Richard Smith [Mon, 13 Feb 2012 03:54:03 +0000 (03:54 +0000)]
Update constexpr implementation to match CWG's chosen approach for core issues
1358, 1360, 1452 and 1453.
- Instantiations of constexpr functions are always constexpr. This removes the
need for separate declaration/definition checking, which is now gone.
- This makes it possible for a constexpr function to be virtual, if they are
only dependently virtual. Virtual calls to such functions are not constant
expressions.
- Likewise, it's now possible for a literal type to have virtual base classes.
A constexpr constructor for such a type cannot actually produce a constant
expression, though, so add a special-case diagnostic for a constructor call
to such a type rather than trying to evaluate it.
- Classes with trivial default constructors (for which value initialization can
produce a fully-initialized value) are considered literal types.
- Classes with volatile members are not literal types.
- constexpr constructors can be members of non-literal types. We do not yet use
static initialization for global objects constructed in this way.
Douglas Gregor [Sun, 12 Feb 2012 18:57:57 +0000 (18:57 +0000)]
Implement the standard decltype() semantics described in C++11
[dcl.type.simple]p4, which treats all xvalues as returning T&&. We had
previously implemented a pre-standard variant of decltype() that
doesn't cope with, e.g., static_ast<T&&>(e) very well.
Douglas Gregor [Sun, 12 Feb 2012 18:42:33 +0000 (18:42 +0000)]
Within the body of a lambda expression, decltype((x)) for an
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.
Sebastian Redl [Sun, 12 Feb 2012 16:37:36 +0000 (16:37 +0000)]
Change the way we store initialization kinds so that all direct inits can distinguish between list and parens form. This allows us to correctly diagnose the last test cases from litb.
r149987 changed the way parsing happens inside an @implementation;
it aggregates the declarations inside and reports them together as a DeclGroup.
This had the side effect that function declarations were reported together with
their definition, while the rewriter expected for function declarations to be
reported immediately to the consumer and thus not have a body.
Fix this by having the rewriter actually check with isThisDeclarationADefinition()
to make sure the body comes from the current decl before rewriting it.
Sebastian Redl [Sat, 11 Feb 2012 23:51:47 +0000 (23:51 +0000)]
Represent C++ direct initializers as ParenListExprs before semantic analysis
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.
Sebastian Redl [Sat, 11 Feb 2012 23:51:21 +0000 (23:51 +0000)]
Drive-by fix of incorrect diagnostic, and a test case for said diagnostic. The double error is unfortunate, but I really don't see an alternative whose effort is worth it.
Sebastian Redl [Sat, 11 Feb 2012 23:51:08 +0000 (23:51 +0000)]
Fix parsing new expressions using init lists. Probably still do the wrong thing in cases involving array new.
Show that many cases using initializer list constructors work, in that they parse and pass semantic analysis.
Anna Zaks [Sat, 11 Feb 2012 23:46:36 +0000 (23:46 +0000)]
[analyzer] Malloc Checker: reduce false negatives rate by assuming that
a pointer cannot escape through calls to system functions. Also, stop
after reporting the first use-after-free.
Anna Zaks [Sat, 11 Feb 2012 21:44:39 +0000 (21:44 +0000)]
[analyzer] Malloc Checker: Report a leak when we are returning freed
memory.
(As per one test case, the existing checker thought that this could
cause a lot of false positives - not sure if that's valid, to be
verified.)
Richard Smith [Sat, 11 Feb 2012 19:22:50 +0000 (19:22 +0000)]
Implement core issue 5: a temporary created for copy-initialization has a
cv-unqualified type. This is essential in order to allow move-only objects of
const-qualified types to be copy-initialized via a converting constructor.
Eli Friedman [Sat, 11 Feb 2012 05:08:10 +0000 (05:08 +0000)]
Implement warning for non-wide string literals with an unexpected encoding. Downgrade error for non-wide character literals with an unexpected encoding to a warning for compatibility with gcc and older versions of clang. <rdar://problem/10837678>.
[libclang] For a reference of an implicit template instantiation just give
a reference for the instantiation decl. Also test that its location is correct
after previous commit.
For class template implicit instantiation, also update its location to point
to the pattern template that it came from, otherwise we had this situation:
template <typename T1, typename T2>
struct S {
};
template <typename T>
struct S<T, int> {
};
void f() {
S<int, int> s; // location of declaration "S<int, int>" was of "S<T1, T2>" not "S<T, int>"
}
Jim Grosbach [Fri, 10 Feb 2012 20:37:10 +0000 (20:37 +0000)]
Have the driver pass CPU and target feature information to cc1as.
When creating the MCSubtargetInfo, the assembler driver uses the CPU and
feature string to construct a more accurate model of what instructions
are and are not legal.
Douglas Gregor [Fri, 10 Feb 2012 17:46:20 +0000 (17:46 +0000)]
Allow implicit capture of 'this' in a lambda even when the capture
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.
Douglas Gregor [Fri, 10 Feb 2012 16:48:36 +0000 (16:48 +0000)]
Add test from [expr.prim.lambda]p12, which deals with odr-use and
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.
Douglas Gregor [Fri, 10 Feb 2012 16:13:20 +0000 (16:13 +0000)]
Don't introduce a lambda's operator() into the class until after we
have finished parsing the body, so that name lookup will never find
anything within the closure type. Then, add this operator() and the
conversion function (if available) before completing the class.
Richard Smith [Fri, 10 Feb 2012 11:05:11 +0000 (11:05 +0000)]
PR11684, core issue 1417:
o Correct the handling of the restrictions on usage of cv-qualified and
ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
arguments, due to such arguments not being treated as a template type arg
context.
o Remove the ExtWarn for usage of such types as template arguments; that was
a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
code for diagnosing ref-qualifiers.
Richard Smith [Fri, 10 Feb 2012 09:58:53 +0000 (09:58 +0000)]
Track whether a function type has a trailing return type as type sugar. Use this
to pretty-print such function types better, and to fix a case where we were not
instantiating templates in lexical order. In passing, move the Variadic bit from
Type's bitfields to FunctionProtoType to get the Type bitfields down to 32 bits.
Also ensure that we always substitute the return type of a function when
substituting explicitly-specified arguments, since that can cause us to bail
out with a SFINAE error before we hit a hard error in parameter substitution.
Evgeniy Stepanov [Fri, 10 Feb 2012 09:30:15 +0000 (09:30 +0000)]
Fix function prolog codegen whe coerce-to type is a struct.
This changes function prolog in such a way as to avoid out-of-bounds
stack store in the case when coerce-to type has a larger storage size
than the real argument type.
Douglas Gregor [Fri, 10 Feb 2012 09:26:04 +0000 (09:26 +0000)]
Add various tests for captures and the reaching scope of the lambda
expression. Implement C++11 [expr.prim.lambda]p12's requirement that
capturing a variable will odr-use it.
Douglas Gregor [Fri, 10 Feb 2012 07:45:31 +0000 (07:45 +0000)]
Extend CXXRecordDecl with a function that determines the mapping from
the variables captured by a lambda to the fields that store the
captured values. To be used in IRgen.
Richard Smith [Fri, 10 Feb 2012 07:41:06 +0000 (07:41 +0000)]
Update to new resolution for DR1458. When taking the address of an object of
incomplete class type which has an overloaded operator&, it's now just
unspecified whether the overloaded operator or the builtin is used.
David Blaikie [Fri, 10 Feb 2012 05:15:16 +0000 (05:15 +0000)]
Move -Wswitch from -Wmost to -Wall, consitent with GCC.
This is a relatively noisy warning for a codebase not explicitly designed for
it (effectively enforcing a stylistic constraint about the use of defaults
in switches over enums) & there's nothing Clang does to clean up the noise
when compared to GCC's implementation so the same decision seems suitable.
Ted Kremenek [Fri, 10 Feb 2012 02:45:47 +0000 (02:45 +0000)]
Revert r145999. This turned out to be a bad idea. Unfortunately, 'id' is used so profusely
in many APIs and large codebases that this made the deprecated warning trigger happy to
the point of not being useful.
objc: If a method is not implemented in the category implementation but
has been declared in its primary class, superclass,
or in one of their protocols, no need to issue unimplemented method.
// rdar://10823023
Akira Hatanaka [Thu, 9 Feb 2012 19:54:16 +0000 (19:54 +0000)]
Class objects passed by value follow the same rules as structure objects.
Double fields of by-value class objects should be passed in floating point
registers.
Douglas Gregor [Thu, 9 Feb 2012 10:18:50 +0000 (10:18 +0000)]
Implement return type deduction for lambdas per C++11
[expr.prim.lambda]p4, including the current suggested resolution of
core isue 975, which allows multiple return statements so long as the
types match. ExtWarn when user code is actually making use of this
extension.
Douglas Gregor [Thu, 9 Feb 2012 08:52:43 +0000 (08:52 +0000)]
Restore the appropriate lexical declaration context for a lambda's
function call operator (to the lambda class). This allows us to IRgen
calls to simple (non-capturing) lambdas, e.g.,
[](int i, int j) -> int { return i + j; }(1, 2)
Eli will be providing test cases as he brings up more IRgen.
Douglas Gregor [Thu, 9 Feb 2012 08:14:43 +0000 (08:14 +0000)]
Implement C++ [expr.prim.lambda]p2, which bans lambda expressions in
unevaluated operands. Be certain that we're marking everything
referenced within a capture initializer as odr-used.
We were passing a decl to the consumer after all pending deserializations were finished
but this was not enough; due to processing by the consumer we may end up into yet another
deserialization process but the way FinishedDeserializing() was setup we would not ensure
that everything was fully deserialized before returning to the consumer.
Separate ASTReader::FinishedDeserializing() into two semantic actions.
The first is ensuring that a deserialization process ends up will fully deserialized decls/types even
if the process is started by the consumer.
The second is pushing "interesting" decls to the consumer; we make sure that we don't re-enter this
section recursively be checking a variable.
Don't cache the artificial type for the this pointer, there's no
difference in the qual type. This is a workaround for the fact that
the type isn't artificial but the this decl is, however, we don't
have any way of representing it in the current metadata. For now,
however, just don't cache the full type.
Fixes rdar://10831526 and probably a couple of others.
Richard Smith [Thu, 9 Feb 2012 06:40:58 +0000 (06:40 +0000)]
DR1359: A constexpr constructor does not need to initialize an empty struct or
empty union. This still rejects anonymous member structs or unions which only
contain such empty class types, pending standard wording defining exactly what
an empty class type is.
[PCH] Set the DeclContext before doing any deserialization, to make sure internal
calls to Decl::getASTContext() by Decl's methods will find the TranslationUnitDecl
without crashing due to a parent declaration context still deserializing.
David Blaikie [Thu, 9 Feb 2012 03:57:02 +0000 (03:57 +0000)]
Correct comment Clang C++ use in production.
This was from way-back-when (r82583) when Clang's C++ support wasn't prime-time
yet. Production quality C++ was tested experimentally from r100119 and turned
on by default in r141063.
projects / clang / log