| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch reduces duplication in the template argument deduction code
for handling deduction from initializer lists in a function call. This
extends the fix for PR12119 to also apply to the case where the
corresponding parameter is a trailing parameter pack.
Test Plan:
A test for deduction from nested initializer lists where the
corresponding parameter is a trailing parameter pack is added in
`clang/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp`.
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10681
llvm-svn: 240612
|
| |
|
|
|
|
|
|
| |
(or of a lambda init-capture, which is sort-of such a variable). The semantics
of such constructs will change when we implement N3922, so we intend to warn on
this in Clang 3.6 then change the semantics in Clang 3.7.
llvm-svn: 228792
|
| |
|
|
|
|
|
|
|
| |
list-initialization that gets converted to some form other than an
InitListExpr. CXXTemporaryObjectExpr is a special case here, because it
represents a fused CXXFunctionalCastExpr + CXXConstructExpr. That, in
itself, is probably a design error...
llvm-svn: 227377
|
| |
|
|
|
|
|
|
|
|
|
|
| |
-- 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.
llvm-svn: 213224
|
| |
|
|
|
|
|
|
|
| |
constructor (and pass it an implicitly-generated std::initializer_list object),
be sure to mark the resulting construction as list-initialization. This fixes
an assert in template instantiation where we previously thought we'd got direct
non-list initialization without any parentheses.
llvm-svn: 213201
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 195384
|
| |
|
|
|
|
|
|
| |
initializer list containing a single element of type T, be sure to mark the
sequence as a list conversion sequence so that it is known to be worse than an
implicit conversion sequence that initializes a std::initializer_list object.
llvm-svn: 190115
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
building the resulting expression because it invokes a deleted constructor.
llvm-svn: 182624
|
| |
|
|
|
|
| |
in the one case where we've already factored out a reason code.
llvm-svn: 174036
|
| |
|
|
|
|
|
|
|
|
| |
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
llvm-svn: 169690
|
| |
|
|
| |
llvm-svn: 167506
|
| |
|
|
|
|
| |
sure to supply an initialization location. Fixes <rdar://problem/11951661>.
llvm-svn: 161084
|
| |
|
|
|
|
|
| |
std::initializer_list<T> so long as <T> is known. This conversion has
identity rank.
llvm-svn: 154065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be sure to perform the argument type adjustments in
[temp.deduct.call]p2, e.g., array decay.
And, when performing these deductions in the context of 'auto', make
sure that we're deducing the P' in std::initializer_list<P'> rather
than the whole initializer list.
Together, this makes code like
for( auto s : {"Deferred", "New", "Open", "Review"}) { }
work properly.
llvm-svn: 153998
|
| |
|
|
| |
llvm-svn: 152848
|
| |
|
|
|
|
| |
direct member initializers.
llvm-svn: 151155
|
| |
|
|
| |
llvm-svn: 150933
|
| |
|
|
|
|
| |
expressions. Array new still missing.
llvm-svn: 150346
|
| |
|
|
|
|
|
|
| |
Fix some review comments.
Add a test for deduction when std::initializer_list isn't available yet.
Fix redundant error messages. This fixes and outstanding FIXME too.
llvm-svn: 148735
|
| |
|
|
|
|
|
|
| |
support. This means you can now write:
for (int i : {1, 4, 512, 23, 251}) {}
llvm-svn: 148353
|
| |
|
|
|
|
| |
initializer lists.
llvm-svn: 148352
|
| |
|
|
| |
llvm-svn: 148350
|
|
|
This does not yet support CodeGen.
llvm-svn: 148349
|
