explicit conversion functions to initialize the argument to a
copy/move constructor that itself is the subject of direct
initialization. Since we don't have that much context in overload
resolution, we end up threading more flags :(.
Fixes <rdar://problem/10903741> / PR10456.
llvm-svn: 151409
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
arguments. There are two aspects to this:
- Make sure that when marking the declarations referenced in a
default argument, we don't try to mark local variables, both because
it's a waste of time and because the semantics are wrong: we're not
in a place where we could capture these variables again even if it
did make sense.
- When a lambda expression occurs in a default argument of a
function template, make sure that the corresponding closure type is
considered dependent, so that it will get properly instantiated. The
second bit is a bit of a hack; to fix it properly, we may have to
rearchitect our handling of default arguments, parsing them only
after creating the function definition. However, I'd like to
separate that work from the lambdas work.
llvm-svn: 151076
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:
(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.
llvm-svn: 151011
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
even if they are not within a function scope. Teach template
instantiation to treat them as such, and make sure that we have a
local instantiation scope when instantiating default arguments and
static data members.
llvm-svn: 150725
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
pointers and block pointers). We use dummy definitions to keep the
invariant that an implicit, used definition has a body; IR generation
will substitute the actual contents, since they can't be represented
as C++.
For the block pointer case, compute the copy-initialization needed to
capture the lambda object in the block, which IR generation will need
later.
llvm-svn: 150645
expression is referenced, defined, then referenced again, make sure we
instantiate it the second time it's referenced. This is the static data member
analogue of r150518.
llvm-svn: 150560
template is defined, and then the specialization is referenced again, don't
forget to instantiate the template on the second reference. Use the source
location of the first reference as the point of instantiation, though.
llvm-svn: 150518
expressions. This is mostly a simple refact, splitting the main "start
a lambda expression" function into smaller chunks that are driven
either from the parser (Sema::ActOnLambdaExpr) or during AST
transformation (TreeTransform::TransformLambdaExpr). A few minor
interesting points:
- Added new entry points for TreeTransform, so that we can
explicitly establish the link between the lambda closure type in the
template and the lambda closure type in the instantiation.
- Added a bit into LambdaExpr specifying whether it had an explicit
result type or not. We should have had this anyway.
This code is 'lightly' tested.
llvm-svn: 150417
id-expression 'x' will compute the type based on the assumption that
'x' will be captured, even if it isn't captured, per C++11
[expr.prim.lambda]p18. There are two related refactors that go into
implementing this:
1) Split out the check that determines whether we should capture a
particular variable reference, along with the computation of the
type of the field, from the actual act of capturing the
variable.
2) Always compute the result of decltype() within Sema, rather than
AST, because the decltype() computation is now context-sensitive.
llvm-svn: 150347
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
nested captures. We currently don't get odr-use correct in array
bounds, so that bit is commented out while we sort out what we need to
do.
llvm-svn: 150255
- Complete the lambda class when we finish the lambda expression
(previously, it was left in the "being completed" state)
- Actually return the LambdaExpr object and bind to the resulting
temporary when needed.
- Detect when cleanups are needed while capturing a variable into a
lambda (e.g., due to default arguments in the copy constructor), and
make sure those cleanups apply for the whole of the lambda
expression.
llvm-svn: 150123
only add 'const' for variables captured by copy in potentially
evaluated expressions of non-mutable lambdas. (The "by copy" part was
missing).
llvm-svn: 150088
a typedef of std::pair. This slightly improves type-safety, but mostly
makes code using it clearer to read as well as making it possible to add
methods to the type.
Add such a method for efficiently single-step desugaring a split type.
Add a method to single-step desugaring a locally-unqualified type.
Implement both the SplitQualType and QualType methods in terms of that.
Also, fix a typo ("ObjCGLifetime").
llvm-svn: 150028
- 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
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
- 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
Pass a typo correction callback object from ParseCastExpr to
Sema::ActOnIdExpression to be a bit more selective about what kinds of
corrections will be allowed for unknown identifiers.
llvm-svn: 148973
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
- Add atomic-to/from-nonatomic cast types
- Emit atomic operations for arithmetic on atomic types
- Emit non-atomic stores for initialisation of atomic types, but atomic stores and loads for every other store / load
- Add a __atomic_init() intrinsic which does a non-atomic store to an _Atomic() type. This is needed for the corresponding C11 stdatomic.h function.
- Enables the relevant __has_feature() checks. The feature isn't 100% complete yet, but it's done enough that we want people testing it.
Still to do:
- Make the arithmetic operations on atomic types (e.g. Atomic(int) foo = 1; foo++;) use the correct LLVM intrinsic if one exists, not a loop with a cmpxchg.
- Add a signal fence builtin
- Properly set the fenv state in atomic operations on floating point values
- Correctly handle things like _Atomic(_Complex double) which are too large for an atomic cmpxchg on some platforms (this requires working out what 'correctly' means in this context)
- Fix the many remaining corner cases
llvm-svn: 148242
not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.
llvm-svn: 148209
I was forced to change test/SemaCXX/linkage.cpp because we aren't actually modeling extern "C" in the AST the way that testcase expects; we were not printing a warning only because we skipped the relevant check. Someone who actually understands the semantics here should fix that.
llvm-svn: 148158
members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.
llvm-svn: 147023
Split out a new ExpressionEvaluationContext flag for this case, and don't treat
it as unevaluated in C++11. This fixes some crash-on-invalids where we would
allow references to class members in potentially-evaluated constant expressions
in static member functions, and also fixes half of PR10177.
The fix to PR10177 exposed a case where template instantiation failed to provide
a source location for a diagnostic, so TreeTransform has been tweaked to supply
source locations when transforming a type. The source location is still not very
good, but MarkDeclarationsReferencedInType would need to operate on a TypeLoc to
improve it further.
Also fix MarkDeclarationReferenced in C++98 mode to trigger instantiation for
static data members of class templates which are used in constant expressions.
This fixes a link-time problem, but we still incorrectly treat the member as
non-constant. The rest of the fix for that issue is blocked on PCH support for
early-instantiated static data members, which will be added in a subsequent
patch.
llvm-svn: 146955
to declaresSameEntity(), as a baby step toward tracking forward
declarations of Objective-C classes precisely. Part of
<rdar://problem/10583531>.
llvm-svn: 146618
whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.
The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.
llvm-svn: 146289
force the unknown any type to "id" so that the message send can be
completed without requiring a case. Fixes <rdar://problem/10506646>.
llvm-svn: 145552
Basically we have to look into the parent *lexical* DeclContext for friend functions at class scope. That's because calling GetParent() return the namespace or file DeclContext.
This fixes all remaining cases of "Unqualified lookup into dependent bases of class templates" when parsing MFC code with clang.
llvm-svn: 145127
pointer mismatch. Cases covered are: initialization, assignment, and function
arguments. Additional text will give the extra information about the nature
of the mismatch: different classes for member functions, wrong number of
parameters, different parameter type, different return type, and function
qualifier mismatch.
llvm-svn: 145114
This is a little bit tricky because during default argument instantiation the CurContext points to a CXXMethodDecl but we can't use the keyword this or have an implicit member call generated.
This fixes 2 errors when parsing MFC code with clang.
llvm-svn: 144881
property references to use a new PseudoObjectExpr
expression which pairs a syntactic form of the expression
with a set of semantic expressions implementing it.
This should significantly reduce the complexity required
elsewhere in the compiler to deal with these kinds of
expressions (e.g. IR generation's special l-value kind,
the static analyzer's Message abstraction), at the lower
cost of specifically dealing with the odd AST structure
of these expressions. It should also greatly simplify
efforts to implement similar language features in the
future, most notably Managed C++'s properties and indexed
properties.
Most of the effort here is in dealing with the various
clients of the AST. I've gone ahead and simplified the
ObjC rewriter's use of properties; other clients, like
IR-gen and the static analyzer, have all the old
complexity *and* all the new complexity, at least
temporarily. Many thanks to Ted for writing and advising
on the necessary changes to the static analyzer.
I've xfailed a small diagnostics regression in the static
analyzer at Ted's request.
llvm-svn: 143867
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
expressions: expressions which refer to a logical rather
than a physical l-value, where the logical object is
actually accessed via custom getter/setter code.
A subsequent patch will generalize the AST for these
so that arbitrary "implementing" sub-expressions can
be provided.
Right now the only client is ObjC properties, but
this should be generalizable to similar language
features, e.g. Managed C++'s __property methods.
llvm-svn: 142914
changed the return type of a compare of two unsigned vectors to be unsigned. This patch removes the check for hasIntegerRepresentation since its not needed and returns the appropriate signed type.
I added a new test case and updated exisiting test cases that assumed an unsigned result.
llvm-svn: 142250
through varargs. This only happens when we're in an unevaluated
context, where we don't want to trigger an error anyway. Fixes PR11131
/ <rdar://problem/10288375>.
llvm-svn: 141986
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
- Remodel Expr::EvaluateAsInt to behave like the other EvaluateAs* functions,
and add Expr::EvaluateKnownConstInt to capture the current fold-or-assert
behaviour.
- Factor out evaluation of bitfield bit widths.
- Fix a few places which would evaluate an expression twice: once to determine
whether it is a constant expression, then again to get the value.
llvm-svn: 141561
function type' when that expression is actually an overloaded function
reference (and not the address of an overloaded function
reference). Fixes PR11066.
llvm-svn: 141514
C-style and functional casts are built in SemaCXXCast.cpp.
Introduce a helper class to encapsulate most of the random
state being passed around, at least one level down.
llvm-svn: 141170
return to one which does not return (has noreturn attribute)
should warn as it is an unsafe assignment. // rdar://10095762
c++ already handles this. This is the c version.
llvm-svn: 141141
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: -(id)first:(int)x second:(int)y;
-With a space between the arguments: -(id)first: (int)x second: (int)y;
-For nullary selectors, immediately before ';': -(void)release;
In such cases we infer the locations instead of storing them.
llvm-svn: 140989
Instead of always storing all source locations for the selector identifiers
we check whether all the identifiers are in a "standard" position; "standard" position is
-Immediately before the arguments: [foo first:1 second:2]
-With a space between the arguments: [foo first: 1 second: 2]
-For nullary selectors, immediately before ']': [foo release]
In such cases we infer the locations instead of storing them.
llvm-svn: 140987
system change in <rdar://problem/10109725> that allows conversion from
'self' in class methods to the root of the class's hierarchy. This
conversion rule is a hack that has non-trivial repurcussions
(particularly with overload resolution).
llvm-svn: 140605
builds a semantic (structured) initializer list, just reports on whether it can match
the given list to the target type.
Use this mode for doing init list checking in the initial step of initialization, which
will eventually allow us to do overload resolution based on the outcome.
llvm-svn: 140457
This fixes a few errors when parsing MFC code with clang.
BTW clang trunk is now about 5 patches away to be able the parse the default wizard-generated MFC project.
llvm-svn: 140452
OpenCL 6.2.1 says: "Implicit conversions between built-in vector data types are
disallowed." OpenCL 6.2.2 says: "Explicit casts between vector types are not
legal." For example:
uint4 u = (uint4)(1);
int4 i = u; // invalid implicit conversion
int4 e = (int4)u; // invalid explicit conversion
Fixes PR10967. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140300
OpenCL is different from AltiVec in the way it supports vector literals. OpenCL
is strict with regards to semantic checks. For example, implicit conversions
and explicit casts between vectors of different types are disallowed.
Fixes PR10975. Submitted by: Anton Lokhmotov <Anton.lokhmotov@gmail.com>
llvm-svn: 140270
the lifetime of the block by copying it to the heap, or else we'll get
a dangling reference because the code working with the non-block-typed
object will not know it needs to copy.
There is some danger here, e.g. with assigning a block literal to an
unsafe variable, but, well, it's an unsafe variable.
llvm-svn: 139451
what 'nullPos' is supposed to mean, at least at this one site.
Use closed forms for the arithmetic. Rip out some clever but
ultimately pointless code that was trying to use 0 or 0L depending
the size of a pointer vs. the size of int; first, it didn't work
on LLP64 systems, and second, the sentinel checking code requires
a pointer-typed value anyway, so this fixit would not have actually
removed the warning.
llvm-svn: 139361
than conversions of C pointers to ObjC pointers. In order to ensure that
we've caught every case, add asserts to CastExpr that strictly determine
which cast kind is used for which kind of bit cast.
llvm-svn: 139352
builtin types (When requested). This is another step toward making
ASTUnit build the ASTContext as needed when loading an AST file,
rather than doing so after the fact. No actual functionality change (yet).
llvm-svn: 138985
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
llvm-svn: 138913
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
to varargs functions in unevaluated contexts. AFAICT, there is no
standards justification for this, but it matches what other compilers do
and therefore preserves compatibility with certain template metaprogramming
idioms.
Should fix self-host.
llvm-svn: 138715
Old warning:
warning: use of NULL in arithmetic operation [-Wnull-arithmetic]
return 10 <= NULL;
^ ~~~~
New warning:
warning: comparison between NULL and non-pointer ('int' and NULL) [-Wnull-arithmetic]
return 10 <= NULL;
~~ ^ ~~~~
llvm-svn: 137377
ASTContext with accessors/mutators. The only functional change is that
the AST writer won't bother writing the id/Class/SEL redefinition type
if it hasn't been explicitly set; previously, it ended up being
written as a synonym for the built-in id/Class/SEL.
llvm-svn: 137349
Eli Friedman