These functions can generally be applied to multiple kinds of AST node,
so it makes sense to add them to DynTypedNode.
Differential Revision: http://llvm-reviews.chandlerc.com/D2096
llvm-svn: 194113
bit more robust against future changes. This includes a slight diagnostic
improvement: if we know we're only trying to form a constant expression, take
the first diagnostic which shows the expression is not a constant expression,
rather than preferring the first one which makes the expression unfoldable.
llvm-svn: 194098
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
llvm-svn: 194055
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
llvm-svn: 193969
If the sole distinction between two declarations is that one has a
__restrict qualifier then we should not consider it to be an overload.
Instead, we will consider it as an incompatible redeclaration which is
similar to how MSVC, ICC and GCC would handle it.
This fixes PR17786.
N.B. We must not mangle in __restrict into method qualifiers becase we
don't allow overloading between such declarations anymore. To do
otherwise would be a violation of the Itanium ABI.
llvm-svn: 193964
Differential Revision: http://llvm-reviews.chandlerc.com/D2090
Clang was "improperly" over-aligning arrays with sizes are not a multiple of
their alignment.
This behavior was removed in microsoft 32 bit mode.
In addition, after examination of ASTContext::getTypeInfoImpl, a redundant code block in
MicrosoftRecordLayoutBuilder::getAdjustedFieldInfo was deleted.
llvm-svn: 193898
Differential Revision: http://llvm-reviews.chandlerc.com/D2082
Adds a lang_c LinkageSpecDecl to lazily generated builtins. This enforces correct
behavior for builtins in a variety of cases without special treatment elsewhere within
the compiler (special treatment is removed by the patch). It also allows for C++
overloads of builtin functions, which Microsoft uses in their headers e.g.
_InterlockedExchangeAdd is an extern C builtin for the long type but an inline wrapper
for int type.
llvm-svn: 193896
it. Also removes all of the microsoft C++ ABI related code from the
itanium layout builder.
Differential Revision: http://llvm-reviews.chandlerc.com/D2003
llvm-svn: 193290
The Itanium mangler couldn't cope with mangling an IndirectFieldDecl.
Instead, mangle the field the IndirectFieldDecl refers to.
Further, give IndirectFieldDecl no linkage just like FieldDecl.
N.B. Decl.cpp:getLVForNamespaceScopeDecl tried to calculate linkage for
data members of anonymous structs/unions. However, this seems
impossible so turn it into an assertion.
llvm-svn: 193269
A prior commit of this patch was reverted because it was within the blamelist's purview of a failing test. The failure of that test has been addressed here: http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131021/091546.html. Therefore I am recommitting this patch (all tests pass on windows, except for the usual modules & index suspects that never pass on my box).
Some background: Both Doug and Richard had asked me in Chicago to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
No change in functionality.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193246
They were causing CodeGenCXX/mangle-exprs.cpp to fail.
Revert "Remove the circular reference to LambdaExpr in CXXRecordDecl."
Revert "Again: Teach TreeTransform and family how to transform generic lambdas nested within templates and themselves."
llvm-svn: 193226
Both Doug and Richard had asked me to remove the circular reference in CXXRecordDecl to LambdaExpr by factoring out and storing the needed information from LambdaExpr directly into CXXRecordDecl.
No change in functionality.
In addition, I have added an IsGenericLambda flag - this makes life a little easier when we implement capturing, and are Sema-analyzing the body of a lambda (and the calloperator hasn't been wired to the closure class yet). Any inner lambdas can have potential captures that could require walking up the scope chain and checking if any generic lambdas are capture-ready. This 'bit' makes some of that checking easier.
This patch was approved by Doug with minor modifications (comments were cleaned up, and all data members were converted from bool/enum to unsigned, as requested):
http://llvm-reviews.chandlerc.com/D1856
Thanks!
llvm-svn: 193223
This fixes pr17639.
Before this patch clang would consider
void foo(void) __attribute((alias("__foo")));
a declaration. It now correctly handles it as a definition.
Initial patch by Alp Toker. I added support for variables.
llvm-svn: 193200
* NamedDecl and CXXMethodDecl were missing getMostRecentDecl.
* The const version can just forward to the non const.
* getMostRecentDecl can use cast instead of cast_or_null.
This then removes some casts from the callers.
llvm-svn: 193039
Summary: Some MS headers use these features.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1948
llvm-svn: 192936
This removes the dependency on the llvm mangler doing it for us. In isolation,
the benefit is that the testing of what mangling is applied is all in one place:
(C, C++) X (Itanium, Microsoft) are all handled by clang.
This also gives me hope that in the future the llvm mangler (and llvm-ar) will
not depend on TargetMachine.
llvm-svn: 192762
If unqualified id lookup fails while parsing a class template with a
dependent base, clang with -fms-compatibility will pretend the user
prefixed the name with 'this->' in order to delay the lookup. However,
if there was a unary ampersand, Sema::ActOnDependentIdExpression() will
create a DependentDeclRefExpr, which is not what we wanted at all. Fix
this by building the CXXDependentScopeMemberExpr directly instead.
In order to be fully MSVC compatible, we would have to defer all
attempts at name lookup to instantiation time. However, until we have
real problems with system headers that can't be parsed, we'll put off
implementing that.
Fixes PR16014.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1892
llvm-svn: 192727
We have to reserve at least the width of a pointer for the vfptr. For
classes with small alignment, we weren't reserving enough space, and
were overlapping the first field with the vfptr.
llvm-svn: 192626
This patch fixes the distructor test when checking for vtordisp requirements in
microsoft record layout. A test case is also included.
Addresses:
http://llvm.org/bugs/show_bug.cgi?id=16406#c7
llvm-svn: 192616
ASTImporter when importing the following types:
typedef struct {
} A;
typedef struct {
A a;
} B;
Suppose we have imported B, but we did not at that
time need to complete it. Then later we want to
import A. The struct is anonymous, so the first
thing we want to do is make sure no other anonymous
struct already matches it. So we set up an
StructuralEquivalenceContext and compare B with A.
This happens at ASTImporter.cpp:2179.
Now, in this scenario, B is not complete. So we go
and import its fields, including a, which causes A
to be imported. The ASTImporter doesn’t yet have A
in its list of already-imported things, so we
import A.
After the StructuralEquivalenceContext is finished
determining that A and B are different, the
ASTImporter concludes that A must be imported
because no equivalent exists, so it imports a second
copy of A. Now we have two different structs
representing A. This is really bad news.
The patch allows the StructuralEquivalenceContext to
use the original version of B when making its
comparison, obviating the need for an import and
cutting this loop.
llvm-svn: 192324
In the test case one type is coming from a typedef with no default arg, the
other has the default arg. Taking the default arg from the typedef crashes, so
always use the real template paramter declaration. PR17510.
llvm-svn: 192202
As described by Richard in https://groups.google.com/a/isocpp.org/d/msg/std-discussion/S1kmj0wF5-g/fb6agEYoL2IJ
we should allow:
template<typename S>
struct A {
template<typename T> static auto default_lambda() {
return [](const T&) { return 42; };
}
template<class U = decltype(default_lambda<S>())>
U func(U u = default_lambda<S>()) { return u; }
};
int run2 = A<double>{}.func()(3.14);
int run3 = A<char>{}.func()('a');
This patch allows the code using the same trickery that was used to allow the code in non-member functions at namespace scope.
Please see http://llvm-reviews.chandlerc.com/D1844 for richard's approval.
llvm-svn: 192166
Summary:
Operator new, new[], delete, and delete[] are all implicitly static when
declared inside a record. CXXMethodDecl already knows this, but we need
to account for that before we pick the calling convention for the
function type.
Fixes PR17371.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1761
llvm-svn: 192150
This change doesn't go all the way to making fields redeclarable; instead, it
makes them 'mergeable', which means we can find the canonical declaration, but
not much else (and for a declaration that's not from a module, the canonical
declaration is always that declaration).
llvm-svn: 192092
When nested C++11 lambdas are used in NSDMI's - this patch prevents infinite recursion by computing the linkage of any nested lambda by determining the linkage of the outermost enclosing lambda (which might inherit its linkage from its parent).
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191727
Currently, IR generation can't handle file-scope compound literals with
non-constant initializers in C++.
Fixes PR17415 (the first crash in the bug).
(We should probably change (T){1,2,3} to use the same codepath as T{1,2,3} in
C++ eventually, given that the semantics of the latter are actually defined by
the standard.)
llvm-svn: 191719
When nested lambdas are used in NSDMI's - this prevents infinite recursion.
See http://llvm-reviews.chandlerc.com/D1783 for Doug's approval regarding the code, and then request for some tests.
[On a related note, I need this patch so as to pass tests of transformations of nested lambdas returned from member functions]
llvm-svn: 191645
The general strategy is to create template versions of the conversion function and static invoker and then during template argument deduction of the conversion function, create the corresponding call-operator and static invoker specializations, and when the conversion function is marked referenced generate the body of the conversion function using the corresponding static-invoker specialization. Similarly, Codegen does something similar - when asked to emit the IR for a specialized static invoker of a generic lambda, it forwards emission to the corresponding call operator.
This patch has been reviewed in person both by Doug and Richard. Richard gave me the LGTM.
A few minor changes:
- per Richard's request i added a simple check to gracefully inform that captures (init, explicit or default) have not been added to generic lambdas just yet (instead of the assertion violation).
- I removed a few lines of code that added the call operators instantiated parameters to the currentinstantiationscope. Not only did it not handle parameter packs, but it is more relevant in the patch for nested lambdas which will follow this one, and fix that problem more comprehensively.
- Doug had commented that the original implementation strategy of using the TypeSourceInfo of the call operator to create the static-invoker was flawed and allowed const as a member qualifier to creep into the type of the static-invoker. I currently kludge around it - but after my initial discussion with Doug, with a follow up session with Richard, I have added a FIXME so that a more elegant solution that involves the use of TrivialTypeSourceInfo call followed by the correct wiring of the template parameters to the functionprototypeloc is forthcoming.
Thanks!
llvm-svn: 191634
- We scan for whitespace between comments anyways, remember any newlines seen
along the way.
- Use this newline number to decide whether two comments are adjacent.
- Since the newline check is now free remove the caching and unused code.
- Remove unnecessary boolean state from the comment list.
- No behavioral change.
llvm-svn: 191614
We previously handled one-dimensional arrays but didn't consider the
general case. The fix is simple: keep going through subsequent
dimensions until we get to the base element.
llvm-svn: 191493
The intent of getTypeOperand() was to yield an unqualified type.
However QualType::getUnqualifiedType() does not strip away qualifiers on
arrays.
N.B. This worked fine when typeid() was applied to an expression
because we would inject as implicit cast to the unqualified array type
in the AST.
llvm-svn: 191487
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- generic lambdas within template functions and nested
within other generic lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
(Although I have gotten some useful feedback on my patches of the above and will be incorporating that as I submit those patches for commit)
As an example of what compiles through this commit:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
This patch has been reviewed by Doug and Richard. Minor changes (non-functionality affecting) have been made since both of them formally looked at it, but the changes involve removal of supernumerary return type deduction changes (since they are now redundant, with richard having committed a recent patch to address return type deduction for C++11 lambdas using C++14 semantics).
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that SemaType.cpp::ConvertDeclSpecToType may use it to immediately
generate a template-parameter-type when 'auto' is parsed in a generic
lambda parameter context. (i.e we do NOT use AutoType deduced to
a template parameter type - Richard seemed ok with this approach).
We encode that this template type was generated from an auto by simply
adding $auto to the name which can be used for better diagnostics if needed.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- various tests were added - but much more will be needed.
There is obviously more work to be done, and both Richard (weakly) and Doug (strongly)
have requested that LambdaExpr be removed form the CXXRecordDecl LambdaDefinitionaData
in a future patch which is forthcoming.
A greatful thanks to all reviewers including Eli Friedman, James Dennett,
and especially the two gracious wizards (Richard Smith and Doug Gregor)
who spent hours providing feedback (in person in Chicago and on the mailing lists).
And yet I am certain that I have allowed unidentified bugs to creep in; bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 191453
1. Fixed constructor of shared clause.
2. Some macros for clauses processing are replaced by private template methods.
3. Additional checks in sema analysis of OpenMP clauses.
llvm-svn: 191265
LLVM supports applying conversion instructions to vectors of the same number of
elements (fptrunc, fptosi, etc.) but there had been no way for a Clang user to
cause such instructions to be generated when using builtin vector types.
C-style casting on vectors is already defined in terms of bitcasts, and so
cannot be used for these conversions as well (without leading to a very
confusing set of semantics). As a result, this adds a __builtin_convertvector
intrinsic (patterned after the OpenCL __builtin_astype intrinsic). This is
intended to aid the creation of vector intrinsic headers that create generic IR
instead of target-dependent intrinsics (in other words, this is a generic
_mm_cvtepi32_ps). As noted in the documentation, the action of
__builtin_convertvector is defined in terms of the action of a C-style cast on
each vector element.
llvm-svn: 190915
Summary:
When selecting a mangling for an anonymous tag type:
- We should first try it's typedef'd name.
- If that doesn't work, we should mangle in the name of the declarator
that specified it as a declaration specifier.
- If that doesn't work, fall back to a static mangling of
<unnamed-type>.
This should make our anonymous type mangling compatible.
This partially fixes PR16994; we would need to have an implementation of
scope numbering to get it right (a separate issue).
Reviewers: rnk, rsmith, rjmccall, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1540
llvm-svn: 190892
Like any other type, an init list for a vector can have the same type as
the vector itself; handle that case.
<rdar://problem/14990460>
llvm-svn: 190844
Summary:
This fixes several issues with the original implementation:
- Win32 entry points cannot be in namespaces
- A Win32 entry point cannot be a function template, diagnose if we it.
- Win32 entry points cannot be overloaded.
- Win32 entry points implicitly return, similar to main.
Reviewers: rnk, rsmith, whunt, timurrrr
Reviewed By: rnk
CC: cfe-commits, nrieck
Differential Revision: http://llvm-reviews.chandlerc.com/D1683
llvm-svn: 190818
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
llvm-svn: 190684
Summary:
Functions named "main", "wmain", "WinMain", "wWinMain", and "DllMain"
are never mangled regardless of linkage, even when compiling for kernel
mode.
Depends on D1655
Reviewers: timurrrr, pcc, rnk, whunt
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1670
llvm-svn: 190675
Summary:
This is a first step to getting extern "C" working properly inside
clang. There are a number of quirks but mangling declarations inside
such a function are a good first step.
Reviewers: timurrrr, pcc, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1655
llvm-svn: 190671
Summary:
More accurately characterize the nature of array parameters. Doing this
removes false back-reference opportunities. Remove some hacks now that
we characterize these better.
Reviewers: rnk, timurrrr, whunt, cdavis5x
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1626
llvm-svn: 190488
trunk clang is a bit more aggressive about emitting unused-declaration
warnings, so adjust some AST code to match. Specifically, use
LLVM_ATTRIBUTE_UNUSED for declarations which are never supposed to be
referenced, and turn references to declarations which are supposed to be
referenced into odr-uses.
llvm-svn: 190443
Static locals requiring initialization are not thread safe on Windows.
Unfortunately, it's possible to create static locals that are actually
externally visible with inline functions and templates. As a result, we
have to implement an initialization guard scheme that is compatible with
TUs built by MSVC, which makes thread safety prohibitively difficult.
MSVC's scheme is that every function that requires a guard gets an i32
bitfield. Each static local is assigned a bit that indicates if it has
been initialized, up to 32 bits, at which point a new bitfield is
created. MSVC rejects inline functions with more than 32 static locals,
and the externally visible mangling (?_B) only allows for one guard
variable per function.
On Eli's recommendation, I used MangleNumberingContext to track which
bit each static corresponds to.
Implements PR16888.
Reviewers: rjmccall, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1416
llvm-svn: 190427
name lookup from lazily deserializing the other declarations with the same
name, by tracking a bit to indicate whether a name in a DeclContext might have
additional external results. This also allows lazier reconciling of the lookup
table if a module import adds decls to a pre-existing DC.
However, this exposes a pre-existing bug, which causes a regression in
test/Modules/decldef.mm: if we have a reference to a declaration, and a
later-imported module adds a redeclaration, nothing causes us to load that
redeclaration when we use or emit the reference (which can manifest as a
reference to an undefined inline function, a use of an incomplete type, and so
on). decldef.mm has been extended with an additional testcase which fails with
or without this change.
llvm-svn: 190293
Summary:
__uuidof on templated types should exmaine if any of its template
parameters have a uuid declspec. If exactly one does, then take it.
Otherwise, issue an appropriate error.
Reviewers: rsmith, thakis, rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1419
llvm-svn: 190240
Summary: Closure classes for C++ lambdas are always compiler-generated. This one-line change calls setImplicit(true) on them at creation time, such that a default RecursiveASTVisitor (or any for which shouldVisitImplicitCode returns false) will skip them.
Reviewers: rsmith, dblaikie
Reviewed By: dblaikie
CC: klimek, revane, cfe-commits, jordan_rose
Differential Revision: http://llvm-reviews.chandlerc.com/D1593
llvm-svn: 190073
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth.
As first commit for PR16752 fix: 'mode' attribute for unusual targets doesn't work properly
Description:
Troubles could be happened due to some assumptions in handleModeAttr function (see SemaDeclAttr.cpp).
For example, it assumes that 32 bit integer is 'int', while it could be 16 bit only.
Instead of asking target: 'which type do you want to use for int32_t ?' it just hardcodes general opinion. That doesn't looks pretty correct.
Please consider the next solution:
1. In Basic/TargetInfo add getIntTypeByWidth and getRealTypeByWidth virtual methods. By default current behaviour could be implemented here.
2. Fix handleModeAttr according to new methods in TargetInfo.
This approach is implemented in the patch attached to this post.
Fixes:
1st Commit (Current): Add new methods for TargetInfo:
getRealTypeByWidth and getIntTypeByWidth
for ASTContext names are almost same(invokes new methods from TargetInfo):
getIntTypeForBitwidth and getRealTypeForBitwidth
2nd Commit (Next): Fix SemaDeclAttr, handleModeAttr function.
llvm-svn: 190044
When an AST file is built based on another AST file, it can use a decl from
the fist file, and therefore mark the "isUsed" bit. We need to note this in
the AST file so that the bit is set correctly when the second AST file is
loaded.
This patch introduces the distinction between setIsUsed() and markUsed() so
that we don't call into the ASTMutationListener callback when it wouldn't
be appropriate.
Fixes PR16635.
llvm-svn: 190016
Summary: I added the display of the VarDecl contained in the statement.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1596
llvm-svn: 189941
Summary:
I have no idea why these were there in the first place, but now they are
certainly not necessary.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1581
llvm-svn: 189813
been an oversight, as it definitely works. Every test which changed had
the const written on the LHS of the auto already.
Notably, this also makes things like cpp11-migrate's formation of 'const
auto &' variables much more familiar.
Yes, many people feel that 'const' and other qualifiers belong on the
RHS of the type. I'm not going to argue about that because Clang already
*overwhelming* places the qualifiers on the LHS when it can and on the
RHS when it must. We shouldn't diverge for auto. We should add a tool to
clang-tidy that fixes this in either direction, and then wire up
clang-tidy to tools like cpp11-migrate to fix their placement after
transforms.
llvm-svn: 189769
these in eagerly if we're not actually processing a translation unit. The added
laziness here also avoids us loading in parts of a CXXRecordDecl earlier than an
upcoming class template specialization merging patch would like.
Ideally, we should mark the vtable as used when we see a definition for the key
function, rather than having a separate pass over dynamic classes at the end of
the TU. The existing approach is pretty bad for PCH/modules, since it forcibly
loads the declarations of all key functions in all imported modules, whether or
not those key functions are defined.
llvm-svn: 189627
I changed the diagnostic printing code because it's probably better
to cut off a digit from DBL_MAX than to print something like
1.300000001 when the user wrote 1.3.
llvm-svn: 189625
Summary:
Instead of calling getAsTemplate(), call
getAsTemplateOrTemplatePattern() because it handles the
TemplateExpansion case too.
This fixes PR16997.
Reviewers: doug.gregor, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1512
llvm-svn: 189422
Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
llvm-svn: 189412
- __func__ or __FUNCTION__ returns captured statement's parent
function name, not the one compiler generated.
Differential Revision: http://llvm-reviews.chandlerc.com/D1491
Reviewed by bkramer
llvm-svn: 189219
would cause us to concatenate these paragraphs into a single one.
The no-op whitespace churn in test/Index test happened because these tests
don't use the correct approach for testing and are more strict than required
for they are testing.
llvm-svn: 189126
This was only used to ensure that the traversal order was the same as the
insertion order, but that guarantee was already being provided by the use
of a FoldingSetVector.
llvm-svn: 189075
Specifically, the following features are not included in this commit:
- any sort of capturing within generic lambdas
- nested lambdas
- conversion operator for captureless lambdas
- ensuring all visitors are generic lambda aware
As an example of what compiles:
template <class F1, class F2>
struct overload : F1, F2 {
using F1::operator();
using F2::operator();
overload(F1 f1, F2 f2) : F1(f1), F2(f2) { }
};
auto Recursive = [](auto Self, auto h, auto ... rest) {
return 1 + Self(Self, rest...);
};
auto Base = [](auto Self, auto h) {
return 1;
};
overload<decltype(Base), decltype(Recursive)> O(Base, Recursive);
int num_params = O(O, 5, 3, "abc", 3.14, 'a');
Please see attached tests for more examples.
Some implementation notes:
- Add a new Declarator context => LambdaExprParameterContext to
clang::Declarator to allow the use of 'auto' in declaring generic
lambda parameters
- Augment AutoType's constructor (similar to how variadic
template-type-parameters ala TemplateTypeParmDecl are implemented) to
accept an IsParameterPack to encode a generic lambda parameter pack.
- Add various helpers to CXXRecordDecl to facilitate identifying
and querying a closure class
- LambdaScopeInfo (which maintains the current lambda's Sema state)
was augmented to house the current depth of the template being
parsed (id est the Parser calls Sema::RecordParsingTemplateParameterDepth)
so that Sema::ActOnLambdaAutoParameter may use it to create the
appropriate list of corresponding TemplateTypeParmDecl for each
auto parameter identified within the generic lambda (also stored
within the current LambdaScopeInfo). Additionally,
a TemplateParameterList data-member was added to hold the invented
TemplateParameterList AST node which will be much more useful
once we teach TreeTransform how to transform generic lambdas.
- SemaLambda.h was added to hold some common lambda utility
functions (this file is likely to grow ...)
- Teach Sema::ActOnStartOfFunctionDef to check whether it
is being called to instantiate a generic lambda's call
operator, and if so, push an appropriately prepared
LambdaScopeInfo object on the stack.
- Teach Sema::ActOnStartOfLambdaDefinition to set the
return type of a lambda without a trailing return type
to 'auto' in C++1y mode, and teach the return type
deduction machinery in SemaStmt.cpp to process either
C++11 and C++14 lambda's correctly depending on the flag.
- various tests were added - but much more will be needed.
A greatful thanks to all reviewers including Eli Friedman,
James Dennett and the ever illuminating Richard Smith. And
yet I am certain that I have allowed unidentified bugs to creep in;
bugs, that I will do my best to slay, once identified!
Thanks!
llvm-svn: 188977
1. We now print the return type of lambdas and return type deduced functions
as "auto". Trailing return types with decltype print the underlying type.
2. Use the lambda or block scope for the PredefinedExpr type instead of the
parent function. This fixes PR16946, a strange mismatch between type of the
expression and the actual result.
3. Verify the type in CodeGen.
4. The type for blocks is still wrong. They are numbered and the name is not
known until CodeGen.
llvm-svn: 188900
We previously mishandled UnresolvedUsingValueDecls in
NamedDecl::declarationReplaces, which caused us to forget decls
when there are multiple dependent using decls for the same name.
Fixes PR16936.
llvm-svn: 188737
Summary:
HandleTopLevelDecl on a templated function leads us to try and mangle
it.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1412
llvm-svn: 188536
In addition to storing more useful information in the AST, this
fixes a semantic check in template instantiation which checks whether
the l-paren location is valid.
Fixes PR16903.
llvm-svn: 188495
Add support for half (a.k.a. __fp16) in builtin descriptions.
The second argument to BUILTIN() now accepts 'h' to represent half.
Patch by Daniel Sanders
llvm-svn: 188464
Summary:
There were several things going wrong:
- We mangled in useless qualifiers like "volatile void" return types.
- We didn't propagate 64-bit pointer markers sufficiently.
- We mangled qualifiers belonging to the pointee incorrectly.
This fixes PR16844 and PR16848.
Reviewers: rnk, whunt
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1353
llvm-svn: 188450
Summary:
It seems that __uuidof introduces a global extern "C" declaration of
type __s_GUID. However, our implementation of __uuidof does not provide
such a declaration and thus must open-code the mangling for __uuidof in
template parameters.
This allows us to codegen scoped COM pointers and other such things.
This fixes PR16836.
Depends on D1356.
Reviewers: rnk, cdavis5x, rsmith
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1357
llvm-svn: 188252
Summary:
Source-centric tools need access to the location of a C++11
lambda expression's capture-default ('&' or '=') when it's present.
It's possible for them to find it by re-lexing and re-implementing
rules that Clang's parser has already applied, but the cost of storing
the SourceLocation and making it available to them is 32 bits per
LambdaExpr (a small delta, proportionally), and the simplification in
client code is significant.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits, klimek, revane
Differential Revision: http://llvm-reviews.chandlerc.com/D1192
llvm-svn: 188121
We mangled them like:
L___uuid_12345678-1234-1234-1234-123456789abc
We should've mangled them like:
__GUID_12345678_1234_1234_1234_123456789abc
Furthermore, they are external symbols.
llvm-svn: 188053
of local classes. We were previously handling this by performing qualified
lookup within a function declaration(!!); replace it with the proper scope
lookup.
llvm-svn: 188050
We were exposing the extra alignment given to large arrays. The new behavior
matches gcc, which is a good thing since this is a gcc extension.
Thanks to Joerg Sonnenberger for noticing it.
While at it, centralize the method description in the .h file.
llvm-svn: 187999
Before this patch we would align
long long int big[1024];
to 4 bytes on 32 bit systems. The problem is that we were only looking
at the element type when getLargeArrayMinWidth returned non zero.
llvm-svn: 187897
There were three things missing from the original implementation:
- We would omit the 'E' qualifier for members int 64-bit mode.
- We would not exmaine the qualifiers in 'IsMember' mode.
- We didn't generate the correct backref to the base class.
llvm-svn: 187753
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
via a macro, try using declaration's starting location.
This is improvement over not having a valid location and
dropping comment altogether. // rdar://14348912
llvm-svn: 187085
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
No functionality change.
In Sema helper functions:
* renamed isTypeName as HasTypenameKeyword
In UsingDecl:
* renamed get/setUsingLocation to get/setUsingLoc
* renamed is/setTypeName as has/setTypename
llvm-svn: 186816
optimize, to follow the permissions granted in N3664. Under those rules, only
calls generated by new-expressions and delete-expressions are permitted to be
optimized, and direct calls to ::operator new and ::operator delete must be
treated as normal calls.
llvm-svn: 186799
A class with a field of non-POD-for-layout type is not POD-for-layout.
This computation should not depend on whether the field is of POD type
in the language sense.
Fixes PR16537.
Patch by Josh Magee.
llvm-svn: 186741
This is the same way GenericSelectionExpr works, and it's generally a
more consistent approach.
A large part of this patch is devoted to caching the value of the condition
of a ChooseExpr; it's needed to avoid threading an ASTContext into
IgnoreParens().
Fixes <rdar://problem/14438917>.
llvm-svn: 186738
Summary: In ARC mode, clang emits a warning if the result of an 'init' method is unused but miss cases where the method does not follows the Cocoa naming convention but is properly declared as an init family method.
CC: cfe-commits, eli.friedman
Differential Revision: http://llvm-reviews.chandlerc.com/D1163
llvm-svn: 186718
Canonical types are unchanged. The type printer had to be changed to
avoid printing any non-default implicit calling convention as well as
the calling convention attribute.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D1132
llvm-svn: 186714
Sema needs to be able to accurately determine what will be
emitted as a constant initializer and what will not, so
we get accurate errors in C and accurate -Wglobal-constructors
warnings in C++. This makes Expr::isConstantInitializer match
CGExprConstant as closely as possible.
llvm-svn: 186464
Summary:
Add support for CXXCtorInitializer and TemplateArgument types to ASTNodeKind.
This change is to support more matchers from clang/ASTMatchers/ASTMatchers.h in the dynamic layer (clang/ASTMatchers/Dynamic).
Reviewers: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1143
llvm-svn: 186422
The record layout code didn't properly take into account that
an empty class at offset 0 can have an alignment greater than 1.
Patch by Andrea Di Biagio.
llvm-svn: 186370
decls. That can reenter deserialization and explode horribly by trying to merge
a declaration that we've not got very far through deserializing yet.
llvm-svn: 186236
They don't seem to be used for back references, presumably because a
function template is unlikely to reoccur, while a class template name
may reoccur as a type.
This fixes a mangling issue for llvm::hash_combine() in Hashing.h.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D1078
llvm-svn: 186233
Make sure we don't crash when checking whether an assignment operator
without any arguments is a special member. <rdar://problem/14397774>.
llvm-svn: 186137
& operator (ignoring any overloaded operator& for the type). The purpose of
this builtin is for use in std::addressof, to allow it to be made constexpr;
the existing implementation technique (reinterpret_cast to some reference type,
take address, reinterpert_cast back) does not permit this because
reinterpret_cast between reference types is not permitted in a constant
expression in C++11 onwards.
llvm-svn: 186053
migrate to 'copy attribute if Object
class implements NSCopying otherwise
assume implied 'strong'. Remove
lifetime qualifier on property as it has
moved to property's attribute. Added TODO
comment for future work by poking into
setter implementation.
llvm-svn: 186037
Specifically, handle the case where the block is in a default argument
in a class method. The mangling here follows what we do for lambdas.
llvm-svn: 185991
Compute mangling numbers for externally visible local variables and tags.
Change the mangler to consistently use discriminators where necessary.
Tweak the scheme we use to number decls which are not externally visible
to avoid unnecessary discriminators in common cases now that we request
them more consistently.
Fixes <rdar://problem/14204721>.
llvm-svn: 185986
This changes the TBAA code so it doesn't use mangleCXXRTTIName in C,
because it doesn't really make sense there. Also, as sort of a
defense-in-depth change, fix the mangler so it handles C RecordDecls
correctly.
No tests because I don't know the TBAA code well enough to write a test,
and I don't know how else to trigger mangling a local struct in C.
Fixes a crash with r185450 reported by Joerg Sonnenberger.
llvm-svn: 185721
As it turns out, the NoFunction bit for local class mangling needed to be
propagated into more places. r185450 turned what used to be an incorrect
mangling into an assertion.
llvm-svn: 185713
Unlike Itanium, there is no code to indicate the beginning of a
parameter pack. I tested this with MSVC 2013, which is the only version
that implements variadic templates so far.
This is needed to compile APInt.cpp for the MS C++ ABI.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D1077
llvm-svn: 185454
Make sure we properly treat names defined inside a block as local
names. There are basically three fixes here. One, correctly
treat blocks as a context where we need to use local-name mangling using
the new isLocalContainerContext helper. Two, make
CXXNameMangler::manglePrefix handle local names in a consistent way.
Three, extend CXXNameMangler::mangleLocalName so it can mangle a block
correctly.
llvm-svn: 185450
This commit rearranges the logic in CXXNameMangler::mangleLocalName and
GetLocalClassDecl so that it doesn't accidentally skip over lambdas. It
also reduces code duplication a bit.
llvm-svn: 185402
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
llvm-svn: 185372
Armed with a much better understanding of what
TemplateSpecializationTypeLoc::initializeArgLocs actually does, I now
understand that it's fine to just use an empty TemplateArgumentLocInfo
for Integral, Declaration, and NullPtr TemplateArguments.
Fixes PR14281. (The testcases are actually derived from libcxx_test in
deduction-crash.cpp because the original testcase was impossible to reduce.)
llvm-svn: 185038
The old implementation of ms_struct in RecordLayoutBuilder was a
complete mess: it depended on complicated conditionals which didn't
really reflect the underlying logic, and placed a burden on users of
the resulting RecordLayout. This commit rips out almost all of the
old code, and replaces it with simple checks in
RecordLayoutBuilder::LayoutBitField.
This commit also fixes <rdar://problem/14252115>, a bug where class
inheritance would cause us to lay out bitfields incorrectly.
llvm-svn: 185018
When the decl that we're getting alignment for is a FieldDecl, and the field's
parent record is invalid, skip the actual field alignment calculation (and
return 1-byte alignment in the general case).
Also, assert in in getASTRecordLayout that the decl is valid. This was
inspired by PR16292; see also r184581 and r184751.
llvm-svn: 184883
This changes the mangling of local static variables/etc. inside blocks
to do something simple and sane. This avoids depending on the way we mangle
blocks, which isn't really appropriate here.
John, please take a look at this to make sure the mangling I chose is sane.
Fixes <rdar://problem/14074423>.
llvm-svn: 184780
At this point, it's clear that the MSVC mangler uses the type-as-written
instead of the canonical type, so this should bring us closer to MSVC.
The main thrust of this change is to fix the way we mangle decayed array
parameters of function pointer parameters. With a DecayedType sugar
node, this code can now be much simpler.
Fixes PR16096.
This also fixes a separate issue that Richard spotted in review.
Because separate declarations of the same entity can be spelled and
mangled differently, MSVC always mangles the earliest declaration in an
attempt to avoid link errors. Clang now does the same.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D844
llvm-svn: 184777
The goal of this sugar node is to be able to look at an arbitrary
FunctionType and tell if any of the parameters were decayed from an
array or function type. Ultimately this is necessary to implement
Microsoft's C++ name mangling scheme, which mangles decayed arrays
differently from normal pointers.
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1014
llvm-svn: 184763
constructing a lookup table.
Previously, buildLookup would add lookup table entries for each item lexically
within the DC, and adding the first entry with a given name would trigger the
external source to add all its entries with that name. Then buildLookup would
carry on and re-add those entries all over again.
Instead, follow a simple rule: a declaration from an external source is only
ever made visible by the external source. One exception to this: since we don't
usually build a lookup table for the TU in C, and we never serialize one, we
don't expect the external source to provide lookups in the TU in C, so we build
those ones ourselves.
llvm-svn: 184696
whether they replace any existing lookups in the context, rather than
accumulating a bunch of lookup results referring to the same entity.
llvm-svn: 184679
Remove unneeded member in CommentSema, add a test for the XML schema (the
schema already allowed multiple paragraphs in <ResultDiscussion>, but there
were no tests for that), fix HTML generation (it is not allowed to have <p>
inside <dl>).
llvm-svn: 184652
Added ASTNodeKind as a standalone way to represent node kinds and their hierarchy.
This change is to support ongoing work on D815.
Reviewers: klimek
CC: cfe-commits
llvm-svn: 184331
In Itanium, dynamic classes have one vtable with several different
address points for dynamic base classes that can't share vtables.
In the MS C++ ABI, each vbtable that can't be shared gets its own
symbol, similar to how ctor vtables work in Itanium. However, instead
of mangling the subobject offset into the symbol, the unique portions of
the inheritance path are mangled into the symbol to make it unique.
This patch implements the MSVC 2012 scheme for forming unique vbtable
symbol names. MSVC 2010 use the same mangling with a different subset
of the path. Implementing that mangling and possibly others is TODO.
Each vbtable is an array of i32 offsets from the vbptr that points to it
to another virtual base subobject. The first entry of a vbtable always
points to the base of the current subobject, implying that it is the
same no matter which parent class contains it.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D636
llvm-svn: 184309
to provide proper overloading, and also prevents mangling conflicts with
template arguments of protocol-qualified type.
This is a non-backward-compatible mangling change, but per discussion with
John, the benefits outweigh this cost.
Fixes <rdar://problem/14074822>.
llvm-svn: 184250
The untemplated implementation of getParents() doesn't need to be in a
header file.
RecursiveASTVisitor.h is full of repeated macro expansion. Moving this
include to ASTContext.cpp speeds up compilation of
LambdaMangleContext.cpp, a small C++ file with few includes, from 3.7s
to 2.8s for me locally. I haven't measured a full build, but it can't
hurt.
I had to fix a few static analyzer files that were depending on
transitive includes of C++ AST headers.
Reviewers: rsmith, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D982
llvm-svn: 184075
the result of a cast-to-reference-type lifetime-extends the object to which the
reference inside the cast binds.
This requires us to look for subobject adjustments on both the inside and the
outside of the MaterializeTemporaryExpr when looking for a temporary to
lifetime-extend (which we also need for core issue 616, and possibly 1213).
llvm-svn: 184024
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
This helps preserve the type-as-written in the AST, which we need for
MSVC mangling. In particular, we need to preserve the types of array
parameters in function pointer types.
The essence of this change is:
- QualType ArgTy = Param->getType();
+ QualType ArgTy = Param->getTypeSourceInfo()->getType();
... followed by the adjustment in ActOnFunctionDeclarator().
Differential Revision: http://llvm-reviews.chandlerc.com/D883
llvm-svn: 183614
correctly in the presence of qualified types.
(I had to change the unittest because it was trying to cast a
QualifiedTypeLoc to TemplateSpecializationTypeLoc.)
llvm-svn: 183563
correctly aligned. Not performing such computations led to misaligned loads,
which crash on some platforms and are generally bad on other platforms.
The implementation of TypeLocBuilder::pushImpl is rather messy; code using
TypeLocBuilder accidentally assumes that partial TypeLocs are
laid out like a complete TypeLoc. As a followup, I intend to work on
fixing the TypeLocBuilder API to avoid exposing partial TypeLocs; this should
substantially simplify the implemementation.
Fixes PR16144.
llvm-svn: 183466
Previously our edges were completely broken here; now, the final result
is a very simple set of edges in most cases: one up to the "for" keyword
for context, and one into the body of the loop. This matches the behavior
for ObjC for-in loops.
In the AST, however, CXXForRangeStmts are handled very differently from
ObjCForCollectionStmts. Since they are specified in terms of equivalent
statements in the C++ standard, we actually have implicit AST nodes for
all of the semantic statements. This makes evaluation very easy, but
diagnostic locations a bit trickier. Fortunately, the problem can be
generally defined away by marking all of the implicit statements as
part of the top-level for-range statement.
One of the implicit statements in a for-range statement is the declaration
of implicit iterators __begin and __end. The CFG synthesizes two
separate DeclStmts to match each of these decls, but until now these
synthetic DeclStmts weren't in the function's ParentMap. Now, the CFG
keeps track of its synthetic statements, and the AnalysisDeclContext will
make sure to add them to the ParentMap.
<rdar://problem/14038483>
llvm-svn: 183449
must be initialized by a constant expression (not just a core constant
expression), because we're going to emit it as a global. Core issue for this is
pending.
llvm-svn: 183388
We based decisions during analysis and during path generation on whether
or not an expression is consumed, so if a top-level expression has
cleanups it's important for us to look through that.
<rdar://problem/14076125>
llvm-svn: 183368
In r183298, I've used llvm::SmallPtrSet<..., 8> instead of llvm::SmallVector<..., 8> for NewVirtualFunctionsTy by mistake.
This only manifested when a class had more than 8 virtual functions, which wasn't covered by unit-tests
llvm-svn: 183310
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
llvm-svn: 183283
Timur Iskhodzhanov