| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
used constructor itself."
It leads to a compiler crash in the Bullet benchmark.
This reverts commit r12014.
llvm-svn: 150684
|
|
|
|
|
|
|
|
|
|
| |
constructor itself.
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
|
|
|
|
|
|
| |
functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary.
llvm-svn: 150408
|
|
|
|
|
|
| |
expressions. Array new still missing.
llvm-svn: 150346
|
|
|
|
|
|
| |
double-check that this is correct.)
llvm-svn: 150292
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
file. No functionality change.
llvm-svn: 150089
|
|
|
|
|
|
| |
body of the lambda to the function call operator.
llvm-svn: 150087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Capturing variables by-reference and by-copy within a lambda
- The representation of lambda captures
- The creation of the non-static data members in the lambda class
that store the captured variables
- The initialization of the non-static data members from the
captured variables
- Pretty-printing lambda expressions
There are a number of FIXMEs, both explicit and implied, including:
- Creating a field for a capture of 'this'
- Improved diagnostics for initialization failures when capturing
variables by copy
- Dealing with temporaries created during said initialization
- Template instantiation
- AST (de-)serialization
- Binding and returning the lambda expression; turning it into a
proper temporary
- Lots and lots of semantic constraints
- Parameter pack captures
llvm-svn: 149977
|
|
|
|
|
|
| |
process removed some naming ambiguities.
llvm-svn: 149870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
|
|
|
|
|
|
|
| |
array new expression. This lays some groundwork for the implicit conversion to
integral or unscoped enumeration which C++11 ICEs undergo.
llvm-svn: 149772
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
new, is well-formed with defined semantics of throwing (a type which can be
caught by a handler for) std::bad_array_new_length, unlike in C++98 where it is
somewhere nebulous between undefined behavior and ill-formed.
If the array size is an integral constant expression and satisfies one of these
criteria, we would previous the array new expression, but now in C++11 mode, we
merely issue a warning (the code is still rejected in C++98 mode, naturally).
We don't yet implement new C++11 semantics correctly (see PR11644), but we do
implement the overflow checking, and (for the default operator new) convert such
expressions to an exception, so accepting such code now does not seem especially
unsafe.
llvm-svn: 149767
|
|
|
|
|
|
| |
allocator is given the pointer to allocate into.
llvm-svn: 149760
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
llvm-svn: 149735
|
|
|
|
| |
llvm-svn: 149719
|
|
|
|
|
|
| |
Still left: explicit captures in lambdas need to cause implicit capture, and I need to take a look at the diagnostics for some cases.
llvm-svn: 149718
|
|
|
|
|
|
| |
will be necessary to handle references to captured variables.
llvm-svn: 149660
|
|
|
|
|
|
| |
C++11 rules.
llvm-svn: 149641
|
|
|
|
|
|
| |
additional entry points are needed to implement C++11 odr-use marking correctly. No functional change in this patch; I'll actually make the change which fixes the odr-use marking in a followup patch.
llvm-svn: 149586
|
|
|
|
| |
llvm-svn: 149517
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cleans up and improves a few things:
- We get rid of the ugly dance of computing all of the captures in
data structures that clone those of CapturingScopeInfo, centralizing
the logic for accessing/updating these data structures
- We re-use the existing capture logic for 'this', which actually
works now.
Cleaned up some diagnostic wording in minor ways as well.
llvm-svn: 149516
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Actually building the var -> capture mapping properly (there was an off-by-one error)
- Keeping track of the source location of each capture
- Minor QoI improvements, e.g, highlighing the prior capture if
there are multiple captures, pointing at the variable declaration we
found if we reject it.
As part of this, add standard citations for the various semantic
checks we perform, and note where we're not performing those checks as
we should.
llvm-svn: 149462
|
|
|
|
| |
llvm-svn: 149458
|
|
|
|
| |
llvm-svn: 149127
|
|
|
|
|
|
|
| |
canonical type directly and adding a fast path for the common case
that the type is directly a RecordType.
llvm-svn: 149039
|
|
|
|
|
|
| |
lvalue-to-rvalue conversion.
llvm-svn: 149003
|
|
|
|
| |
llvm-svn: 148921
|
|
|
|
| |
llvm-svn: 148920
|
|
|
|
|
|
| |
PR11833.
llvm-svn: 148893
|
|
|
|
|
|
| |
lvalue-to-rvalue conversion.
llvm-svn: 148874
|
|
|
|
|
|
|
| |
allocator to construct an object which declares more alignment than the default
allocator actually provides. Fixes PR9527!
llvm-svn: 148857
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 148683
|
|
|
|
|
|
| |
This matches cl.exe's behavior and fixes PR11791.
llvm-svn: 148682
|
|
|
|
|
|
| |
appropriate.
llvm-svn: 148673
|
|
|
|
|
|
| |
and less error-prone way of handling the relevant cases. Towards marking of whether a declaration is used more accurately.
llvm-svn: 148522
|
|
|
|
|
|
|
|
|
|
|
|
| |
No new unit tests yet as there is no behavioral change
(except for slightly more specific filtering in
Sema::ActOnStartOfLambdaDefinition). Tests will be added
as the code paths are traced in greater depth to determine
how to improve the results--there are at least one or two
known bugs that require those improvements. This commit
lays the groundwork for those changes.
llvm-svn: 148382
|
|
|
|
|
|
| |
appropriate or when GCC requires it)
llvm-svn: 148292
|
|
|
|
|
|
| |
declaration which is used is marked as used.
llvm-svn: 148253
|
|
|
|
|
|
|
|
| |
expression for an Objective-C object or pointer type, so that we don't
attempt to treat the member name as a template. Fixes
<rdar://problem/10672501>.
llvm-svn: 148028
|
|
|
|
|
|
| |
shared between lambda expressions and block literals.
llvm-svn: 147917
|
|
|
|
|
|
| |
new-expressions.
llvm-svn: 147900
|
|
|
|
|
|
| |
complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)
llvm-svn: 147723
|
|
|
|
|
|
| |
This patch (and some of my other commits related to lambdas) is heavily based off of John Freeman's work-in-progress patches.
llvm-svn: 147706
|
|
|
|
|
|
| |
lambda parameters work correctly, recording more information into the AST.
llvm-svn: 147650
|
|
|
|
|
|
| |
pieces to build the lambda class and its call operator. Create an actual scope for the lambda body.
llvm-svn: 147595
|
|
|
|
|
|
| |
BlockLiteralContext. Use it to ensure semantic analysis of types isn't confused by the lack of a type specifier.
llvm-svn: 147522
|
|
|
|
|
|
| |
use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet.
llvm-svn: 147515
|
|
|
|
|
|
| |
Reviewed by Eli Friedman.
llvm-svn: 146738
|