aboutsummaryrefslogtreecommitdiff
path: root/test/Parser
AgeCommit message (Collapse)Author
2012-05-09Push the knowledge that we are parsing a type-id/type-name further into theRichard Smith
parser, and use it to emit better diagnostics in cases where an identifer can't be looked up as a type name. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156508 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-09Stop AltiVec parsing from going down the 'implicit int' codepath as part of itsRichard Smith
normal parse for token sequences like 'vector pixel foo'. This incidentally also fixes a couple of wrong-parse issues. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156503 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-30Restore paren, bracket and brace counts in parser whenDouglas Gregor
TentativeParsingAction is reverted, from Pasi Parviainen! Fixes PR12480 / <rdar://problem/11341251>. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155823 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-28improve error recovery for extra ')'s after a if/switch/while condition. ↵Chris Lattner
Before: t.c:3:9: error: expected expression if (x)) { ^ .. which isn't even true - a statement or expression is fine. After: t.c:3:9: error: extraneous ')' after condition, expected a statement if (x)) { ^ This is the second part of PR12595 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155762 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-28switch some uses of ExpectAndConsume(tok::semi to use ExpectAndConsumeSemi. ↵Chris Lattner
This allows us to improve this diagnostic (telling us to insert another ")": t.c:2:19: error: expected ';' at end of declaration int x = 4+(5-12)); ^ ; to: t.c:2:19: error: extraneous ')' before ';' int x = 4+(5-12)); ^ ...telling us to remove the ")". This is PR12595. There are more uses of ExpectAndConsumeSemi that could be switched over, but I don't hit them on a daily basis :) git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155759 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-27Imrpove the note text for when a non-type decl hides a tag typeKaelyn Uhrain
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155723 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-26Add note to help explain why a tag such as 'struct' is needed to referKaelyn Uhrain
to a given type, when the reason is that there is a non-type decl with the same name. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155677 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-19Implements boxed expressions for Objective-C. <rdar://problem/10194391>Patrick Beard
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155082 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-17Emulate a MSVC bug where the creation of pointer-to-member to protected ↵Francois Pichet
member of base class is allowed but only from a static function. This fixes a regression when parsing MFC code with clang. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154924 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-16The result of the Microsoft __uuidof operator must be considered a global ↵Francois Pichet
lvalue during constant expression evaluation. Otherwise we would get this error in C++11 mode (because of a recent change): error: non-type template argument of type 'const _GUID *' is not a constant expression For code like: template <const GUID* g = &__uuidof(struct_with_uuid)> class COM_CLASS { }; git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154790 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-14Add an AttributedStmt type to represent a statement with C++11 attributesRichard Smith
attached. Since we do not support any attributes which appertain to a statement (yet), testing of this is necessarily quite minimal. Patch by Alexander Kornienko! git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154723 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-12Added a flag to the parser to skip method bodies.Erik Verbruggen
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154584 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-11Part of PR10101: after a parse error in a declaration, try harder to find theRichard Smith
right place to pick up parsing. In C++, this had a tendency to skip everything declared within headers if the TU starts with garbage. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154530 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-11Support C++11 attributes at the start of a parameter-declaration.Richard Smith
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154476 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-10Parsing of C++11 attributes:Richard Smith
* Alternative tokens (such as 'compl') are treated as identifiers in attribute names. * An attribute-list can start with a comma. * An ellipsis may not be used with either of our currently-supported C++11 attributes. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154381 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-10Disambiguation of '[[':Richard Smith
* 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
2012-04-09Fix bugs found by -Wconstant-conversion improvements currently under review.David Blaikie
Specifically, using a an integer outside [0, 1] as a boolean constant seems to be an easy mistake to make with things like "x == a || b" where the author intended "x == a || x == b". The bug caused by calling SkipUntil with three token kinds was also identified by a VC diagnostic & reported by Francois Pichet as review feedback for my commit r154163. I've included test cases to verify the error recovery that was broken/poorly implemented due to this bug. The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually reached in any of Clang's tests & is related to Objective C features I'm not familiar with, so I've not been able to construct a test case for it. Perhaps someone else can. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154325 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-06Remove "parse error" in favor of more descriptive diagnostics.David Blaikie
In a few cases clang emitted a rather content-free diagnostic: 'parse error'. This change replaces two actual cases (template parameter parsing and K&R parameter declaration parsing) with more specific diagnostics and removes a third dead case of this in the BalancedDelimiterTracker (the ctor already checked the invariant necessary to ensure that the diag::parse_error was never actually used). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154224 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-06Added a new attribute, objc_root_class, which informs the compiler when a ↵Patrick Beard
root class is intentionally declared. The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154187 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-06Fix diagnostic text for r154163.David Blaikie
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154164 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-06Restrict fixit for missing 'class' in template template parameters.David Blaikie
Based on Doug's feedback to r153887 this omits the FixIt if the following token isn't syntactically valid for the context. (not a comma, '...', identifier, '>', or '>>') There's a bunch of work to handle the '>>' case, but it makes for a much more pleasant diagnostic in this case. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154163 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-05Improve & simplify diagnostic for missing 'class' in template template ↵David Blaikie
parameter. Change suggested by Sebastian Redl on review feedback from r153887. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154102 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-05Improve diagnostics for invalid use of non-static members / this:Richard Smith
* s/nonstatic/non-static/ in the diagnostics, since the latter form outvoted the former by 28-2 in our diagnostics. * Fix the "use of member in static member function" diagnostic to correctly detect this situation inside a block or lambda. * Produce a more specific "invalid use of non-static member" diagnostic for the case where a nested class member refers to a member of a lexically-surrounding class. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154073 91177308-0d34-0410-b5e6-96231b3b80d8
2012-04-02Correct error recovery when missing 'class' in a template template parameter.David Blaikie
The diagnostic message correctly informs the user that they have omitted the 'class' keyword, but neither suggests this insertion as a fixit, nor attempts to recover as if they had provided the keyword. This fixes the recovery, adds the fixit, and adds a separate diagnostic and corresponding replacement fixit for cases where the user wrote 'struct' or 'typename' instead of 'class' (suggested by Richard Smith as a possible common mistake). I'm not sure the diagnostic message for either the original or new cases feel very Clang-esque, so I'm open to suggestions there. The fixit hints make it fairly easy to see what's required, though. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153887 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-29Don't try to parse a malformed parameter list after a constructor or operatorRichard Smith
name as a direct initializer. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153628 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-27If we see '(...' where we're expecting an abstract-declarator, that doesn'tRichard Smith
necessarily mean we've found a function declarator. If the next token is not a ')', this is actually a parenthesized pack expansion. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153544 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-27When we see 'Class(X' or 'Class::Class(X' and we suspect that it names aRichard Smith
constructor, but X is not a known typename, check whether the tokens could possibly match the syntax of a declarator before concluding that it isn't a constructor. If it's definitely ill-formed, assume it is a constructor. Empirical evidence suggests that this pattern is much more often a constructor with a typoed (or not-yet-declared) type name than any of the other possibilities, so the extra cost of the check is not expected to be problematic. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153488 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-15Adding some more specific tests for enum declspec parsing, to prove that it ↵Aaron Ballman
really works. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152757 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-12Fix a crash-on-invalid found by -Wlogical-op-parentheses.David Blaikie
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152559 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-12Fix parsing of trailing-return-type. Types are syntactically prohibited fromRichard Smith
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
2012-03-12Fix parsing of type-specifier-seq's. Types are syntactically allowed to beRichard Smith
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
2012-03-09Support for raw and template forms of numeric user-defined literals,Richard Smith
and lots of tidying up. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152392 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-08Fix a couple of issues with literal-operator-id parsing, and provide recoveryRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152348 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-08Add support for cooked forms of user-defined-integer-literal andRichard Smith
user-defined-floating-literal. Support for raw forms of these literals to follow. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152302 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-08Implement C++11 [lex.ext]p10 for string and character literals: a ud-suffix notRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152287 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-08User-defined literal support for character literals.Richard Smith
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152277 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-07AST representation for user-defined literals, plus just enough of semanticRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152211 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-06User-defined literals: reject string and character UDLs in all places where theRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152098 91177308-0d34-0410-b5e6-96231b3b80d8
2012-03-01Added support for parsing declspecs on enumerations. Fixes PR8783Aaron Ballman
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151798 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-27Fix decltype crash-on-invalid, if we don't find a matching ')' for an ill-formedRichard Smith
decltype expression. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151515 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-23Update parser's disambiguation to cope with braced function-style casts inRichard Smith
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151227 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-22In -fdelayed-template-parsing mode, reenter every scope when late parsing a ↵Francois Pichet
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151140 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-22Accept braced-init-lists in conditions, and, in passing, dramatically improveRichard Smith
the diagnostic for using a parenthesized direct-initializer in a condition. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151137 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-17Disambiguate between C++11 lambda expressions and C99 arrayDouglas Gregor
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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150790 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16Improve recovery for lambda expressions that have 'mutable' or aDouglas Gregor
trailing return type but not a '()'. Recover by inserting the parentheses. Thanks to Xeo on IRC for the example. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150727 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-16Allow thread safety attributes on function definitions.DeLesley Hutchins
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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150698 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-15Improve typo correction involving nested name specifiers.Kaelyn Uhrain
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). git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150622 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-14Generalize -Wempty-body: warn when statement body is empty (closes: PR11329)Dmitri Gribenko
* 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150515 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-11Drive-by fix of incorrect diagnostic, and a test case for said diagnostic. ↵Sebastian Redl
The double error is unfortunate, but I really don't see an alternative whose effort is worth it. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150317 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-09Remove the "unsupported" error for lambda expressions. It's annoying,Douglas Gregor
and rapidly becoming untrue. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150165 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3-18-g5258 (git 2.32.0) at 2025-07-16 11:57:04 +0000