| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
ActOnFinishFullExpr that some of its checks only apply to discarded-value
expressions. This adds missing checks for unexpanded variadic template
parameter packs to a handful of constructs.
llvm-svn: 172485
|
|
|
|
|
|
| |
nearby 'C++0x' comments.
llvm-svn: 171372
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
| |
llvm-svn: 171268
|
|
|
|
|
|
| |
that was skipped by the parser.
llvm-svn: 169531
|
|
|
|
|
|
|
| |
-fasm-blocks flag, not the -fms-extensions flag.
rdar://12808010
llvm-svn: 169422
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
them in order to parse the rest of the file.
llvm-svn: 168327
|
|
|
|
|
|
| |
Based on post-commit review feedback for r167766 by Richard Smith.
llvm-svn: 167856
|
|
|
|
|
|
|
| |
Introduces more clear scoping flags & flag combinations which should hopefully
be more understandable.
llvm-svn: 167766
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++11 3.3.3/2 "A parameter name shall not be redeclared in the outermost block
of the function definition nor in the outermost block of any handler associated
with a function-try-block."
It's not totally clear to me whether the "FIXME" case is covered by this, but
Richard Smith thinks it probably should be. It's just a bit more involved to
fix that case.
llvm-svn: 167650
|
|
|
|
|
|
| |
compound statement.
llvm-svn: 167363
|
|
|
|
|
|
|
|
| |
directly
without using tentative parsing.
llvm-svn: 167142
|
|
|
|
| |
llvm-svn: 166867
|
|
|
|
|
|
|
| |
declarations and statements. Emit an error if the FP_CONTRACT is used
later in a compound statement.
llvm-svn: 166383
|
|
|
|
|
|
|
| |
I think our general framework for parser pragmas needs a bit more work,
but I'm not planning on working on it at the moment.
llvm-svn: 165558
|
|
|
|
|
|
| |
contexts. <rdar://problem/12453134>
llvm-svn: 165462
|
|
|
|
|
|
|
| |
mess by handling all pragmas which the parser touches uniformly.
<rdar://problem/12248901>, etc.
llvm-svn: 165195
|
|
|
|
|
|
|
|
| |
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
llvm-svn: 164989
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but can be dereferenced to form an expression which does have viable begin/end
functions, then typo-correct the range, even if something else goes wrong with
the statement (such as inaccessible begin/end or the wrong type of loop
variable).
In order to ensure we recover correctly and produce any followup diagnostics in
this case, redo semantic analysis on the for-range statement outside of the
diagnostic trap, after issuing the typo-correction.
llvm-svn: 164323
|
|
|
|
| |
llvm-svn: 163149
|
|
|
|
|
|
| |
Also a minor fix to __except printing in StmtPrinter.cpp. Thanks to Aaron Ballman for review.
llvm-svn: 163083
|
|
|
|
|
|
| |
No functional change intended.
llvm-svn: 162632
|
|
|
|
|
|
|
|
|
| |
CodeGen option to a LangOpt option. In turn, hoist the guard into the parser
so that we avoid the new (and fairly unstable) Sema/AST/CodeGen logic. This
should restore the behavior of clang to that prior to r158325.
<rdar://problem/12163681>
llvm-svn: 162602
|
|
|
|
|
|
|
|
| |
MutableArrayRef.
This required changing all get() calls to data() and using the simpler constructors.
llvm-svn: 162501
|
|
|
|
|
|
| |
SmallVector.
llvm-svn: 162492
|
|
|
|
|
|
|
| |
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
llvm-svn: 162475
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old error message stating that 'begin' was an undeclared identifier
is replaced with a new message explaining that the error is in the range
expression, along with which of the begin() and end() functions was
problematic if relevant.
Additionally, if the range was a pointer type or defines operator*,
attempt to dereference the range, and offer a FixIt if the modified range
works.
llvm-svn: 162248
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).
This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.
llvm-svn: 162159
|
|
|
|
| |
llvm-svn: 162048
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement. For example,
if (x)
__asm out dx, ax __asm out dx, ax
results in a single inline asm statement (i.e., both "out dx, ax" statements are
predicated on if(x)).
llvm-svn: 161986
|
|
|
|
|
|
| |
printer. Patch by Enea Zaffanella <zaffanella@cs.unipr.it>.
llvm-svn: 161958
|
|
|
|
| |
llvm-svn: 161904
|
|
|
|
| |
llvm-svn: 161890
|
|
|
|
|
|
| |
functional change intended.
llvm-svn: 161518
|
|
|
|
|
|
| |
the ASTContext BumpPtr. Also use the preferred llvm::ArrayRef interface.
llvm-svn: 161373
|
|
|
|
|
|
| |
change intended. No test case as there's no real way to test at this time.
llvm-svn: 161342
|
|
|
|
| |
llvm-svn: 160017
|
|
|
|
|
|
|
| |
objective-c's fast enumeration statement,
for more work to come.
llvm-svn: 159689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attributes in more places where we didn't and catching a lot more issues.
This implements nearly every aspect of C++11 attribute parsing, except for:
- Attributes are permitted on explicit instantiations inside the declarator
(but not preceding the decl-spec)
- Attributes are permitted on friend declarations of functions.
- Multiple instances of the same attribute in an attribute-list (e.g.
[[noreturn, noreturn]], not [[noreturn]] [[noreturn]] which is conforming)
are allowed.
The first two are marked as expected-FIXME in the test file and the latter
is probably a defect and is currently untested.
Thanks to Richard Smith for providing the lion's share of the testcases.
llvm-svn: 159072
|
|
|
|
|
|
| |
statements are allowed on the same line.
llvm-svn: 158372
|
|
|
|
|
|
|
|
|
|
| |
Specifically, improve the handling of whitespace, stop saving tokens that are
in comments and fix the case where we have a comment followed by a closing brace
on the next line.
Unfortunately, there's no easy way of testing this code.
llvm-svn: 158367
|
|
|
|
| |
llvm-svn: 158325
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves the conversion diagnostics (by correctly pointing to the loop
construct for conversions that may've been caused by the contextual conversion
to bool caused by a condition expression) and also causes the NULL conversion
warnings to be correctly suppressed when crossing a macro boundary in such a
context. (previously, since the conversion context location was incorrect, the
suppression could not be performed)
Reported by Nico Weber as feedback to r156826.
llvm-svn: 156901
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 155762
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 :)
llvm-svn: 155759
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 154723
|
|
|
|
| |
llvm-svn: 154584
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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 '[]'.
llvm-svn: 154369
|
|
|
|
|
|
|
|
|
| |
recover by returning the statements that we parsed so far, instead of
dropping the whole function body.
rdar://10967343
llvm-svn: 153367
|