| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
to the ambiguity, rather than noting all viable candidates.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initializers.
This has some interesting interactions with our existing extensions to
support C99 designated initializers as an extension in C++. Those are
resolved as follows:
* We continue to permit the full breadth of C99 designated initializers
in C++, with the exception that we disallow a partial overwrite of an
initializer with a non-trivially-destructible type. (Full overwrite
is OK, because we won't run the first initializer at all.)
* The C99 extensions are disallowed in SFINAE contexts and during
overload resolution, where they could change the meaning of valid
programs.
* C++20 disallows reordering of initializers. We only check for that for
the simple cases that the C++20 rules permit (designators of the form
'.field_name =' and continue to allow reordering in other cases).
It would be nice to improve this behavior in future.
* All C99 designated initializer extensions produce a warning by
default in C++20 mode. People are going to learn the C++ rules based
on what Clang diagnoses, so it's important we diagnose these properly
by default.
* In C++ <= 17, we apply the C++20 rules rather than the C99 rules, and
so still diagnose C99 extensions as described above. We continue to
accept designated C++20-compatible initializers in C++ <= 17 silently
by default (but naturally still reject under -pedantic-errors).
This is not a complete implementation of P0329R4. In particular, that
paper introduces new non-C99-compatible syntax { .field { init } }, and
we do not support that yet.
This is based on a previous patch by Don Hinton, though I've made
substantial changes when addressing the above interactions.
Differential Revision: https://reviews.llvm.org/D59754
llvm-svn: 370544
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This change fixes a crash on initialization of a reference from ({}) during
template instantiation and incidentally improves diagnostics.
This reverts a prior attempt to handle this in r286721. Instead, we teach the
initialization code that initialization cannot be performed if a source type
is required and the initializer is an initializer list (which is not an
expression and does not have a type), and likewise for function-style cast
expressions.
llvm-svn: 298676
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy-initialization. We previously got this wrong in a couple of ways:
- we only looked for copy / move constructors and constructor templates for
this copy, and thus would fail to copy in cases where doing so should use
some other constructor (but see core issue 670),
- we mishandled the special case for disabling user-defined conversions that
blocks infinite recursion through repeated application of a copy constructor
(applying it in slightly too many cases) -- though as far as I can tell,
this does not ever actually affect the result of overload resolution, and
- we misapplied the special-case rules for constructors taking a parameter
whose type is a (reference to) the same class type by incorrectly assuming
that only happens for copy/move constructors (it also happens for
constructors instantiated from templates and those inherited from base
classes).
These changes should only affect strange corner cases (for instance, where the
copy constructor exists but has a non-const-qualified parameter type), so for
the most part it only causes us to produce more 'candidate' notes, but see the
test changes for other cases whose behavior is affected.
llvm-svn: 280776
|
| |
|
|
|
|
|
|
| |
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
llvm-svn: 228896
|
| |
|
|
| |
llvm-svn: 228654
|
| |
|
|
|
|
| |
overlooked a few things, but this implementation comes straight from the DR resolution itself.
llvm-svn: 227224
|
| |
|
|
|
|
|
|
|
| |
elements from {}, rather than value-initializing them. This permits calling an
initializer-list constructor or constructing a std::initializer_list object.
(It would also permit initializing a const reference or rvalue reference if
that weren't explicitly prohibited by other rules.)
llvm-svn: 210091
|
| |
|
|
|
|
|
|
|
|
| |
just the extremely specific case of a trailing array element that couldn't be
initialized because the default constructor for the element type is deleted.
Also reword the diagnostic to better match our other context diagnostics and to
prepare for the implementation of core issue 1070.
llvm-svn: 210083
|
| |
|
|
|
|
| |
deleted default constructor
llvm-svn: 209869
|
| |
|
|
|
|
|
|
|
| |
The conventional form is '<action> to silence this warning'.
Also call the diagnostic an 'issue' rather than a 'message' because the latter
term is more widely used with reference to message expressions.
llvm-svn: 209052
|
| |
|
|
|
|
|
|
|
| |
caused us to perform copy-initialization for the parameters of an allocation
function called by a new-expression multiple times, resulting in us rejecting
allocations that passed non-copyable parameters (and much worse things in
MSVC compat mode, where we potentially called this function multiple times).
llvm-svn: 208724
|
| |
|
|
| |
llvm-svn: 174337
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
actually perform value initialization rather than trying to fake it with a call
to the default constructor. Fixes various bugs related to the previously-missing
zero-initialization in this case.
I've also moved this and the other list initialization 'special case' from
TryConstructorInitialization into TryListInitialization where they belong.
llvm-svn: 159733
|
| |
|
|
|
|
|
|
| |
incomplete type, keep track of the actual type that was
incomplete. Otherwise, we might fail to produce a diagnostic. Fixes
PR12498.
llvm-svn: 154432
|
| |
|
|
| |
llvm-svn: 153849
|
| |
|
|
| |
llvm-svn: 153523
|
| |
|
|
| |
llvm-svn: 153130
|
| |
|
|
|
|
| |
CXXTemporaryObjectExprs, not just CXXConstructExprs, which have a worrying tendency to vanish. Fixes PR12167.
llvm-svn: 152340
|
| |
|
|
|
|
| |
existing tests still pass, but there may still be corner cases.
llvm-svn: 151716
|
| |
|
|
| |
llvm-svn: 151577
|
| |
|
|
|
|
| |
direct member initializers.
llvm-svn: 151155
|
| |
|
|
|
|
| |
functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary.
llvm-svn: 150408
|
| |
|
|
|
|
| |
initialization edge cases.
llvm-svn: 150342
|
| |
|
|
|
|
|
|
| |
thing in cases involving array new.
Show that many cases using initializer list constructors work, in that they parse and pass semantic analysis.
llvm-svn: 150316
|
| |
|
|
| |
llvm-svn: 147156
|
| |
|
|
|
|
| |
expressoins of the form T{args}.
llvm-svn: 147155
|
|
|
overloading, initializer_list.
llvm-svn: 147145
|
