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
Template functions (and member functions of class templates) present the same
problem as inline functions. They need to be uniqued, so we need to assign
VisibleNoLinkage linkage to types defined in them.
llvm-svn: 183222
This patch ensures that APValues are deallocated with the ASTContext by
registering a deallocation function for APValues to the ASTContext.
Original version of the patch by James Dennett.
llvm-svn: 183101
which is lifetime-extended by a reference binding. An additional temporary is
created for such a bitfield access (although we have no explicit AST
representation for it).
llvm-svn: 183095
materialized temporary with the corresponding MaterializeTemporaryExpr. This is
groundwork for providing C++11's guaranteed static initialization for global
references bound to lifetime-extended temporaries (if the initialization is a
constant expression).
In passing, fix a couple of bugs where some evaluation failures didn't trigger
diagnostics, and a rejects-valid where potential constant expression testing
would assume that it knew the dynamic type of *this and would reject programs
which relied on it being some derived type.
llvm-svn: 183093
The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.
In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.
llvm-svn: 182962
Check for invalid decls in ObjCMethodDecl::getNextRedeclaration(); otherwise if we start from an invalid redeclaration
of an @implementation we would move to the @interface and not reach the original declaration again.
Fixes rdar://14024851
llvm-svn: 182951
MSVC's class data is always comdat, so clang's should always be
linkonce_odr in LLVM IR.
Reviewers: pcc
Differential Revision: http://llvm-reviews.chandlerc.com/D838
llvm-svn: 182865
This brings the number of linkage computations in "clang -cc1" in SemaExpr.ii
from 58426 to 43134. With -emit-llvm the number goes from 161045 to 145461.
llvm-svn: 182823
Before this patch the linkage cache was only used by the entry level function
(getLinkage). The function that does the actual computation (getLVForDecl),
never looked at it.
This means that we would not reuse an entry in the cache when getLVForDecl did
a recursive call. This patch fixes that by adding another computation enum
value for when we don't care about the linkage at all and having getLVForDecl
check the cache in that case.
When running "clang -cc1" over SemaExpr.ii this brings the number of linkage
computations from 93749 to 58426. When running "clang -cc1 -emit-llvm -O3" it
goes from 198708 to 161444.
For SemaExpr.ii at least linkage computation is a small enough percentage of
the work that the time difference was in the noise.
When asserts are enabled this patch also causes clang to check the linkage
cache even on recursive calls.
llvm-svn: 182799
Faisal Vali