trivial if the implicit declaration would be. Don't forget to set the Trivial
flag on the special member as well as on the class. It doesn't seem ideal that
we have two separate mechanisms for storing this information, but this patch
does not attempt to address that.
This leaves us in an interesting position where the has_trivial_X trait for a
class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'.
This seems to be what the standard requires.
llvm-svn: 151465
function, provide a specialized diagnostic that indicates the kind of
special member function (default constructor, copy assignment
operator, etc.) and that it was implicitly deleted. Add a hook where
we can provide more detailed information later.
llvm-svn: 150611
o Correct the handling of the restrictions on usage of cv-qualified and
ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
arguments, due to such arguments not being treated as a template type arg
context.
o Remove the ExtWarn for usage of such types as template arguments; that was
a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
code for diagnosing ref-qualifiers.
llvm-svn: 150244
to an error, so that users can turn them off if necessary. Note that
this does *not* change the behavior of in a SFINAE context, where we
still flag an error even if the warning is disabled. This matches
GCC's behavior.
llvm-svn: 148701
for it to be used in converted constant expression checking, and fix a couple
of issues:
- Conversion operators implicitly invoked prior to the narrowing conversion
were not being correctly handled when determining whether a constant value
was narrowed.
- For conversions from floating-point to integral types, the diagnostic text
incorrectly always claimed that the source expression was not a constant
expression.
llvm-svn: 148381
zero-initialize the first union member. Also fix a bug where initializing an
array of types compatible with wchar_t from a wide string literal failed in C,
and fortify the C++ tests in this area. This part can't be tested without a code
change to enable array evaluation in C (where an existing test fails).
llvm-svn: 148035
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
Add test that a variadic base list which expands to 0 bases doesn't make the
class a non-aggregate. This test passed before the change, too.
llvm-svn: 142411
initializer to update the type of the declaration. For example, this
allows us to determine the size of an incomplete array from its
initializer. Fixes PR10288.
llvm-svn: 141543
conversion function whose result type is an lvalue reference. The
initialization code already handled this properly, but overload
resolution was allowing the binding. Fixes PR11003 /
<rdar://problem/10233078>.
llvm-svn: 141137
- This fixes a host of obscure bugs with regards to how warning mapping options composed with one another, and I believe makes the code substantially easier to read and reason about.
llvm-svn: 140770
This makes the code duplication of implicit special member handling even worse,
but the cleanup will have to come later. For now, this works.
Follow-up with tests for explicit defaulting and enabling the __has_feature
flag to come.
llvm-svn: 138821
qualification of a type doesn't affect whether a conversion is a narrowing
conversion.
This doesn't work in template cases because SubstTemplateTypeParmType gets in
the way.
llvm-svn: 138735
[dcl.init.list] as is possible without generalized initializer lists or full
constant expression support, and adds a c++0x-compat warning in C++98 mode.
The FixIt currently uses a typedef's basename without qualification, which is
likely to be incorrect on some code. If it's incorrect on too much code, we
should write a function to get the string that refers to a type from a
particular context.
The warning is currently off by default. I'll fix LLVM and clang before turning
it on.
llvm-svn: 136181
Revert "For C++11, do more checking of initializer lists up-front, enabling some subset of the final functionality. C just leaves the function early. C++98 runs through the same code path, but has no changed functionality either."
This reverts commit ac420c5053d6aa41d59f782caad9e46e5baaf2c2.
llvm-svn: 135210
This is a first baby step towards supporting generalized initializer lists. This also removes an aggregate
test case that was just plain wrong, assuming that non-aggregates couldn't be initialized with initializer lists
in C++11 mode.
llvm-svn: 135177
should use a constructor to default-initialize a
variable. InitializationSequence knows the rules for default
initialization, better. Fixes <rdar://problem/8501008>.
llvm-svn: 131796
* 'auto' was being rejected on abstract-declarators with trailing return
types and on typedefs with trailing return types. 'auto' is always
allowed in these cases. This was found while testing the fix for PR 9278.
* A very poor diagnostic was being issued for auto (f() -> int): "return
type must be 'auto', not 'auto'". This is closely related to PR 9060.
* Trailing return type handling was happening slightly too late,
resulting in the checks for functions returning arrays and functions
returning functions being missed.
llvm-svn: 126166
- Add ref-qualifiers to the type system; they are part of the
canonical type. Print & profile ref-qualifiers
- Translate the ref-qualifier from the Declarator chunk for
functions to the function type.
- Diagnose mis-uses of ref-qualifiers w.r.t. static member
functions, free functions, constructors, destructors, etc.
- Add serialization and deserialization of ref-qualifiers.
llvm-svn: 124281
implementation used by overload resolution to support rvalue
references. The original commits caused PR9026 and some
hard-to-reproduce self-host breakage.
The only (crucial!) difference between this commit and the previous
commits is that we now properly check the SuppressUserConversions flag
before attempting to perform a second user-defined conversion in
reference binding, breaking the infinite recursion chain of
user-defined conversions.
Rvalue references should be working a bit better now.
llvm-svn: 124121
resolution to match the latest C++0x working paper's semantics. The
implementation now matching up with the reference-binding
implementation used for initialization.
llvm-svn: 123977
specification. In particular, an rvalue reference can bind to an
initializer expression that is an lvalue if the referent type and the
initializer expression type are not reference-related. This is a newer
formulation to the previous "rvalue references can never bind to
lvalues" rule.
llvm-svn: 123952
working paper's structure. The only functional change here is that we
now handling binding to array rvalues, which we would previously reject.
llvm-svn: 123918
involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.
llvm-svn: 123913
1) Declaration of function parameter packs
2) Instantiation of function parameter packs within function types.
3) Template argument deduction of function parameter packs when
matching two function types.
We're missing all of the important template-instantiation logic for
function template definitions, along with template argument deduction
from the argument list of a function call, so don't even think of
trying to use these for real yet.
llvm-svn: 122926
Richard Smith