Richard Smith [Tue, 14 Feb 2012 23:06:14 +0000 (23:06 +0000)]
Extend all-std-headers.cpp to include C++11 headers when building in C++11 mode.
Conditionally include headers which older STL implementations don't provide.
Douglas Gregor [Tue, 14 Feb 2012 22:28:59 +0000 (22:28 +0000)]
Implement C++ core issue 974, which permits default arguments for
lambda expressions. Because these issue was pulled back from Ready
status at the Kona meeting, we still emit an ExtWarn when using
default arguments for lambda expressions.
Richard Smith [Tue, 14 Feb 2012 22:25:15 +0000 (22:25 +0000)]
If a constexpr function template specialization is referenced, and then the
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.
Dmitri Gribenko [Tue, 14 Feb 2012 22:14:32 +0000 (22:14 +0000)]
Generalize -Wempty-body: warn when statement body is empty (closes: PR11329)
* if, switch, range-based for: warn if semicolon is on the same line.
* for, while: warn if semicolon is on the same line and either next
statement is compound statement or next statement has more
indentation.
Replacing the semicolon with {} or moving the semicolon to the next
line will always silence the warning.
Tests from SemaCXX/if-empty-body.cpp merged into SemaCXX/warn-empty-body.cpp.
Richard Smith [Tue, 14 Feb 2012 21:38:30 +0000 (21:38 +0000)]
Pending clear answer from WG21 on whether core issue 903 is intended to apply to
C++11 or just C++17, restrict the set of null pointer constants in C++11 mode
back to those which were considered null in C++98.
Richard Smith [Tue, 14 Feb 2012 21:14:13 +0000 (21:14 +0000)]
PR11650: Implement resolution of core issue 1301. Value initialization can't be
used to construct an object of union type with a deleted default constructor
(plus fixes for some related value-initialization corner cases).
Kaelyn Uhrain [Tue, 14 Feb 2012 18:56:48 +0000 (18:56 +0000)]
Use several weighted factors to determine typo candidate viablity.
Replace the simple Levenshtein edit distance for typo correction
candidates--and the hacky way adding namespace qualifiers would affect
the edit distance--with a synthetic "edit distance" comprised of several
factors and their relative weights. This also allows the typo correction
callback object to convey more information about the viability of a
correction candidate than simply viable or not viable.
Ted Kremenek [Tue, 14 Feb 2012 02:46:03 +0000 (02:46 +0000)]
Implement new DiagnosticsRenderer that packages notes retrieved by clang_getDiagnosticSetFromTU() as
child diagnostics of primary diagnostics. By using the DiagnosticRenderer, these Diagnostics now
match with those generated for serialized diagnostics.
Ted Kremenek [Tue, 14 Feb 2012 02:46:00 +0000 (02:46 +0000)]
Refactor DiagnosticRenderer and SDiagsRenderer to have some functionality
pulled into DiagnosticNoteRenderer, and common DiagnosticRenderer that
assumes that all custom diagnostic messages are notes. Also extend
DiagnosticRenderer to work with StoredDiagnostics in preparation for
subsequent changes.
Richard Smith [Tue, 14 Feb 2012 02:33:50 +0000 (02:33 +0000)]
Fix another issue introduced by the proposed wording for core issue 1358: since
the instantiation of a constexpr function temploid is now always constexpr, a
defaulted constexpr function temploid is often ill-formed by the rule in
[dcl.fct.def.default]p2 that an explicitly-defaulted constexpr function must
have a constexpr implicit definition. To avoid making loads of completely
reasonable code ill-formed, do not apply that rule to templates.
Eli Friedman [Tue, 14 Feb 2012 02:15:49 +0000 (02:15 +0000)]
Refactor out new function EmitInitializerForField from EmitMemberInitializer. The new function will be used to initialize the fields of lambda expressions.
Anna Zaks [Tue, 14 Feb 2012 00:26:13 +0000 (00:26 +0000)]
[analyzer] Malloc Checker: realloc: add dependency between the symbols
in realloc map.
If there is no dependency, the reallocated ptr will get garbage
collected before we know that realloc failed, which would lead us to
missing a memory leak warning.
Also added new test cases, which we can handle now.
Plus minor cleanups.
Douglas Gregor [Tue, 14 Feb 2012 00:00:48 +0000 (00:00 +0000)]
Link together the call operator produced from transforming a lambda
expression with the original call operator, so that we don't try to
separately instantiate the call operator. Test and tweak a few more
bits for template instantiation of lambda expressions.
Richard Smith [Mon, 13 Feb 2012 22:16:19 +0000 (22:16 +0000)]
Deal with a horrible C++11 special case. If a non-literal type has a constexpr
constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.
Douglas Gregor [Mon, 13 Feb 2012 22:00:16 +0000 (22:00 +0000)]
Introduce support for template instantiation of lambda
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.
Sebastian Redl [Mon, 13 Feb 2012 19:55:43 +0000 (19:55 +0000)]
Don't route explicit construction via list-initialization through the functional cast code path. It sometimes does the wrong thing, produces horrible error messages, and is just unnecessary.
1) Support the case when realloc fails to reduce False Positives. (We
essentially need to restore the state of the pointer being reallocated.)
2) Realloc behaves differently under special conditions (from pointer is
null, size is 0). When detecting these cases, we should consider
under-constrained states (size might or might not be 0). The
old version handled this in a very hacky way. The code did not
differentiate between definite and possible (no consideration for
under-constrained states). Further, after processing each special case,
the realloc processing function did not return but chained to the next
special case processing. So you could end up in an execution in which
you first see the states in which size is 0 and realloc ~ free(),
followed by the states corresponding to size is not 0 followed by the
evaluation of the regular realloc behavior.
Douglas Gregor [Mon, 13 Feb 2012 17:20:40 +0000 (17:20 +0000)]
Split the storage of lambda information between the LambdaExpr and the
CXXRecordDecl in a way that actually makes some sense:
- LambdaExpr contains all of the information for initializing the
lambda object, including the capture initializers and associated
array index variables.
- CXXRecordDecl's LambdaDefinitionData contains the captures, which
are needed to understand the captured variable references in the
body of the lambda.
Douglas Gregor [Mon, 13 Feb 2012 16:35:30 +0000 (16:35 +0000)]
Keep track of the set of array index variables we use when we
synthesize a by-copy captured array in a lambda. This information will
be needed by IR generation.
Douglas Gregor [Mon, 13 Feb 2012 15:44:47 +0000 (15:44 +0000)]
Move the storage of lambda captures and capture initializers from
LambdaExpr over to the CXXRecordDecl. This allows us to eliminate the
back-link from the closure type to the LambdaExpr, which will simplify
and lazify AST deserialization.
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>"
}
projects / clang / log