Both Richard and I felt that the current wording in the working paper needed some tweaking - Please see http://llvm-reviews.chandlerc.com/D2035 for additional context and references to core-reflector messages that discuss wording tweaks.
What is implemented is what we had intended to specify in Bristol; but, recently felt that the specification might benefit from some tweaking and fleshing.
As a rough attempt to explain the semantics: If a nested lambda with a default-capture names a variable within its body, and if the enclosing full expression that contains the name of that variable is instantiation-dependent - then an enclosing lambda that is capture-ready (i.e. within a non-dependent context) must capture that variable, if all intervening nested lambdas can potentially capture that variable if they need to, and all intervening parent lambdas of the capture-ready lambda can and do capture the variable.
Of note, 'this' capturing is also currently underspecified in the working paper for generic lambdas. What is implemented here is if the set of candidate functions in a nested generic lambda includes both static and non-static member functions (regardless of viability checking - i.e. num and type of parameters/arguments) - and if all intervening nested-inner lambdas between the capture-ready lambda and the function-call containing nested lambda can capture 'this' and if all enclosing lambdas of the capture-ready lambda can capture 'this', then 'this' is speculatively captured by that capture-ready lambda.
Hopefully a paper for the C++ committee (that Richard and I had started some preliminary work on) is forthcoming.
This essentially makes generic lambdas feature complete, except for known bugs. The more prominent ones (and the ones I am currently aware of) being:
- generic lambdas and init-captures are broken - but a patch that fixes this is already in the works ...
- nested variadic expansions such as:
auto K = [](auto ... OuterArgs) {
vp([=](auto ... Is) {
decltype(OuterArgs) OA = OuterArgs;
return 0;
}(5)...);
return 0;
};
auto M = K('a', ' ', 1, " -- ", 3.14);
currently cause crashes. I think I know how to fix this (since I had done so in my initial implementation) - but it will probably take some work and back & forth with Doug and Richard.
A warm thanks to all who provided feedback - and especially to Doug Gregor and Richard Smith for their pivotal guidance: their insight and prestidigitation in such matters is boundless!
Now let's hope this commit doesn't upset the buildbot gods ;)
Thanks!
llvm-svn: 194188
would be deleted are still declared, but are ignored by overload resolution.
Also, don't delete such members if a subobject has no corresponding move
operation and a non-trivial copy. This causes us to implicitly declare move
operations in more cases, but risks move-assigning virtual bases multiple
times in some circumstances (a warning for that is to follow).
llvm-svn: 193969
Summary: Some MS headers use these features.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1948
llvm-svn: 192936
This is a fix to PR12778: in erroneous code an allocation function
can be declared with no arguments, quering the first argument in this case
causes assertion violation.
llvm-svn: 190751
Summary:
__uuidof on templated types should exmaine if any of its template
parameters have a uuid declspec. If exactly one does, then take it.
Otherwise, issue an appropriate error.
Reviewers: rsmith, thakis, rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1419
llvm-svn: 190240
In addition to storing more useful information in the AST, this
fixes a semantic check in template instantiation which checks whether
the l-paren location is valid.
Fixes PR16903.
llvm-svn: 188495
global allocation or deallocation function, that should not cause that global
allocation or deallocation function to become unavailable.
llvm-svn: 186270
clang would incorrectly not allow the following:
int x = true ? (throw 1) : 2;
The problem exists because we don't see beyond the parens.
This, in turn, causes us to believe that we are choosing between void
and int which we diagnose as an error.
Instead, allow clang to see the 'throw' inside the parens.
llvm-svn: 183085
* Treat _Atomic(T) as a literal type if T is a literal type.
* Evaluate expressions of this type properly.
* Fix a lurking bug where we built completely bogus ASTs for converting to
_Atomic types in C++ in some cases, caught by the tests for this change.
llvm-svn: 182541
common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.
This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.
llvm-svn: 182406
to use. This makes very little difference right now (other than suppressing
follow-on errors in some cases), but will matter more once we support deduced
return types (we don't want expressions with undeduced return types in the
AST).
llvm-svn: 181107
the actual parser and support arbitrary id-expressions.
We're actually basically set up to do arbitrary expressions here
if we wanted to.
Assembly operands permit things like A::x to be written regardless
of language mode, which forces us to embellish the evaluation
context logic somewhat. The logic here under template instantiation
is incorrect; we need to preserve the fact that an expression was
unevaluated. Of course, template instantiation in general is fishy
here because we have no way of delaying semantic analysis in the
MC parser. It's all just fishy.
I've also fixed the serialization of MS asm statements.
This commit depends on an LLVM commit.
llvm-svn: 180976
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
llvm-svn: 180789
Add a CapturedStmt.h similar to Lambda.h to reduce the typing required to get
to the CapturedRegionKind enum. This also allows codegen to access this enum
without including Sema/ScopeInfo.h.
Also removes some duplicated code for capturing 'this' between CapturedStmt and
Lambda.
Differential Revision: http://llvm-reviews.chandlerc.com/D712
llvm-svn: 180710
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
Add CapturedDecl to be the DeclContext for CapturedStmt, and perform semantic
analysis. Currently captures all variables by reference.
TODO: templates
Author: Ben Langmuir <ben.langmuir@intel.com>
Differential Revision: http://llvm-reviews.chandlerc.com/D433
llvm-svn: 179618
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
MarkMemberReferenced instead of marking functions referenced directly. An audit
of callers to MarkFunctionReferenced and DiagnoseUseOfDecl also caused a few
other changes:
* don't mark functions odr-used when considering them for an initialization
sequence. Do mark them referenced though.
* the function nominated by the cleanup attribute should be diagnosed.
* operator new/delete should be diagnosed when building a 'new' expression.
llvm-svn: 174951
expressions which have undefined behavior due to multiple unsequenced
modifications or an unsequenced modification and use of a variable.
llvm-svn: 172690
ActOnFinishFullExpr that some of its checks only apply to discarded-value
expressions. This adds missing checks for unexpanded variadic template
parameter packs to a handful of constructs.
llvm-svn: 172485
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
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
initialization, don't rebuild it. Remove a couple of hacks which were trying to
work around this. Fix the special case for one-argument CXXConstructExprs to
not apply if the one argument is a default argument.
llvm-svn: 168582
It may become a dangling pointer if the underlying SmallVector reallocates.
Sadly the testcase is really large and doesn't reduce well because of
SmallVector's reallocation patterns.
Fixes PR14336.
llvm-svn: 168045
Spent longer than reasonable looking for a nice way to test this & decided to
give up for now. Open to suggestions/requests. Richard Smith suggested adding
something to ASTMatchers but it wasn't readily apparent how to test this with
that.
llvm-svn: 167507
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
integral promotions to both its underlying type and to its underlying type's
promoted type. This matters now that boolean conversions aren't permitted in
converted constant expressions (a la DR1407): an enumerator with a fixed
underlying type of bool still can be.
llvm-svn: 163841
A couple of missing "RequireNonAbstractType" calls in conditional operator
handling. I looked for opportunities to tie this check in to all relevant
callers of PerformCopyInitialization (couldn't be all callers since this is
called for base subobject copying too, where it's acceptable to copy abstract
types) but the callers varied too much & in many cases had substantial code
or conditionals on the RequireNonAbstractType call, the
PerformCopyInitialization call, or the code between the two calls.
llvm-svn: 163555
A conditional operator between glvalues of types cv1 T and cv2 T produces a
glvalue if the expressions are of the same value kind and one of cv1 and cv2
is a subset of the other.
A conditional operator between two null pointer constants is permitted if one
of them is of type std::nullptr_t.
llvm-svn: 161476
and the other is a glvalue of class type, don't forget to copy-initialize a
temporary when performing the lvalue-to-rvalue conversion on the glvalue.
Strangely, DefaultLvalueConversions misses this part of the lvalue-to-rvalue
conversions.
llvm-svn: 161450
expressions to have complete return types (or accessible destructors). If the
return type is required to be complete for some other reason (for instance, if
it is needed by overload resolution), then it will still be required to be
complete. This is apparently required in order to parse a MSVC11 header.
llvm-svn: 160924
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
type traits that assignment to/construction of a lifetime-qualified
object under ARC is *not* trivial. Fixes <rdar://problem/11738725>.
llvm-svn: 159401
* Escaped "::" and "<" as needed in Doxygen comments;
* Marked up code examples with \code...\endcode;
* Documented a \param that is current, instead of a few that aren't;
* Fixed up some \file and \brief comments.
llvm-svn: 158562
This improves the conversion diagnostics (by correctly pointing to the loop
construct for conversions that may've been caused by the contextual conversion
to bool caused by a condition expression) and also causes the NULL conversion
warnings to be correctly suppressed when crossing a macro boundary in such a
context. (previously, since the conversion context location was incorrect, the
suppression could not be performed)
Reported by Nico Weber as feedback to r156826.
llvm-svn: 156901
Sema::ConvertToIntegralOrEnumerationType() from PartialDiagnostics to
abstract "diagnoser" classes. Not much of a win here, but we're
-several PartialDiagnostics.
llvm-svn: 156217
off PartialDiagnostic. PartialDiagnostic is rather heavyweight for
something that is in the critical path and is rarely used. So, switch
over to an abstract-class-based callback mechanism that delays most of
the work until a diagnostic is actually produced. Good for ~11k code
size reduction in the compiler and 1% speedup in -fsyntax-only on the
code in <rdar://problem/11004361>.
llvm-svn: 156176
being used in an exception specification in a way which isn't otherwise
ill-formed in C++98: this warning also incorrectly triggered on uses of 'this'
inside thread-safety attributes, and the mechanism required to tell these cases
apart is more complex than can be justified by the (minimal) value of this part
of -Wc++98-compat.
llvm-svn: 155857
We have a new flavor of exception specification, EST_Uninstantiated. A function
type with this exception specification carries a pointer to a FunctionDecl, and
the exception specification for that FunctionDecl is instantiated (if needed)
and used in the place of the function type's exception specification.
When a function template declaration with a non-trivial exception specification
is instantiated, the specialization's exception specification is set to this
new 'uninstantiated' kind rather than being instantiated immediately.
Expr::CanThrow has migrated onto Sema, so it can instantiate exception specs
on-demand. Also, any odr-use of a function triggers the instantiation of its
exception specification (the exception specification could be needed by IRGen).
In passing, fix two places where a DeclRefExpr was created but the corresponding
function was not actually marked odr-used. We used to get away with this, but
don't any more.
Also fix a bug where instantiating an exception specification which refers to
function parameters resulted in a crash. We still have the same bug in default
arguments, which I'll be looking into next.
This, plus a tiny patch to fix libstdc++'s common_type, is enough for clang to
parse (and, in very limited testing, support) all of libstdc++4.7's standard
headers.
llvm-svn: 154886
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
llvm-svn: 154799
in general (such an atomic has boolean representation) and
specifically for IR generation of __c11_atomic_init. The latter also
means actually using initialization semantics for this initialization,
rather than just creating a store.
On a related note, make sure we actually put in non-atomic-to-atomic
conversions when performing an implicit conversion sequence. IR
generation is far too kind here, but we still want the ASTs to make
sense.
llvm-svn: 154612
- The [class.protected] restriction is non-trivial for any instance
member, even if the access lacks an object (for example, if it's
a pointer-to-member constant). In this case, it is equivalent to
requiring the naming class to equal the context class.
- The [class.protected] restriction applies to accesses to constructors
and destructors. A protected constructor or destructor can only be
used to create or destroy a base subobject, as a direct result.
- Several places were dropping or misapplying object information.
The standard could really be much clearer about what the object type is
supposed to be in some of these accesses. Usually it's easy enough to
find a reasonable answer, but still, the standard makes a very confident
statement about accesses to instance members only being possible in
either pointer-to-member literals or member access expressions, which
just completely ignores concepts like constructor and destructor
calls, using declarations, unevaluated field references, etc.
llvm-svn: 154248
track whether the referenced declaration comes from an enclosing
local context. I'm amenable to suggestions about the exact meaning
of this bit.
llvm-svn: 152491
- getSourceRange().getBegin() is about as awesome a pattern as .copy().size().
I already killed the hot paths so this doesn't seem to impact performance on my
tests-of-the-day, but it is a much more sensible (and shorter) pattern.
llvm-svn: 152419
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed.
llvm-svn: 151797
- variant members with nontrivial destructors make the containing class's
destructor deleted
- check for a virtual destructor after checking for overridden methods in the
base class(es)
- check for an inaccessible operator delete for a class with a virtual
destructor.
Do not try to call an anonymous union field's destructor from the destructor of
the containing class.
llvm-svn: 151483
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
llvm-svn: 151352
function call (or a comma expression with a function call on its right-hand
side), possibly parenthesized, then the return type is not required to be
complete and a temporary is not bound. Other subexpressions inside a decltype
expression do not get this treatment.
This is implemented by deferring the relevant checks for all calls immediately
within a decltype expression, then, when the expression is fully-parsed,
checking the relevant constraints and stripping off any top-level temporary
binding.
Deferring the completion of the return type exposed a bug in overload
resolution where completion of the argument types was not attempted, which
is also fixed by this change.
llvm-svn: 151117
eliminating a bunch of redundant code and properly modeling how the
captures of outside blocks/lambdas affect the types seen by inner
captures.
This new scheme makes two passes over the capturing scope stack. The
first pass goes up the stack (from innermost to outermost), assessing
whether the capture looks feasible and stopping when it either hits
the scope where the variable is declared or when it finds an existing
capture. The second pass then walks down the stack (from outermost to
innermost), capturing the variable at each step and updating the
captured type and the type that an expression referring to that
captured variable would see. It also checks type-specific
restrictions, such as the inability to capture an array within a
block. Note that only the first odr-use of each
variable needs to do the full walk; subsequent uses will find the
capture immediately, so multiple walks need not occur.
The same routine that builds the captures can also compute the type of
the captures without signaling errors and without actually performing
the capture. This functionality is used to determine the type of
declaration references as well as implementing the weird decltype((x))
rule within lambda expressions.
The capture code now explicitly takes sides in the debate over C++
core issue 1249, which concerns the type of captures within nested
lambdas. We opt to use the more permissive, more useful definition
implemented by GCC rather than the one implemented by EDG.
llvm-svn: 150875
We had two separate issues here: firstly, varions functions were assuming that
they did not need to perform semantic checks on trivial destructors (this is
not true in C++11, where a trivial destructor can nonetheless be private or
deleted), and a bunch of DiagnoseUseOfDecl calls were missing for uses of
destructors.
llvm-svn: 150866
Holding the constructor directly makes no sense when list-initialized arrays come into play. The constructor is now held in a CXXConstructExpr, if construction is what is done. The new design can also distinguish properly between list-initialization and direct-initialization, as well as implicit default-initialization constructors and explicit value-initialization constructors. Finally, doing it this way removes redundance from the AST because CXXNewExpr doesn't try to handle both the allocation and the initialization responsibilities.
This breaks the static analysis of new expressions. I've filed PR12014 to track this.
llvm-svn: 150682
default is '=', and reword the warning about explicitly capturing
'this' in such lambdas to indicate that only explicit capture is
banned.
Introduce Fix-Its for this and other "save the programmer from
themself" rules regarding what can be explicitly captured and what
must be implicitly captured.
llvm-svn: 150256
David Blaikie