This commit fixes a bug that's tracked by PR 10758 and duplicates like PR 30343.
The bug causes clang to crash with a stack overflow while recursing infinitely
trying to perform copy-initialization on a type without a copy constructor but
with a constructor that accepts another type that can be constructed using the
original type.
The commit fixes this bug by detecting the recursive behavior and failing
correctly with an appropriate error message. It also tries to provide a
meaningful diagnostic note about the constructor which leads to this behavior.
rdar://28483944
Differential Revision: https://reviews.llvm.org/D25051
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@303156 91177308-0d34-0410-b5e6-96231b3b80d8
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226410 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)
Included a few FIXMEs in tests where some further improvements could be
made.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201038 91177308-0d34-0410-b5e6-96231b3b80d8
Without this patch, record decls with invalid out-of-line method delcs would
sometimes be marked invalid, but not always. With this patch, they are
consistently never marked invalid.
(The code to do this was added in
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100809/033154.html
, but the test from that revision is still passing.)
As far as I can tell, this was the only place where a class was marked invalid
after its definition was complete.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197848 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178088 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164366 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we relied on the presence of a member which needs no initialization
to prevent us from creating an additional initialization of the outer anonymous
union field. We have already correctly marked that field as initialized by the
member of the union (repeatedly due to the original bug this patch fixes) so we
simply need to bail out.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107242 91177308-0d34-0410-b5e6-96231b3b80d8
anonymous union under the presumption that they didn't do anything. While this
is true, our checks for redundant initialization of an anonymous union still
fire when these overlap with explicit user initialization. A cleaner approach
is to avoid initializing multiple members of a union altogether, but this still
is in a rather fuzzy are especially when C++0x allows non-POD types into
unions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107235 91177308-0d34-0410-b5e6-96231b3b80d8
member. Use a better diagnostic for this case. Also fix a bug with nested
anonymous structs/unions for -Wreorder; this last was PR6575.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100923 91177308-0d34-0410-b5e6-96231b3b80d8
when they're instantiated. Merge the note into the -Wreorder warning; it
doesn't really contribute much, and it was splitting a thought across diagnostics
anyway. Don't crash in the parser when a constructor's initializers end in a
comma and there's no body; the recovery here is still terrible, but anything's
better than a crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100922 91177308-0d34-0410-b5e6-96231b3b80d8
Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100880 91177308-0d34-0410-b5e6-96231b3b80d8
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98149 91177308-0d34-0410-b5e6-96231b3b80d8
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@94952 91177308-0d34-0410-b5e6-96231b3b80d8
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93277 91177308-0d34-0410-b5e6-96231b3b80d8
as parts of overload sets. Also, refer to constructors as 'constructors'
rather than functions.
Adjust a lot of tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92832 91177308-0d34-0410-b5e6-96231b3b80d8
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91446 91177308-0d34-0410-b5e6-96231b3b80d8
and implicitly defined constructors. This has a number of benefits:
1. Less code.
2. Explicit and implicit constructors get the same diagnostics.
3. The AST explicitly contains constructor calls from implicit default
constructors. This allows handing some cases that previously weren't handled
correctly in IRGen without any additional code. Specifically, implicit default
constructors containing calls to constructors with default arguments are now
handled correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86500 91177308-0d34-0410-b5e6-96231b3b80d8
class C {
C() { }
int a;
};
C::C() : a(10) { }
We also diagnose when initializers are used on declarations that aren't constructors:
t.cpp:1:10: error: only constructors take base initializers
void f() : a(10) { }
^
Doug and/or Sebastian: I'd appreciate a review, especially the nested-name-spec test results (from the looks of it we now match gcc in that test.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67672 91177308-0d34-0410-b5e6-96231b3b80d8
information about types. We often print diagnostics where we say
"foo_t" is bad, but the user doesn't know how foo_t is declared
(because it is a typedef). Fix this by expanding sugar when present
in a diagnostic (and not one of a few special cases, like vectors).
Before:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' and 'typeof(F)')
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
After:
t.m:5:2: error: invalid operands to binary expression ('typeof(P)' (aka 'struct mystruct') and 'typeof(F)' (aka 'float'))
MAX(P, F);
^~~~~~~~~
t.m:1:78: note: instantiated from:
#define MAX(A,B) ({ __typeof__(A) __a = (A); __typeof__(B) __b = (B); __a < __b ? __b : __a; })
^
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65081 91177308-0d34-0410-b5e6-96231b3b80d8
Alex Lorenz