being defined here: [] () -> struct S {} does not define struct S.
In passing, implement DR1318 (syntactic disambiguation of 'final').
llvm-svn: 152551
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.
llvm-svn: 152549
for a few kinds of error. Specifically:
Since we're after translation phase 6, the "" token might be formed by multiple
source-level string literals. Checking the token width is not a correct way of
detecting empty string literals, due to escaped newlines. Diagnose and recover
from a missing space between "" and suffix, and from string literals other than
"", which are followed by a suffix.
llvm-svn: 152348
starting with an underscore is ill-formed.
Since this rule rejects programs that were using <inttypes.h>'s macros, recover
from this error by treating the ud-suffix as a separate preprocessing-token,
with a DefaultError ExtWarn. The approach of treating such cases as two tokens
is under discussion for standardization, but is in any case a conforming
extension and allows existing codebases to keep building while the committee
makes up its mind.
Reword the warning on the definition of literal operators not starting with
underscores (which are, strangely, legal) to more explicitly state that such
operators can't be called by literals. Remove the special-case diagnostic for
hexfloats, since it was both triggering in the wrong cases and incorrect.
llvm-svn: 152287
analysis to make the AST representation testable. They are represented by a
new UserDefinedLiteral AST node, which is a sugared CallExpr. All semantic
properties, including full CodeGen support, are achieved for free by this
representation.
UserDefinedLiterals can never be dependent, so no custom instantiation
behavior is required. They are mangled as if they were direct calls to the
underlying literal operator. This matches g++'s apparent behavior (but not its
actual mangling, which is broken for literal-operator-ids).
User-defined *string* literals are now fully-operational, but the semantic
analysis is quite hacky and needs more work. No other forms of user-defined
literal are created yet, but the AST support for them is present.
This patch committed after midnight because we had already hit the quota for
new kinds of literal yesterday.
llvm-svn: 152211
grammar requires a string-literal and not a user-defined-string-literal. The
two constructs are still represented by the same TokenKind, in order to prevent
a combinatorial explosion of different kinds of token. A flag on Token tracks
whether a ud-suffix is present, in order to prevent clients from needing to look
at the token's spelling.
llvm-svn: 152098
C++11, and with braced-init-list initializers in conditions. This exposed an
ambiguity with enum underlying types versus bitfields, which we resolve by
treating 'enum E : T {' as always defining an enumeration (even if it would
only successfully parse as a bitfield). This appears to be g++ compatible.
llvm-svn: 151227
designators in the parser. In the worst case, this disambiguation
requires tentative parsing just past the closing ']', but for most
cases we'll be able to tell by looking ahead just one token (without
going into the heavyweight tentative parsing machinery).
llvm-svn: 150790
For compatibility with gcc, clang will now parse gcc attributes on
function definitions, but issue a warning if the attribute is not a
thread safety attribute. Warning controlled by -Wgcc-compat.
llvm-svn: 150698
Snooping in other namespaces when the identifier being corrected is
already qualified (i.e. a valid CXXScopeSpec is passed to CorrectTypo)
and ranking synthesized namespace qualifiers relative to the existing
qualifier is now performed. Support for disambiguating the string
representation of synthesized namespace qualifers has also been added
(the change to test/Parser/cxx-using-directive.cpp is an example of an
ambiguous relative qualifier).
llvm-svn: 150622
* 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.
llvm-svn: 150515
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
function body. This keeps the brace count accurate to prevent
additional errors. Also, moved the caret from the brace to the function
name.
Code:
class F{ int Foo{ return 1; } };
Fixed error:
parameters.cc:1:14: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
1 error generated.
Old errors:
parameters.cc:1:17: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
parameters.cc:1:30: error: expected ';' after class
class F{ int Foo{ return 1; } };
^
;
parameters.cc:1:31: error: expected external declaration
class F{ int Foo{ return 1; } };
^
3 errors generated.
llvm-svn: 148621
Stopping at '@' was originally intended to avoid skipping an '@' at the @interface context
when doing parser recovery, but we should not stop at all '@' tokens because they may be part
of expressions (e.g. in @"string", @selector(), etc.), so in most cases we will want to skip them.
This commit caused 'test/Parser/method-def-in-class.m' to fail for the cases where we tried to
recover from unmatched angle bracket but IMO it is not a big deal to not have good recovery
from such broken code and the way we did recovery would not always work anyway (e.g. if there was '@'
in an expression).
The case that rdar://7029784 is about still passes.
llvm-svn: 146815
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)
llvm-svn: 146619
Necessary to parse Microsoft ATL code.
Example:
int array[] = {
0,
__if_exists(CLASS::Type) {2, }
3
};
will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.
llvm-svn: 146447
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is followed by something which can't
possibly be a declarator (or even something which might be a plausible typo for
a declarator), suggest that a semicolon was intended.
llvm-svn: 142544
Aaron Ballman