| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
user-defined-floating-literal. Support for raw forms of these literals
to follow.
llvm-svn: 152302
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 152277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 151798
|
|
|
|
|
|
| |
decltype expression.
llvm-svn: 151515
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
templated function; (Not just the template parameter scope as previously). Also enter the scope stack in the correct order.
Otherwise this breaks some invariant during name lookup especially when dealing with shadowed declaration
Fix PR11931.
llvm-svn: 151140
|
|
|
|
|
|
| |
the diagnostic for using a parenthesized direct-initializer in a condition.
llvm-svn: 151137
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
trailing return type but not a '()'. Recover by inserting the
parentheses. Thanks to Xeo on IRC for the example.
llvm-svn: 150727
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
The double error is unfortunate, but I really don't see an alternative whose effort is worth it.
llvm-svn: 150317
|
|
|
|
|
|
| |
and rapidly becoming untrue.
llvm-svn: 150165
|
|
|
|
| |
llvm-svn: 150129
|
|
|
|
| |
llvm-svn: 150126
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
expressions and block literals. As it turns out, almost all the logic can be shared.
llvm-svn: 149031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Fixes PR6484. Patch from Jason Switzer!
llvm-svn: 148270
|
|
|
|
|
|
| |
complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)
llvm-svn: 147723
|
|
|
|
|
|
| |
pieces to build the lambda class and its call operator. Create an actual scope for the lambda body.
llvm-svn: 147595
|
|
|
|
|
|
| |
use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet.
llvm-svn: 147515
|
|
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
|
|
|
|
|
| |
This works like described in http://drdobbs.com/blogs/cpp/231602010
Fixes http://llvm.org/PR11609
llvm-svn: 147202
|
|
|
|
|
|
|
|
| |
reasonable-looking but ill-formed for-range statement of the form:
for (expression : expression)
llvm-svn: 147006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
in classes. // rdar://10535349
llvm-svn: 146504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
// rdar://10095131
llvm-svn: 146304
|
|
|
|
| |
llvm-svn: 146147
|
|
|
|
|
|
| |
Fixes PR2709.
llvm-svn: 145928
|
|
|
|
|
|
| |
<rdar://problem/10465079>.
llvm-svn: 145656
|
|
|
|
|
|
| |
class) since members are public by default.
llvm-svn: 145580
|
|
|
|
|
|
| |
class scope.
llvm-svn: 144980
|
|
|
|
|
|
| |
defaulted or deleted.
llvm-svn: 144270
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
of an attrib is missing. gcc does not allow the closing parenthesis to be omitted.
llvm-svn: 142255
|
|
|
|
| |
llvm-svn: 142053
|
|
|
|
| |
llvm-svn: 142050
|
|
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
|
|
|
|
|
| |
attributes are found, propagate them to subsequent declarations.
llvm-svn: 141861
|
|
|
|
|
|
| |
colon after access specifiers in C++
llvm-svn: 141852
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 141801
|
|
|
|
|
|
|
| |
delimiter pairs and detect when we exceed the implementation limit for
nesting depth, from Aaron Ballman!
llvm-svn: 141782
|
|
|
|
|
|
|
|
|
| |
which enables support for C99 storage-class specifiers.
This extension is intended to be used by implementations to implement
OpenCL C built-in functions.
llvm-svn: 141271
|