| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
target Objective-C runtime down to the frontend: break this
down into a single target runtime kind and version, and compute
all the relevant information from that. This makes it
relatively painless to add support for new runtimes to the
compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z,
available at the driver level as a better and more general
alternative to -fgnu-runtime and -fnext-runtime. This new
concept of an Objective-C runtime also encompasses what we
were previously separating out as the "Objective-C ABI", so
fragile vs. non-fragile runtimes are now really modelled as
different kinds of runtime, paving the way for better overall
differentiation.
As a sort of special case, continue to accept the -cc1 flag
-fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak.
I won't go so far as to say "no functionality change", even
ignoring the new driver flag, but subtle changes in driver
semantics are almost certainly not intended.
llvm-svn: 158793
|
|
|
|
|
|
| |
conflicts from a separate problematic patch.
llvm-svn: 158750
|
|
|
|
|
|
|
|
| |
The original r158700 caused crashes in the gcc test suite,
g++.abi/vtable3a.C among others. It also caused failures in the libc++
test suite.
llvm-svn: 158749
|
|
|
|
|
|
| |
includes support for the align (which fixes PR12631).
llvm-svn: 158717
|
|
|
|
|
|
|
|
|
| |
also deal with '>>>' (in CUDA), '>=', and '>>='. Fix the FixItHints logic to
deal with cases where the token is followed by an adjacent '=', '==', '>=',
'>>=', or '>>>' token, where a naive fix-it would result in a differing token
stream on a re-lex.
llvm-svn: 158652
|
|
|
|
| |
llvm-svn: 158573
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
all. Suppresses follow-on errors mentioned in PR13074.
llvm-svn: 158348
|
|
|
|
|
|
|
|
|
| |
are otherwise too short to try to correct.
The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.
llvm-svn: 158109
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In standard C since C89, a 'translation-unit' is syntactically defined to have
at least one "external-declaration", which is either a decl or a function
definition. In Clang the latter gives us a declaration as well.
The tricky bit about this warning is that our predefines can contain external
declarations (__builtin_va_list and the 128-bit integer types). Therefore our
AST parser now makes sure we have at least one declaration that doesn't come
from the predefines buffer.
Also, remove bogus warning about empty source files. This doesn't catch source
files that only contain comments, and never fired anyway because of our
predefines.
PR12665 and <rdar://problem/9165548>
llvm-svn: 158085
|
|
|
|
|
|
|
|
|
| |
on the RecordDecl. Persist the MS portability type attributes and
ignore them in Sema rather than the parser.
Patch by João Matos!
llvm-svn: 157288
|
|
|
|
| |
llvm-svn: 157287
|
|
|
|
|
|
| |
Microsoft mode, from Will Wilson!
llvm-svn: 156940
|
|
|
|
|
|
|
|
| |
a warning for an extra semi-colon after function definitions. Added logic
so that a block of semi-colons on a line will only get one warning instead
of a warning for each semi-colon.
llvm-svn: 156934
|
|
|
|
|
|
| |
disambiguate whether the type name was forgotten or mistyped.
llvm-svn: 156854
|
|
|
|
|
|
|
| |
permitted as a Microsoft extension. Patch by William Wilson! (Plus some minor
tweaking by me.)
llvm-svn: 156786
|
|
|
|
|
|
|
| |
parser, and use it to emit better diagnostics in cases where an identifer
can't be looked up as a type name.
llvm-svn: 156508
|
|
|
|
|
|
|
| |
normal parse for token sequences like 'vector pixel foo'. This incidentally also
fixes a couple of wrong-parse issues.
llvm-svn: 156503
|
|
|
|
|
|
|
| |
TentativeParsingAction is reverted, from Pasi Parviainen! Fixes
PR12480 / <rdar://problem/11341251>.
llvm-svn: 155823
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 155723
|
|
|
|
|
|
|
| |
to a given type, when the reason is that there is a non-type decl with
the same name.
llvm-svn: 155677
|
|
|
|
| |
llvm-svn: 155082
|
|
|
|
|
|
|
|
| |
member of base class is allowed but only from a static function.
This fixes a regression when parsing MFC code with clang.
llvm-svn: 154924
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 { };
llvm-svn: 154790
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
right place to pick up parsing. In C++, this had a tendency to skip everything
declared within headers if the TU starts with garbage.
llvm-svn: 154530
|
|
|
|
| |
llvm-svn: 154476
|
|
|
|
|
|
|
|
|
|
| |
* 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.
llvm-svn: 154381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 154325
|
|
|
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 154224
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 154187
|
|
|
|
| |
llvm-svn: 154164
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 154163
|
|
|
|
|
|
|
|
| |
parameter.
Change suggested by Sebastian Redl on review feedback from r153887.
llvm-svn: 154102
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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.
llvm-svn: 154073
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 153887
|
|
|
|
|
|
| |
name as a direct initializer.
llvm-svn: 153628
|
|
|
|
|
|
|
| |
necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.
llvm-svn: 153544
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 153488
|
|
|
|
|
|
| |
really works.
llvm-svn: 152757
|
|
|
|
| |
llvm-svn: 152559
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and lots of tidying up.
llvm-svn: 152392
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|