* In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
array sizes and array indexes which begin with a lambda-expression. Recover by
parsing the lambda as a lambda.
* In Objective-C++11, either '[' could be the start of a message-send.
Fully disambiguate this case: it turns out that the grammars of message-sends,
lambdas and attributes do not actually overlap. Accept any occurrence of '[['
where either '[' starts a message send, but reject a lambda in an array index
just like in C++11 mode.
Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
* In a function-declaration, the attributes go after the exception specification,
not after the right paren.
* A reference type can have attributes applied.
* An 'identifier' in an attribute can also be a keyword. Support for alternative
tokens (iso646 keywords) in attributes to follow.
And some bug fixes:
* Parse attributes after declarator-ids, even if they are not simple identifiers.
* Do not accept attributes after a parenthesized declarator.
* Accept attributes after an array size in a new-type-id.
* Partially disamiguate 'delete' followed by a lambda. More work is required
here for the case where the lambda-introducer is '[]'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154369 91177308-0d34-0410-b5e6-96231b3b80d8
a constant expression' error into a DefaultError ExtWarn, so that it can be
disabled and is suppressed in system headers. libstdc++4.7 contains some such
functions which we currently can't evaluate as constant expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154115 91177308-0d34-0410-b5e6-96231b3b80d8
The deferred lookup table building step couldn't accurately tell which Decls
should be included in the lookup table, and consequently built different tables
in some cases.
Fix this by removing lazy building of DeclContext name lookup tables. In
practice, the laziness was frequently not worthwhile in C++, because we
performed lookup into most DeclContexts. In C, it had a bit more value,
since there is no qualified lookup.
In the place of lazy lookup table building, we simply don't build lookup tables
for function DeclContexts at all. Such name lookup tables are not useful, since
they don't capture the scoping information required to correctly perform name
lookup in a function scope.
The resulting performance delta is within the noise on my testing, but appears
to be a very slight win for C++ and a very slight loss for C. The C performance
can probably be recovered (if it is a measurable problem) by avoiding building
the lookup table for the translation unit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152608 91177308-0d34-0410-b5e6-96231b3b80d8
being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152551 91177308-0d34-0410-b5e6-96231b3b80d8
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152549 91177308-0d34-0410-b5e6-96231b3b80d8
string literal, and adjust the diagnostic code to match. This also causes us
to escape any control characters in the message.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152069 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151117 91177308-0d34-0410-b5e6-96231b3b80d8
explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151001 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix bug when determining whether && / || are potential constant expressions
* Try harder when determining whether ?: is a potential constant expression
* Produce a diagnostic on sizeof(VLA) to provide a better source location
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150657 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150359 91177308-0d34-0410-b5e6-96231b3b80d8
[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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150348 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150244 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150157 91177308-0d34-0410-b5e6-96231b3b80d8
can't produce a constant expression is not ill-formed (so long as some
instantiation of that function can produce a constant expression).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149802 91177308-0d34-0410-b5e6-96231b3b80d8
* support the gcc __builtin_constant_p() ? ... : ... folding hack in C++11
* check for unspecified values in pointer comparisons and pointer subtractions
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149578 91177308-0d34-0410-b5e6-96231b3b80d8
function definition can produce a constant expression. This also provides the
last few checks for [dcl.constexpr]p3 and [dcl.constexpr]p4.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149108 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148735 91177308-0d34-0410-b5e6-96231b3b80d8
- If the declarator is at the start of a line, and the previous line contained
another declarator and ended with a comma, then that comma was probably a
typo for a semicolon:
int n = 0, m = 1, l = 2, // k = 5;
myImportantFunctionCall(); // oops!
- If removing the parentheses would correctly initialize the object, then
produce a note suggesting that fix.
- Otherwise, if there is a simple initializer we can suggest which performs
value-initialization, then provide a note suggesting a correction to that
initializer.
Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148072 91177308-0d34-0410-b5e6-96231b3b80d8
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147824 91177308-0d34-0410-b5e6-96231b3b80d8
the Semantic Powers to only warn on class types (or dependent types), where the
constructor or destructor could do something interesting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147642 91177308-0d34-0410-b5e6-96231b3b80d8
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.
Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.
Add a new warning group -Wvexing-parse containing both of these warnings.
The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147599 91177308-0d34-0410-b5e6-96231b3b80d8
variable is initialized by a non-constant expression, and pass in the variable
being declared so that earlier-initialized fields' values can be used.
Rearrange VarDecl init evaluation to make this possible, and in so doing fix a
long-standing issue in our C++ constant expression handling, where we would
mishandle cases like:
extern const int a;
const int n = a;
const int a = 5;
int arr[n];
Here, n is not initialized by a constant expression, so can't be used in an ICE,
even though the initialization expression would be an ICE if it appeared later
in the TU. This requires computing whether the initializer is an ICE eagerly,
and saving that information in PCH files.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146856 91177308-0d34-0410-b5e6-96231b3b80d8
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@146619 91177308-0d34-0410-b5e6-96231b3b80d8
or MemberExpr which refers to it. As a side-effect, MemberExprs which refer to
static member functions and static data members are now emitted as constant
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144468 91177308-0d34-0410-b5e6-96231b3b80d8
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@144028 91177308-0d34-0410-b5e6-96231b3b80d8
valid C++98/03 code. However, add these warnings to -Wall, for those
who obviously already like clean code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142903 91177308-0d34-0410-b5e6-96231b3b80d8
instead of silently discarding them.
As a side effect, this improves diagnostics for constexpr class
templates slightly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@142755 91177308-0d34-0410-b5e6-96231b3b80d8
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141801 91177308-0d34-0410-b5e6-96231b3b80d8
constexpr constructor templates. Such checking is optional, and currently hard
to get right since clang doesn't generate implicit member initializers until
instantiation (even for non-dependent members).
This is needed for clang to accept libstdc++ from g++4.6 in c++0x mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141547 91177308-0d34-0410-b5e6-96231b3b80d8
part on patches by Peter Collingbourne.
We diverge from the C++11 standard in a few areas, mostly related to checking
constexpr function declarations, and not just definitions. See WG21 paper
N3308=11-0078 for details.
Function invocation substitution is not available in this patch; constexpr
functions cannot yet be used from within constant expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140926 91177308-0d34-0410-b5e6-96231b3b80d8
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140801 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith
Douglas Gregor
Sebastian Redl
Eli Friedman
Richard Trieu
John McCall
Peter Collingbourne
David Blaikie