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
John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.
One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.
To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.
llvm-svn: 182711
specialization with modules enabled. Just don't merge them at all for now;
we'll revisit this when support for template merging is added.
In passing, make Decl::dump() a little safer to use with PCH/modules, by making
it not deserialize any additional declarations. From a debugger you can call
decls_begin() or similar first if you want to dump all child decls.
llvm-svn: 182544
* Treat _Atomic(T) as a literal type if T is a literal type.
* Evaluate expressions of this type properly.
* Fix a lurking bug where we built completely bogus ASTs for converting to
_Atomic types in C++ in some cases, caught by the tests for this change.
llvm-svn: 182541
attach, rather than merging all comments on the declaration chain. This gives a
more faithful dump, and has the side benefit of unbreaking uses of dump() from
within AST deserialization (where the redeclaration chain may not be sane).
llvm-svn: 182350
protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes
the property. // rdar://13075400
llvm-svn: 182316
Constructs like PseudoObjectExpr, where an expression can appear more than
once in the AST, use OpaqueValueExprs to guard against inadvertent
re-processing of the shared expression during AST traversal. The most
common form of this is to share expressions between the syntactic
"as-written" form of, say, an Objective-C property access 'obj.prop', and
the underlying "semantic" form '[obj prop]'.
However, some constructs can produce OpaqueValueExprs that don't appear in
the syntactic form at all; in these cases the ParentMap wasn't ever traversing
the children of these expressions. This patch fixes that by checking to see
if an OpaqueValueExpr's child has ever been traversed before. There's also a
bit of reset logic when visiting a PseudoObjectExpr to handle the case of
updating the ParentMap, which some external clients depend on.
This still isn't exactly the right fix because we probably want the parent
of the OpaqueValueExpr itself to be its location in the syntactic form if
it's syntactic and the PseudoObjectExpr or BinaryConditionalOperator itself
if it's semantic. Whe I originally wrote the code to do this, I didn't realize
that OpaqueValueExprs themselves are shared in the AST, not just their source
expressions. This patch doesn't change the existing behavior so as not to
break anything inadvertently relying on it; we'll come back to this later.
llvm-svn: 182187
Ted and I spent a long time discussing this today and found out that neither
the existing code nor the new code was doing what either of us thought it
was, which is never good. The good news is we found a much simpler way to
fix the motivating test case (an ObjCSubscriptExpr).
This reverts r182083, but pieces of it will come back in subsequent commits.
llvm-svn: 182185
This optimizes some spurious edges resulting from PseudoObjectExprs.
This required far more changes than I anticipated. The current
ParentMap does not record any hierarchy information between
a PseudoObjectExpr and its *semantic* expressions that may be
wrapped in OpaqueValueExprs, which are the expressions actually
laid out in the CFG. This means the arrow pruning logic could
not map from an expression to its containing PseudoObjectExprs.
To solve this, this patch adds a variant of ParentMap that
returns the "semantic" parentage of expressions (essentially
as they are viewed by the CFG). This alternate ParentMap is then
used by the arrow reducing logic to identify edges into pseudo
object expressions, and then eliminate them.
llvm-svn: 182083
a FieldDecl from it, and propagate both into the closure type and the
LambdaExpr.
You can't do much useful with them yet -- you can't use them within the body
of the lambda, because we don't have a representation for "the this of the
lambda, not the this of the enclosing context". We also don't have support or a
representation for a nested capture of an init-capture yet, which was intended
to work despite not being allowed by the current standard wording.
llvm-svn: 181985
In the case of inline functions, we have to special case local types
when they are used as template arguments to make sure the template
instantiations are still uniqued in case the function itself is inlined.
llvm-svn: 181981
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
ASTDumper was already trying to do this & instead got an implicit bool
conversion by surprise (thus printing out 0 or 1 instead of the name of
the declaration). To avoid that issue & simplify call sites, simply make
it the normal/expected operator<<(raw_ostream&, ...) overload & simplify
all the existing call sites. (bonus: this function doesn't need to be a
member or friend, it's just using public API in DeclarationName)
llvm-svn: 181832
Most of the complexity of this patch is figuring out which types get the
qualifier and which don't. If we implement __ptr32/64, then we should
check the qualifier instead of assuming all pointers are 64-bit.
This fixes PR13792.
Patch by Warren Hunt!
llvm-svn: 181825
recovery form duplicate method definition error thus
preventing doc parsing to loop trying to find comment
for the invalid redefinition in a previous declaration.
// rdar://13836387
llvm-svn: 181710
Fariborz Jahanian