decomposition declaration for arrays, aggregate-like structs, tuple-like
types, and (as an extension) for complex and vector types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@278435 91177308-0d34-0410-b5e6-96231b3b80d8
decomposition declarations.
There are a couple of things in the wording that seem strange here:
decomposition declarations are permitted at namespace scope (which we partially
support here) and they are permitted as the declaration in a template (which we
reject).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276492 91177308-0d34-0410-b5e6-96231b3b80d8
they're redeclarations. This is necessary in order for name lookup to correctly
find the most recent declaration of the name (which affects default template
argument lookup and cross-module merging, among other things).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@275612 91177308-0d34-0410-b5e6-96231b3b80d8
ArrayRef is a little better than passing around a pointer/length pair.
No functional change is intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274601 91177308-0d34-0410-b5e6-96231b3b80d8
Reverts r273305 and re-instates r273296.
We needed to fix a bug in Sema::MarkVTableUsed to ensure that operator
delete lookup occurs when the vtable is referenced. We already had a
special case to look up operator delete when dllimport was used, but I
think should really mark virtual destructors referenced any time the
vtable is used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274147 91177308-0d34-0410-b5e6-96231b3b80d8
constructor would be; this is effectively required by P0136R1. This has the
effect of exposing the validity of the base class initialization steps to
SFINAE checks.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274088 91177308-0d34-0410-b5e6-96231b3b80d8
Replace inheriting constructors implementation with new approach, voted into
C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited
base class constructor, we make the constructors of the base class visible to
constructor lookup in the derived class, using the normal rules for
using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived
class that tracks the requisite additional information. We create shadow
constructors (not found by name lookup) in the derived class to model the
actual initialization, and have a new expression node,
CXXInheritedCtorInitExpr, to model the initialization of a base class from such
a constructor. (This initialization is special because it performs real perfect
forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls,
variadic calls, and calls with callee parameter cleanup), the shadow inheriting
constructor is not emitted and instead we directly emit the initialization code
into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some
corner cases. In particular:
* if B inherits a private constructor from A, and C uses that constructor to
construct a B, then we previously required that A befriends B and B
befriends C, but the new rules require A to befriend C directly, and
* if a derived class has its own constructors (and so its implicit default
constructor is suppressed), it may still inherit a default constructor from
a base class
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274049 91177308-0d34-0410-b5e6-96231b3b80d8
variable weak discardable linkage and partially-ordered initialization, and is
implied for constexpr static data members.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273754 91177308-0d34-0410-b5e6-96231b3b80d8
-Wfor-loop-analysis warnings for a for-loop with a condition variable. In such
a case, the loop condition variable is modified on each iteration of the loop
by definition.
Original commit message:
Rearrange condition handling so that semantic checks on a condition variable
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273600 91177308-0d34-0410-b5e6-96231b3b80d8
are performed before the other substatements of the construct are parsed,
rather than deferring them until the end. This allows better error recovery
from semantic errors in the condition, improves diagnostic order, and is a
prerequisite for C++17 constexpr if.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@273548 91177308-0d34-0410-b5e6-96231b3b80d8
Clang doesn't dllexport defaulted special member function defaulted
inside class but does it if they defaulted outside class. MSVC doesn't
make any distinction where they were defaulted. Also MSVC 2013 and 2015
export different set of members. MSVC2015 doesn't emit trivial defaulted
x-tors but does emit copy assign operator.
Differential revision: http://reviews.llvm.org/D20422
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@270535 91177308-0d34-0410-b5e6-96231b3b80d8
Clang creates implicit move constructor/assign operator in all cases if
there is std=c++11. But MSVC supports such generation starting from
version 1900 only. As result we have some binary incompatibility.
Differential Revision: http://reviews.llvm.org/D19156
Patch by Andrew V. Tischenko
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269400 91177308-0d34-0410-b5e6-96231b3b80d8
a base class via a using-declaration. If a class has a using-declaration
declaring either a constructor or an assignment operator, eagerly declare its
special members in case they need to displace a shadow declaration from a
using-declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269398 91177308-0d34-0410-b5e6-96231b3b80d8
This is in preparation for C++ P0136R1, which switches the model for inheriting
constructors over from synthesizing a constructor to finding base class
constructors (via using shadow decls) when looking for derived class
constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@269231 91177308-0d34-0410-b5e6-96231b3b80d8
* an unscoped enumerator whose enumeration is a class member is itself a class
member, so can only be the subject of a class-scope using-declaration.
* a scoped enumerator cannot be the subject of a class-scope using-declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@268594 91177308-0d34-0410-b5e6-96231b3b80d8
with a prior UsingDecl -- those should not even really be found by the lookup
here, except that we use the same lookup results for two different checks, and
the other check needs them.
This happens to work in *almost all* cases, because either the lookup results
list the UsingDecl first (and the NonTag result gets replaced by something
else) or because the problematic declaration is a function (which causes us to
use different logic to detect conflicts). This can also be triggered from a
state only reachable through modules (where the name lookup results can contain
multiple UsingDecls in the same scope).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262105 91177308-0d34-0410-b5e6-96231b3b80d8
Relands r260194 with a fix. If we have a template that transitions from
an extern template to an explicitly instantiated dllexport template, we
would add that class to the delayed exported class list without flushing
it.
For explicit instantiations, we can just flush the list of delayed
classes immediately. We don't have to worry about the bug fixed in
r260194 in this case because explicit instantiations can only occur at
file and namespace scope.
Fixes PR26490.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@262056 91177308-0d34-0410-b5e6-96231b3b80d8
Per C++14 [class.virtual]p8, it is OK for the return type's class type
to be incomplete so long as the return type is the same between the base
and complete classes.
This fixes PR26297.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258768 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257254 91177308-0d34-0410-b5e6-96231b3b80d8
The MS ABI emits a special default constructor closure thunk if a
default constructor has a weird calling convention or default arguments.
The MS ABI has a quirk: there can be only one such thunk because the
mangling scheme does not have room for distinct manglings. We must
raise a diagnostic in this eventuality.
N.B. MSVC sorta gets this right. Multiple default constructors result
in the default constructor closure getting emitted but they seem to
get confused by which default constructors are reasonable to reference
from the closure. We try to be a little more careful which results in
mild differences in behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256661 91177308-0d34-0410-b5e6-96231b3b80d8
declaration. This fixes an issue where we would reject (due to a claimed
ambiguity) a case where lookup finds multiple NamespaceAliasDecls from
different scopes that nominate the same namespace.
The C++ standard doesn't make it clear that such a case is in fact valid (which
I'm working on fixing), but there are no relevant rules that distinguish using
declarations and namespace alias declarations here, so it makes sense to treat
them the same way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256601 91177308-0d34-0410-b5e6-96231b3b80d8
underlying decls. Preserve the found declaration throughout, and only map to
the underlying declaration when we want to check whether it's the right kind.
This allows us to provide the right source location for the found declaration,
and prepares for the possibility of underlying decls with a different name
from the found decl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256575 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes PR16677. The latter represents the case when due to
misprinted character class definition occurs in the scope of template
arguments. Base class of this class depends on the template parameter in the
same scope and cannot be resolved, it causes crash. Right behavior is to
make semantic processing even if the definition is wrong, as the code
that emits appropriate message is called after the processing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256511 91177308-0d34-0410-b5e6-96231b3b80d8
is complete (with an error produced if not) and a function that merely queries
whether the type is complete. Either way we'll trigger instantiation if
necessary, but only the former will diagnose and recover from missing module
imports.
The intent of this change is to prevent a class of bugs where code would call
RequireCompleteType(..., 0) and then ignore the result. With modules, we must
check the return value and use it to determine whether the definition of the
type is visible.
This also fixes a debug info quality issue: calls to isCompleteType do not
trigger the emission of debug information for a type in limited-debug-info
mode. This allows us to avoid emitting debug information for type definitions
in more cases where we believe it is safe to do so.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256049 91177308-0d34-0410-b5e6-96231b3b80d8
for the derived class into it. This is mostly just a cleanup, but could in
principle be a bugfix if there is some codepath that reaches here and didn't
previously require a complete type (I couldn't find any such codepath, though).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256037 91177308-0d34-0410-b5e6-96231b3b80d8
do scope-based lookup when looking for redeclarations of them. Add some related
missing checks for the scope-based redeclaration lookup: properly filter the
list of found declarations to match the scope, and diagnose shadowing of a
template parameter name.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254663 91177308-0d34-0410-b5e6-96231b3b80d8
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253283 91177308-0d34-0410-b5e6-96231b3b80d8
declarations in redeclaration lookup. A declaration is now visible to
lookup if:
* It is visible (not in a module, or in an imported module), or
* We're doing redeclaration lookup and it's externally-visible, or
* We're doing typo correction and looking for unimported decls.
We now support multiple modules having different internal-linkage or no-linkage
definitions of the same name for all entities, not just for functions,
variables, and some typedefs. As previously, if multiple such entities are
visible, any attempt to use them will result in an ambiguity error.
This patch fixes the linkage calculation for a number of entities where we
previously didn't need to get it right (using-declarations, namespace aliases,
and so on). It also classifies enumerators as always having no linkage, which
is a slight deviation from the C++ standard's definition, but not an observable
change outside modules (this change is being discussed on the -core reflector
currently).
This also removes the prior special case for tag lookup, which made some cases
of this work, but also led to bizarre, bogus "must use 'struct' to refer to type
'Foo' in this scope" diagnostics in C++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252960 91177308-0d34-0410-b5e6-96231b3b80d8
Unqualified templated constructors cannot be friended and our lack of a
diagnostic led to violated invariants. Instead, raise a diagnostic when
processing the friend declaration.
This fixes PR20251.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248953 91177308-0d34-0410-b5e6-96231b3b80d8
Such declarations would be invalid anyway, and trying to make the
correction will lead to a crash. Fixes PR 24781.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248928 91177308-0d34-0410-b5e6-96231b3b80d8
for an existing entity, and as such a using-declaration doesn't need to
conflict with a hidden entity (nor vice versa).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247654 91177308-0d34-0410-b5e6-96231b3b80d8
whether it can ever produce a constant expression in the case where it has a
void return type and no return statements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@246347 91177308-0d34-0410-b5e6-96231b3b80d8
This enables Clang to correctly handle code such as:
struct __declspec(dllexport) S {
int x = 42;
};
where it would otherwise error due to trying to generate the default
constructor before the in-class initializer for x has been parsed.
Differential Revision: http://reviews.llvm.org/D11850
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245139 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us pass functors (and lambdas) without void * tricks. On the
downside we can't pass CXXRecordDecl's Find* members (which are now type
safe) to lookupInBases directly, but a lambda trampoline is a small
price to pay. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243217 91177308-0d34-0410-b5e6-96231b3b80d8
The pattern was born out of the lack of range-based for loops in C++98
and is somewhat obscure. No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241300 91177308-0d34-0410-b5e6-96231b3b80d8
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8
This is a follow-up to r225570 which enabled adding DLL attributes when a
class template goes from explicit instantiation declaration to explicit
instantiation definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239375 91177308-0d34-0410-b5e6-96231b3b80d8
It is safe to add a dll attribute if the base class template previously only had
an explicit instantiation declaration, or was implicitly instantiated.
I both those cases, the members would not have been codegenned yet. In the case
of explicit instantiation declaration this is natural, and for implicit
instantiations, codegen is deferred (see r225570).
This is work towards fixing PR23770.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239373 91177308-0d34-0410-b5e6-96231b3b80d8
Don't warn about not being able to propagate dll attribute to a base class template
when that base already has a different attribute.
MSVC doesn't actually try to do this; the first attribute that was propagated
takes precedence, so Clang is already doing the right thing and there's no
need to warn.
(This is a step towards fixing PR21718.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239372 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we wouldn't call checkDLLAttribute() after the class template
specialization definition if the class template was already instantiated
by an explicit class template specialization declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238266 91177308-0d34-0410-b5e6-96231b3b80d8
The method wasn't an overrider but didn't have 'virtual' textually
written because our CXXMethodDecl was an out-of-line definition. Make
sure we use the canonical decl instead.
This fixes PR23629.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237999 91177308-0d34-0410-b5e6-96231b3b80d8
We now use an enum which maps the marketing name (almost always a year)
to the major version number.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236967 91177308-0d34-0410-b5e6-96231b3b80d8
This affects this test case:
void foo();
template <typename T> class C {
friend inline void foo();
};
inline void foo() {}
C<int> c;
Here, we instantiate the foo friend decl and add it to foo's redecl
chain. However, our previous decl pointer happens to reference the first
declaration of foo, which is not marked inline. When we check to see if
foo was already defined, we implicitly search all previous decls. We
should do the same for the inline check, instead of just checking this
particular previous decl.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D8872
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234374 91177308-0d34-0410-b5e6-96231b3b80d8
constructors, instead of having the typo-correction code also dispatch to the
inheriting constructor special case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@233833 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we would error out on this code because the default argument
wasn't parsed until the end of Outer:
struct __declspec(dllexport) Outer {
struct __declspec(dllexport) Inner {
Inner(void *p = 0);
};
};
Now we do the checking on the closing brace of Outer instead of Inner.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232519 91177308-0d34-0410-b5e6-96231b3b80d8
Using declarations which are aliases to struct types have their name
used as the struct type's name for linkage purposes. Otherwise, make
sure to give an anonymous struct defined inside a using declaration a
mangling number to disambiguate it from other anonymous structs in the
same context.
This fixes PR22809.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231909 91177308-0d34-0410-b5e6-96231b3b80d8
The exception object should be unqualified. Using a qualified exception
object results in the wrong copy constructor getting called when the
catch handler executes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231054 91177308-0d34-0410-b5e6-96231b3b80d8
dynamic classes in the translation unit and check whether each one's key
function is defined when we got to the end of the TU (and when we got to the
end of each module). This is really terrible for modules performance, since it
causes unnecessary deserialization of every dynamic class in every compilation.
We now use a much simpler (and, in a modules build, vastly more efficient)
system: when we see an out-of-line definition of a virtual function, we check
whether that function was in fact its class's key function. (If so, we need to
emit the vtable.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230830 91177308-0d34-0410-b5e6-96231b3b80d8
bug is not actually modules-specific, but it's a little tricky to tickle it
outside of modules builds, so submitting with the reduced testcase I have.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230303 91177308-0d34-0410-b5e6-96231b3b80d8
This is only a problem in C++03 mode targeting MS ABI (MinGW doesn't
export inline methods, and C++11 marks these methods implicitly
deleted).
Since targeting the MS ABI in pre-C++11 mode is a rare configuration,
this will probably not get fixed, but we can at least have a better
error message.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230115 91177308-0d34-0410-b5e6-96231b3b80d8
MinGW neither imports nor exports such methods. The import bit was
committed earlier, in r221154, and this takes care of the export part.
This also partially fixes PR22591.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@229922 91177308-0d34-0410-b5e6-96231b3b80d8
Parser::ParseLexedMethodDeclaration: Use local var for Param
Sema::MergeCXXFunctionDecls: Use hasInheritedDefaultArg
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227577 91177308-0d34-0410-b5e6-96231b3b80d8
clang currently calls MarkVTableUsed() for classes that get their virtual
methods called or that participate in a dynamic_cast. This is unnecessary,
since CodeGen only emits vtables when it generates constructor, destructor, and
vtt code. (*)
Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable.
Its main user-visible effect is that it instantiates virtual member functions
of template classes, to make sure that if codegen decides to write a vtable
all the entries in the vtable are defined.
While this shouldn't change the behavior of codegen (other than being faster),
it does make clang more permissive: virtual methods of templates (in particular
destructors) end up being instantiated less often. In particular, classes that
have members that are smart pointers to incomplete types will now get their
implicit virtual destructor instantiated less frequently. For example, this
used to not compile but does now compile:
template <typename T> struct OwnPtr {
~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); }
};
class ScriptLoader;
struct Base { virtual ~Base(); };
struct Sub : public Base {
virtual void someFun() const {}
OwnPtr<ScriptLoader> m_loader;
};
void f(Sub *s) { s->someFun(); }
The more permissive behavior matches both gcc (where this is not often
observable, since in practice most things with virtual methods have a key
function, and Sema::DefineUsedVTables() skips vtables for classes with key
functions) and cl (which is my motivation for this change) – this fixes
PR20337. See this issue and the review thread for some discussions about
optimizations.
This is similar to r213109 in spirit. r225761 was a prerequisite for this
change.
Various tests relied on "a->f()" marking a's vtable as used (in the sema
sense), switch these to just construct a on the stack. This forces
instantiation of the implicit constructor, which will mark the vtable as used.
(*) The exception is -fapple-kext mode: In this mode, qualified calls to
virtual functions (`a->Base::f()`) still go through the vtable, and since the
vtable pointer off this doesn't point to Base's vtable, this needs to reference
Base's vtable directly. To keep this working, keep referencing the vtable for
virtual calls in apple kext mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@227073 91177308-0d34-0410-b5e6-96231b3b80d8
Clang would previously become confused and crash here.
It does not make a lot of sense to export these, so warning seems appropriate.
MSVC will export some member functions for this kind of specializations, whereas
MinGW ignores the dllexport-edness. The latter behaviour seems better.
Differential Revision: http://reviews.llvm.org/D6984
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226208 91177308-0d34-0410-b5e6-96231b3b80d8
Sema calls HandleVTable() with a bool parameter which is then threaded through
three layers. The only effect of this bool is an early return at the last
layer.
Instead, remove this parameter and call HandleVTable() only if the bool is
true. No intended behavior change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226096 91177308-0d34-0410-b5e6-96231b3b80d8
We'd crash trying to make the SourceRange for the tokens we'd like to
highlight. Don't assume there is more than one token makes up the
default argument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225774 91177308-0d34-0410-b5e6-96231b3b80d8
This code was written with the intent that a pointer could be null but
we dyn_cast'd it anyway. Change the dyn_cast to a dyn_cast_or_null.
This fixes PR21933.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224411 91177308-0d34-0410-b5e6-96231b3b80d8
Update the comments to make it more clear what's going on, and address
Richard's comments from PR21718. This doesn't fix that bug, but hopefully
makes the code easier to understand.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224303 91177308-0d34-0410-b5e6-96231b3b80d8
We would crash trying to treat a property member as a field. These
shoudl be forbidden anyway, reject programs which contain them.
This fixes PR21840.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@224193 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, when we have this situation:
struct A {
template <typename T> struct B {
int m1 = sizeof(A);
};
B<int> m2;
};
We can't parse m1's initializer eagerly because we need A to be
complete. Therefore we wait until the end of A's class scope to parse
it. However, we can trigger instantiation of B before the end of A,
which will attempt to instantiate the field decls eagerly, and it would
build a bad field decl instantiation that said it had an initializer but
actually lacked one.
Fixed by deferring instantiation of default member initializers until
they are needed during constructor analysis. This addresses a long
standing FIXME in the code.
Fixes PR19195.
Reviewed By: rsmith
Differential Revision: http://reviews.llvm.org/D5690
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222192 91177308-0d34-0410-b5e6-96231b3b80d8
Without this, -Wunused-local-typedef would incorrectly warn on the two typedefs
in this program:
void foo() {
struct A {};
struct B : public A {
typedef A INHERITED;
B() : INHERITED() {}
typedef B SELF;
B(int) : SELF() {}
};
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221765 91177308-0d34-0410-b5e6-96231b3b80d8
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
This is a re-commit of r219977:
r219977 was reverted in r220038 because it hit a wrong-code bug in GCC 4.7.2.
(That's gcc.gnu.org/PR56135, and affects any implicit lambda-capture of
'this' within a template.)
r219977 was a re-commit of r217995, r218011, and r218053:
r217995 was reverted in r218058 because it hit a rejects-valid bug in MSVC.
(Incorrect overload resolution in the presence of using-declarations.)
It was re-committed in r219977 with a workaround for the MSVC rejects-valid.
r218011 was a workaround for an MSVC parser bug. (Incorrect desugaring of
unbraced range-based for loop).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221750 91177308-0d34-0410-b5e6-96231b3b80d8
Trying to import or export such classes doesn't make sense, and Clang
would assert trying to export vtables for them.
This is consistent with how we treat functions with internal linkage,
but it is stricter than MSVC so we may have to back down if it breaks
real code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221160 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that MinGW never dllimports of exports inline functions.
This means that code compiled with Clang would fail to link with
MinGW-compiled libraries since we might try to import functions that
are not imported.
To fix this, make Clang never dllimport inline functions when targeting
MinGW.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221154 91177308-0d34-0410-b5e6-96231b3b80d8
If a templated class is not instantiated, then the AST for it could be missing
some things that would throw the field checker off. Wait until specialization
before emitting these warnings.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@220363 91177308-0d34-0410-b5e6-96231b3b80d8
reverted in r218058 because they triggered a rejects-valid bug in MSVC.
Original commit message from r217995:
Instantiate exception specifications when instantiating function types (other
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@219977 91177308-0d34-0410-b5e6-96231b3b80d8
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218969 91177308-0d34-0410-b5e6-96231b3b80d8
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218925 91177308-0d34-0410-b5e6-96231b3b80d8
to recover from parse error parsing the default
argument. Patch prevents crash after spewing 100s
of errors caused by someone who forgot to compile in c++11
mode. So no test. rdar://18508589
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218780 91177308-0d34-0410-b5e6-96231b3b80d8
Get the record handling code from SelfReferenceChecker into
UninitializedFieldVisitor as well as copying the testcases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218740 91177308-0d34-0410-b5e6-96231b3b80d8
As PR20495 demonstrates, Clang currenlty infers the CUDA target (host/device,
etc) for implicit members (constructors, etc.) incorrectly. This causes errors
and even assertions in Clang when compiling code (assertions in C++11 mode where
implicit move constructors are added into the mix).
Fix the problem by inferring the target from the methods the implicit member
should call (depending on its base classes and fields).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218624 91177308-0d34-0410-b5e6-96231b3b80d8
r218053: Use exceptions() instead of getNumExceptions()/getExceptionType() to avoid
r218011: Work around MSVC parser bug by putting redundant braces around the body of
r217997: Skip parens when detecting whether we're instantiating a function declaration.
r217995: Instantiate exception specifications when instantiating function types (other
The Windows build was broken for 16 hours and no one had any good ideas of how to
fix it. Reverting for now to make the builders green. See the cfe-commits thread [1] for
more info.
This was the build error (from [2]):
C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1590) : error C2668: '`anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType' : ambiguous call to overloaded function
C:\bb-win7\ninja-clang-i686-msc17-R\llvm-project\clang\lib\Sema\SemaTemplateInstantiate.cpp(1313): could be 'clang::QualType `anonymous-namespace'::TemplateInstantiator::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)'
with
[
Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>
]
c:\bb-win7\ninja-clang-i686-msc17-r\llvm-project\clang\lib\sema\TreeTransform.h(4532): or 'clang::QualType clang::TreeTransform<Derived>::TransformFunctionProtoType<clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>>(clang::TypeLocBuilder &,clang::FunctionProtoTypeLoc,clang::CXXRecordDecl *,unsigned int,Fn)'
with
[
Derived=`anonymous-namespace'::TemplateInstantiator,
Fn=clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>
]
while trying to match the argument list '(clang::TypeLocBuilder, clang::FunctionProtoTypeLoc, clang::CXXRecordDecl *, unsigned int, clang::Sema::SubstFunctionDeclType::<lambda_756edcbe7bd5c7584849a6e3a1491735>)'
1. http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140915/115011.html
2. http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/10515/steps/build_clang_tools_1/logs/stdio
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218058 91177308-0d34-0410-b5e6-96231b3b80d8
than the type of a function declaration). We previously didn't instantiate
these at all! This also covers the pathological case where the only mention of
a parameter pack is within the exception specification; this gives us a second
way (other than alias templates) to reach the horrible state where a type
contains an unexpanded pack, but its canonical type does not.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217995 91177308-0d34-0410-b5e6-96231b3b80d8
merging of namespace aliases across modules and improves source fidelity.
Incidentally also fixes PR20816.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217103 91177308-0d34-0410-b5e6-96231b3b80d8
In line with SemaOpenMP.cpp, etc. CUDA-specific semantic analysis code goes into
a separate file. This is in anticipation of adding extra functionality here in
the near future.
No change in functionality.
Review: http://reviews.llvm.org/D5160
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@217043 91177308-0d34-0410-b5e6-96231b3b80d8
don't mark the field as initialized until the next initializer instead of
instantly. Since this checker is AST based, statements are processed in tree
order instead of following code flow. This can result in different warnings
from just reordering the code. Also changed to use one checker per constructor
instead of creating a new checker per field.
class T {
int x, y;
// Already warns
T(bool b) : x(!b ? (1 + y) : (y = 5)) {}
// New warning added here, previously (1 + y) comes after (y = 5) in the AST
// preventing the warning.
T(bool b) : x(b ? (y = 5) : (1 + y)) {}
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216641 91177308-0d34-0410-b5e6-96231b3b80d8
Fix r216438 to catch more complicated self-initialized in std::move. For
instance, "Foo f = std::move(cond ? OtherFoo : (UNUSED_VALUE, f));"
Make sure that BinaryConditionalOperator, ConditionalOperator, BinaryOperator
with comma operator, and OpaqueValueExpr perform the correct usage forwarding
across the three uninitialized value checkers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216627 91177308-0d34-0410-b5e6-96231b3b80d8
pattern of an alias template declaration. Use this to merge alias templates
properly when they're members of class template specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216437 91177308-0d34-0410-b5e6-96231b3b80d8
We would previously assert (a decl cannot have two DLL attributes) on this code:
template <typename T> struct __declspec(dllimport) S { T f() { return T(); } };
template struct __declspec(dllexport) S<int>;
The problem was that when instantiating, we would take the attribute from the
template even if the instantiation itself already had an attribute.
Also, don't inherit DLL attributes from the template to its members before
instantiation, as the attribute may change.
I couldn't figure out what MinGW does here, so I'm leaving that open. At least
we're not asserting anymore.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216340 91177308-0d34-0410-b5e6-96231b3b80d8
Normally we mark all members of exported classes referenced to get them emitted.
However, MSVC doesn't do this for class templates that are implicitly specialized or
just have an explicit instantiation declaration. For such specializations, the members
are emitted when referenced.
The exception is the case when the dllexport attribute is propagated from a base class
to a base class template that doesn't have an explicit attribute: in this case all
methods of the base class template do get instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@216145 91177308-0d34-0410-b5e6-96231b3b80d8
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215982 91177308-0d34-0410-b5e6-96231b3b80d8
FunctionProtoType::ExtProtoInfo. Most of the users of these fields don't care
about the other ExtProtoInfo bits and just want to talk about the exception
specification.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@214450 91177308-0d34-0410-b5e6-96231b3b80d8
If function parameters have default values, and that of the second
parameter is parsed with errors, function declaration would have
a parameter without default value that follows a parameter with
that. Such declaration breaks logic of selecting overloaded
function. As a solution, put opaque object as default value in such case.
This patch fixes PR20055.
Differential Revision: http://reviews.llvm.org/D4378
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213594 91177308-0d34-0410-b5e6-96231b3b80d8
ExtWarn/Warnings. Mostly the name of the warning was changed to match the
semantics, but in the PR20356 cases, the warning was about valid code, so the
diagnostic was changed from ExtWarn to Warning instead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213443 91177308-0d34-0410-b5e6-96231b3b80d8
I don't think other implicit members like copy assignment and move
assignment require this treatment, because they should already be
operating on a constructed object.
Fixes PR20351.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213346 91177308-0d34-0410-b5e6-96231b3b80d8
-- a constructor list initialization that unpacked an initializer list into
constructor arguments and
-- a list initialization that created as std::initializer_list and passed it
as the first argument to a constructor
in the AST. Use this flag while instantiating templates to provide the right
semantics for the resulting initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213224 91177308-0d34-0410-b5e6-96231b3b80d8
We would silently accept volatile ~S() when the user probably intended
to write virtual ~S().
This fixes PR20238.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212555 91177308-0d34-0410-b5e6-96231b3b80d8
This source range is useful for all kinds of diagnostic QOI and refactoring
work, so let's make it more discoverable.
This commit also makes use of the new function to enhance various diagnostics
relating to return types and resolves an old FIXME.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@212154 91177308-0d34-0410-b5e6-96231b3b80d8
Consider the following code:
template <typename T> class Base {};
class __declspec(dllexport) class Derived : public Base<int> {}
When the base of an exported or imported class is a class template
specialization, MSVC will propagate the dll attribute to the base.
In the example code, Base<int> becomes a dllexported class.
This commit makes Clang do the proopagation when the base hasn't been
instantiated yet, and warns about it being unsupported otherwise.
This is different from MSVC, which allows changing a specialization
back and forth between dllimport and dllexport and seems to let the
last one win. Changing the dll attribute after instantiation would be
hard for us, and doesn't seem to come up in practice, so I think this
is a reasonable limitation to have.
MinGW doesn't do this kind of propagation.
Differential Revision: http://reviews.llvm.org/D4264
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211725 91177308-0d34-0410-b5e6-96231b3b80d8
When adding the implicit compound statement (required for Codegen?), the
end location was previously overridden by the start location, probably
based on the assumptions:
* The location of the compound statement should be the member's location
* The compound statement if present is the last element of a FunctionDecl
This patch changes the location of the compound statement to the
member's end location.
Code review: http://reviews.llvm.org/D4175
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211344 91177308-0d34-0410-b5e6-96231b3b80d8
The compilation pipeline doesn't actually need to know about the high-level
concept of diagnostic mappings, and hiding the final computed level presents
several simplifications and other potential benefits.
The only exceptions are opportunistic checks to see whether expensive code
paths can be avoided for diagnostics that are guaranteed to be ignored at a
certain SourceLocation.
This commit formalizes that invariant by introducing and using
DiagnosticsEngine::isIgnored() in place of individual level checks throughout
lex, parse and sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@211005 91177308-0d34-0410-b5e6-96231b3b80d8
CRTP-like patterns involve a class which inherits from another class
using itself as a template parameter.
However, the base class itself may try to create a pointer-to-member
which involves the derived class. This is problematic because we
may not have finished parsing the most derived classes' base specifiers
yet.
It turns out that MSVC simply uses the unspecified inheritance model
instead of doing anything fancy.
This fixes PR19987.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210886 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would do the access check from the context of
MarkVTableUsed.
Also update this test to C++11, since that is typically used with the MS
C++ ABI.
Fixes PR20005.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210850 91177308-0d34-0410-b5e6-96231b3b80d8
Current MSVC versions don't have move assignment operators, so we
can't rely on them being available in the dll. If we have the
definition, we can just use that directly. This breaks pointer
equality, but should work fine otherwise.
When there is an MSVC version that supports move assignment,
we can key this off the -fmsc-ver option.
http://reviews.llvm.org/D4105
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210715 91177308-0d34-0410-b5e6-96231b3b80d8
We would previously end up with an error when instantiating the
following template:
template <typename> struct __declspec(dllimport) S {
void foo() = delete;
};
S<int> s;
error: attribute 'dllimport' cannot be applied to a deleted function
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210550 91177308-0d34-0410-b5e6-96231b3b80d8
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210498 91177308-0d34-0410-b5e6-96231b3b80d8
function parameter. One of our existing test cases was XFAILed because
of this. This fixes the issue and un-XFAILs the test.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@210026 91177308-0d34-0410-b5e6-96231b3b80d8
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209908 91177308-0d34-0410-b5e6-96231b3b80d8
These note diags have the same message and can be unified further but for now
let's just bring them together.
Incidental change: Display a source range in the final attr diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209728 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith