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
CXXCtorInitializers to the point where we perform the questionable lifetime
extension. This exposed a selection of false negatives in the warning.
llvm-svn: 183869
were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).
Original commit message:
Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.
We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.
llvm-svn: 183859
Disallowing deriving from classes that have private virtual base classes
except in instances where the deriving class would be able to cast
itself to the private virtual base via a different derivation.
llvm-svn: 183462
While the C++ standard requires that this lookup take place only at the
definition point of a virtual destructor (C++11 [class.dtor]p12), the
Microsoft ABI may require the compiler to emit a deleting destructor
for any virtual destructor declared in the TU, including ones without
a body, requiring an operator delete() lookup for every virtual
destructor declaration. The result of the lookup should be the same
no matter which declaration is used (except in weird corner cases).
This change will cause us to reject some valid TUs in Microsoft ABI
mode, e.g.:
struct A {
void operator delete(void *);
};
struct B {
void operator delete(void *);
};
struct C : A, B {
virtual ~C();
};
As Richard points out, every virtual function declared in a TU
(including this virtual destructor) is odr-used, so it must be defined
in any program which declares it, or the program is ill formed, no
diagnostic required. Because we know that any definition of this
destructor will cause the lookup to fail, the compiler can choose to
issue a diagnostic here.
Differential Revision: http://llvm-reviews.chandlerc.com/D822
llvm-svn: 182270
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
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
MSVC provides __wchar_t. This is the same as the built-in wchar_t type
from C++, but it is also available with -fno-wchar and in C.
The commit changes ASTContext to have two different types for this:
- WCharTy is the built-in type used for wchar_t in C++ and __wchar_t.
- WideCharTy is the type of a wide character literal. In C++ this is
the same as WCharTy, and in C it is an integer type compatible with
the type in <stddef.h>.
This fixes PR15815.
llvm-svn: 181587
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
llvm-svn: 180976
When we find a friend declaration we have to skip transparent contexts for doing
lookups, but we should not skip them when inserting the new decl if the lookup
found nothing.
Fixes PR15841.
llvm-svn: 180571
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.
There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.
llvm-svn: 179958
constructor. This isn't quite perfect (as usual, we don't handle default
arguments correctly yet, and we don't deal with copy/move constructors for
arguments correctly either, but this will be fixed when we implement core issue
1351.
This completes our support for inheriting constructors.
llvm-svn: 179154
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
overriding a non-deleted virtual function. The existing check for this doesn't
catch this case, because it fires before we mark the method as deleted.
llvm-svn: 178563
uninstantiated exception specification when a special member within a class
template is both defaulted and given an exception specification on its first
declaration.
llvm-svn: 178103
When Sema::RequireCompleteType() is given a class template
specialization type that then fails to instantiate, it returns
'true'. On subsequent invocations, it can return false. Make sure that
this difference doesn't change the result of
Sema::CompareReferenceRelationship, which is expected to remain stable
while we're checking an initialization sequence.
llvm-svn: 178088
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
llvm-svn: 177692
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
llvm-svn: 175900
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
llvm-svn: 175575
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
If the member has an initializer, assume it was probably intended to be static
and suggest/recover with that.
If the member doesn't have an initializer, assume it was probably intended to
be const instead of constexpr and suggest that.
(if the attempt to apply these changes fails, don't make any suggestion &
produce the same diagnostic experience as before. The only case where this can
come up that I know of is with a mutable constexpr with an initializer, since
mutable is incompatible with static (but it's already incompatible with
const anyway))
llvm-svn: 173873
never key functions. We did not implement that rule for the
iOS ABI, which was driven by what was implemented in gcc-4.2.
However, implement it now for other ARM-based platforms.
llvm-svn: 173515
expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.
llvm-svn: 172690
ActOnFinishFullExpr that some of its checks only apply to discarded-value
expressions. This adds missing checks for unexpanded variadic template
parameter packs to a handful of constructs.
llvm-svn: 172485
copy-list-initialization (and doesn't add an additional copy step):
Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it
when instantiating initializers in order to correctly handle instantiation of
copy-list-initialization. Teach TreeTransform that function arguments are
initializations, and so need this special treatment too. Finally, remove some
hacks which were working around SubstInitializer's shortcomings.
llvm-svn: 170489
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
llvm-svn: 168847
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
a special member" diagnostic from warning to error, and fix the cases where it
produced diagnostics with incorrect wording.
We don't support this as an extension, and we ban it even in C++98 mode. This
breaks too much (for instance, the ABI-specified calling convention for a type
can change if it acquires a copy constructor through the addition of a default
argument).
llvm-svn: 168769
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
- In C++11, perform overload resolution over all assignment operators, rather than just looking for copy/move assignment operators.
- Clean up after temporaries produced by operator= immediately, rather than accumulating them until the end of the function.
llvm-svn: 167798
assignment generation. This incidentally avoids reusing the same Expr* across
multiple statements in the same object; that was generating slightly broken
ASTs, but I couldn't trigger any observable bad behavior, so no test.
llvm-svn: 167779
would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>
llvm-svn: 167651
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
source locations in places where it is necessary for diagnostics. By itself,
this causes assertions, so while I'm here, also fix property synthesis
for properties of C++ class type so we use so we properly set up a scope
and mark variable declarations.
<rdar://problem/12514189>.
llvm-svn: 166219
GCC and Clang both do not warn on:
struct a { virtual void func(); };
struct b: a { virtual void func(); void func(int); };
struct c: b { void func(int); using b::func; };
but if the "using" was using a::func GCC would still remain silent where Clang
would warn. This change makes Clang consistent with GCC's existing behavior.
llvm-svn: 166154
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
This makes Clang warn about self references in in-class initializers,
for example:
struct S {
int a = a + 42;
};
This basically just moves UninitializedFieldVisitor up a bit in
SemaDeclCXX.cpp, and adds a call to it from ActOnCXXInClassMemberInitializer.
llvm-svn: 164131
type checking for non-static data member initializers in a dependent
class, because our ASTs lose too much information to when
type-checking an initializer. Fixes <rdar://problem/11974632>,
although the result is still rather unsatisfactory.
llvm-svn: 163871
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
and remove ASTContext reference (which was frequently bound to a dereferenced
null pointer) from the recursive lump of printPretty functions. In so doing,
fix (at least) one case where we intended to use the 'dump' mode, but that
failed because a null ASTContext reference had been passed in.
llvm-svn: 162011
things going on here that were problematic:
- We were missing the actual access check, or rather, it was suppressed
on account of being a redeclaration lookup.
- The access check would naturally happen during delay, which isn't
appropriate in this case.
- We weren't actually emitting dependent diagnostics associated with
class templates, which was unfortunate.
- Access was being propagated incorrectly for friend method declarations
that couldn't be matched at parse-time.
llvm-svn: 161652
for side-effects. Instead, check for side-effects after performing
initialization. Doing so also removes some strange corner cases and differences
between in-class initialization and constructor initialization.
llvm-svn: 161449
we know whether the function is virtual. But check it as soon as we do know;
in some cases we don't need to wait for an instantiation.
llvm-svn: 161316
sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.
llvm-svn: 161008
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
structor class under ARC, that struct/class does not have a trivial
move constructor or move assignment operator. Fixes the rest of
<rdar://problem/11738725>.
llvm-svn: 160615
be defined as deleted, take cv-qualifiers on class members into account when
looking up the copy or move constructor or assignment operator which will be
used for them.
llvm-svn: 160418
diagnostics implemented -- see testcases.
I created a new TableGen file for comment diagnostics,
DiagnosticCommentKinds.td, because comment diagnostics don't logically
fit into AST diagnostics file. But I don't feel strongly about it.
This also implements support for self-closing HTML tags in comment
lexer and parser (for example, <br />).
In order to issue precise diagnostics CommentSema needs to know the
declaration the comment is attached to. There is no easy way to find a decl by
comment, so we match comments and decls in lockstep: after parsing one
declgroup we check if we have any new, not yet attached comments. If we do --
then we do the usual comment-finding process.
It is interesting that this automatically handles trailing comments.
We pick up not only comments that precede the declaration, but also
comments that *follow* the declaration -- thanks to the lookahead in
the lexer: after parsing the declgroup we've consumed the semicolon
and looked ahead through comments.
Added -Wdocumentation-html flag for semantic HTML errors to allow the user to
disable only HTML warnings (but not HTML parse errors, which we emit as
warnings in -Wdocumentation).
llvm-svn: 160078
which will appear in the vtable as used, not just those ones which were
declared within the class itself. Fixes an issue reported as comment#3 in
PR12763 -- we sometimes assert in codegen if we try to emit a reference to a
function declaration which we've not marked as referenced. This also matches
gcc's observed behavior.
llvm-svn: 159895
template instantiation. I wasn't able to reproduce this down to
anything small enough to put in our test suite, but it's "obviously"
okay to set the invalid bit earlier and precludes a
known-broken-but-not-marked-broken class from being used elsewhere.
llvm-svn: 159584
This works around a quirk in the way that explicit template specializations are
handled in Clang. We generate an implicit declaration from the original
template which the explicit specialization is considered to redeclare. This
trips up the explicit delete logic.
This change only works around that strange representation. At some point it'd
be nice to remove those extra declarations to make the AST more accurately
reflect the C++ semantics.
Review by Doug Gregor.
llvm-svn: 159167
resulted in it being reverted. A test for that bug was added in r158950.
Original comment:
If an object (such as a std::string) with an appropriate c_str() member function
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 159159
Revert "If an object (such as a std::string) with an appropriate c_str() member function"
This reverts commit 7d96f6106bfbd85b1af06f34fdbf2834aad0e47e.
llvm-svn: 158949
is passed to a variadic function in a position where a format string indicates
that c_str()'s return type is desired, provide a note suggesting that the user
may have intended to call the c_str() member.
Factor the non-POD-vararg checking out of DefaultVariadicArgumentPromotion and
move it to SemaChecking in order to facilitate this. Factor the call checking
out of function call checking and block call checking, and extend it to cover
constructor calls too.
Patch by Sam Panzer!
llvm-svn: 158887
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
* Escaped "::" and "<" as needed in Doxygen comments;
* Marked up code examples with \code...\endcode;
* Documented a \param that is current, instead of a few that aren't;
* Fixed up some \file and \brief comments.
llvm-svn: 158562
Richard Smith