We don't support any C++11 attributes that appertain to declaration specifiers so reject
the attributes in parser until we support them; this also conforms to what g++ 4.8 is doing.
llvm-svn: 167481
- General C++11 attributes were previously parsed and ignored. Now they are parsed and stored in AST.
- Add support to parse arguments of attributes that in 'gnu' namespace.
- Differentiate unknown attributes and known attributes that can't be applied to statements when emitting diagnostic.
llvm-svn: 165082
-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.
llvm-svn: 164951
start of a statement or the end of a compound-statement, diagnose the comma as
a typo for a semicolon. Patch by Ahmed Bougacha! Additional test cases and
minor refactoring by me.
llvm-svn: 164085
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
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
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
llvm-svn: 162464
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
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
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
llvm-svn: 160998
scope to -Wc++11-extensions. Move extra semicolon after member function
definition diagnostic out of -pedantic, since C++ allows a single semicolon
there. Keep it in -Wextra-semi, though, since it's still questionable.
llvm-svn: 160618
Previously it was possible to get an infinite-loop-on-invalid with a namespace
decl within @interface. Since 'namespace' is normally a safe place to retry
top-level parsing, we just didn't consume the token.
This adds a flag that tracks whether we have temporarily left Objective-C
scope to parse a C-like declaration, and uses that to better recover from
parse problems by stopping at possible method declarations and at @end. To
fix the original problem, we do /not/ stop at 'namespace' when in an
Objective-C @interface or @protocol context (but still do in @implementation).
llvm-svn: 159941
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
llvm-svn: 159494
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
error was asserting on anything that included Windows.h. MS-style inline asm is
still dropped, but at least now we're not completely silent about it.
llvm-svn: 158833
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
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
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
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
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
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
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
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
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
* 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
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
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
* 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
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
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
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
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
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
The token stream was not getting properly reset when leaving
ParseLexedMethodDef in some error cases. In the testcase, that caused later
accesses to the token stream to touch memory which had been freed as we
finished parsing the class definition. Major hat-tip to AddressSanitizer for
helping pinpoint the use-after-free, including the allocation and deallocation
points:
==21510== ERROR: AddressSanitizer heap-use-after-free on address 0x7feb3de87848 at pc 0x249f4e2 bp 0x7fff15a89df0 sp 0x7fff15a89ce0
READ of size 1 at 0x7feb3de87848 thread T0
#0 0x249f4e2 clang::TokenLexer::Lex()
#1 0x1c834a0 clang::Parser::ConsumeToken()
#2 0x1c7dc0f clang::Parser::ParseDeclarationOrFunctionDefinition()
#3 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
0x7feb3de87848 is located 1992 bytes inside of 3816-byte region [0x7feb3de87080,0x7feb3de87f68)
freed by thread T0 here:
#0 0x3a22c19 free
#1 0x1d136a1 clang::Parser::LexedMethod::~LexedMethod()
#2 0x1cef528 clang::Parser::DeallocateParsedClasses()
#3 0x1cef676 clang::Parser::PopParsingClass()
#4 0x1cea094 clang::Parser::ParseCXXMemberSpecification()
#5 0x1ce7ae5 clang::Parser::ParseClassSpecifier()
#6 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers()
#7 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition()
#8 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
previously allocated by thread T0 here:
#0 0x3a2302d realloc
#1 0x39d7c97 llvm::SmallVectorBase::grow_pod()
#2 0x1ac588e llvm::SmallVectorImpl<>::push_back()
#3 0x1d12d8b clang::Parser::ConsumeAndStoreUntil()
#4 0x1c9c24d clang::Parser::ConsumeAndStoreUntil()
#5 0x1d12c1e clang::Parser::ConsumeAndStoreUntil()
#6 0x1c9c24d clang::Parser::ConsumeAndStoreUntil()
#7 0x1d10042 clang::Parser::ParseCXXInlineMethodDef()
#8 0x1cec51a clang::Parser::ParseCXXClassMemberDeclaration()
#9 0x1ce9de5 clang::Parser::ParseCXXMemberSpecification()
#10 0x1ce7ae5 clang::Parser::ParseClassSpecifier()
#11 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers()
#12 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition()
#13 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
llvm-svn: 140427
The solution is to create a new ParseScope(Scope::TemplateParamScope) for each template scope that we want to reenter. (from the outmost to the innermost scope)
This fixes some errors when parsing MFC code with clang.
llvm-svn: 140344
For instance:
template <class T> void E() {};
class F {};
void test() {
::E<::F>();
E<::F>();
}
Gives the following error messages:
error: found '<::' after a template name which forms the
digraph '<:' (aka '[') and a ':', did you mean '< ::'?
::E<::F>();
^~~
< ::
error: expected expression
E<::F>();
^
error: expected ']'
note: to match this '['
E<::F>();
This patch adds the digraph fix-it check right before the name lookup,
moves the shared checking code to a new function, and adds new
tests to catch future regressions.
llvm-svn: 140039
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
When a macro instantiation occurs, reserve a SLocEntry chunk with length the
full length of the macro definition source. Set the spelling location of this chunk
to point to the start of the macro definition and any tokens that are lexed directly
from the macro definition will get a location from this chunk with the appropriate offset.
For any tokens that come from argument expansion, '##' paste operator, etc. have their
instantiation location point at the appropriate place in the instantiated macro definition
(the argument identifier and the '##' token respectively).
This improves macro instantiation diagnostics:
Before:
t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
^~~~
t.c:5:11: note: instantiated from:
int y = M(/);
^
After:
t.c:5:9: error: invalid operands to binary expression ('struct S' and 'int')
int y = M(/);
^~~~
t.c:3:20: note: instantiated from:
\#define M(op) (foo op 3);
~~~ ^ ~
t.c:5:11: note: instantiated from:
int y = M(/);
^
The memory savings for a candidate boost library that abuses the preprocessor are:
- 32% less SLocEntries (37M -> 25M)
- 30% reduction in PCH file size (900M -> 635M)
- 50% reduction in memory usage for the SLocEntry table (1.6G -> 800M)
llvm-svn: 134587
int f(int x) {
if (int foo = f(bar)) {}
return 0;
}
Clang produces the following error messages:
paren_imbalance.cc:2:19: error: use of undeclared identifier 'bar'
if (int foo = f(bar)) {}
^
paren_imbalance.cc:2:26: error: expected ')'
if (int foo = f(bar)) {}
^
paren_imbalance.cc:2:6: note: to match this '('
if (int foo = f(bar)) {}
^
The second error is incorrect. This patch will stop Clang from producing an error on parenthesis imbalance during error recovery when there isn't one.
llvm-svn: 134258
- Move the diagnostic to the case statement instead of at the end of the switch
- Add a fix-it hint as to how to fix the compilation error
llvm-svn: 132903
__builtin_astype(): Used to reinterpreted as another data type of the same size using for both scalar and vector data types.
Added test case.
llvm-svn: 132612
that they are C++0x extensions, and put them in the appropriate
group. We already support most of the semantics. Addresses
<rdar://problem/9407525>.
llvm-svn: 131153
Allow to include or exclude code depending on if a symbol exists or not. Just like a #ifdef but for C/C++ symbols.
More doc: http://msdn.microsoft.com/en-us/library/x7wy9xh3(v=VS.100).aspx
Support at class and namespace scopes will be added later.
llvm-svn: 131014
This idiom is used everywhere in MFC/COM code and as such this patch removes hundreds of errors when parsing MFC code with clang.
Example:
template <class T, const GUID* g = &__uuidof(T)>
class ComTemplate { };
typedef ComTemplate<struct_with_uuid, &__uuidof(struct_with_uuid)> COM_TYPE;
Of course this is just parsing support. Trying to use this in CodeGen will generate:
error: cannot yet mangle expression type CXXUuidofExpr
llvm-svn: 130381
This fixes 1 error when parsing MSVC 2008 headers with clang.
Must "return true;" even if it is a warning because the rest of the code path assumes that SS is set to something. The parser will get back on its feet and continue parsing the rest of the declaration correctly so it is not a problem.
llvm-svn: 130088
ObjC NeXt runtime where method pointer registered in
metadata belongs to an unrelated method. Ast part of this fix,
I turned at @end missing warning (for class
implementations) into an error as we can never
be sure that meta-data being generated is correct.
// rdar://9072317
llvm-svn: 130019
is so broken that Sema can't form a declaration for it, don't bother
trying to parse the definition later. Fixes <rdar://problem/9221993>.
llvm-svn: 129547
diagnosing it as an error rather than looping infinitely. Also,
explicitly disallow @defs in Objective-C++. Fixes <rdar://problem/9260136>.
llvm-svn: 129521
the following '@'. Conceivably, we could skip tokens until something that
can validly start an @interface declaration here, but it's not clear that
it matters.
llvm-svn: 128325
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
add support for the OpenCL __private, __local, __constant and
__global address spaces, as well as the __read_only, _read_write and
__write_only image access specifiers. Patch originally by ARM;
language-specific address space support by myself.
llvm-svn: 127915
bugs from other clients that don't expect to see a LabelDecl in a DeclStmt,
but if so they should be easy to fix.
This implements most of PR3429 and rdar://8287027
llvm-svn: 125817
especially C++ code, and generally expand the test coverage.
Logic adapted from a patch by Kaelyn Uhrain <rikka@google.com> and
another Googler.
llvm-svn: 125775
and turn on __has_feature(cxx_rvalue_references). The core rvalue
references proposal seems to be fully implemented now, pending lots
more testing.
llvm-svn: 124169
For example:
class A{
public:
A& operator=(const A& that) {
if (this != &that) {
this->A::~A();
this->A::A(that); // <=== explicit constructor call.
}
return *this;
}
};
More work will be needed to support an explicit call to a template constructor.
llvm-svn: 123735
Objective-C declarations and statements. Fixes
<rdar://problem/8814576> (wrong source line for diagnostics about
missing ';'), and now we actually consume the ';' at the end of a
@compatibility_alias directive!
llvm-svn: 122855
1. Do not validate for uuid attribute if the type is template dependent.
2. Search every class declaration and definition for the uuid attribute.
llvm-svn: 122578
and 'default' statements, including a Fix-It to add the colon:
test/Parser/switch-recovery.cpp:13:12: error: expected ':' after 'case'
case 17 // expected-error{{expected ':' after 'case'}}
^
:
test/Parser/switch-recovery.cpp:16:12: error: expected ':' after 'default'
default // expected-error{{expected ':' after 'default'}}
^
:
llvm-svn: 122522
protocol-qualifier list without a leading type (e.g., <#blah#>), don't
complain about it being an archaic protocol-qualifier list unless it
actually parses as one.
llvm-svn: 119805
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
lexed method declarations.
This avoid interference with tokens coming after the point where the default arg tokens were 'injected', e.g. for
typedef struct Inst {
void m(int x=0);
} *InstPtr;
when parsing '0' the next token would be '*' and things would be messed up.
llvm-svn: 110436
parenthesized, unlike in C++, e.g.,
C has: typeof ( expression)
C++ has: typeof unary-expression
So, once we've parsed a parenthesized expression after typeof, we
should only go on to parse the postfix expression suffix if we're in
C++. Fixes <rdar://problem/8237491>.
llvm-svn: 109606
parser is looking at a declaration or an expression, use a '=' to
conclude that we are parsing a declaration.
This is wrong. However, our previous approach of finding a comma after
the '=' is also wrong, because the ',' could be part of a
template-argument-list. So, for now we're going to use the same wrong
heuristic as GCC and Visual C++, because less real-world code is
likely to be broken this way. I've opened PR7655 to keep track of our
wrongness; note also the XFAIL'd test.
Fixes <rdar://problem/8193163>.
llvm-svn: 108459
In the case of backtracking, the cached token lexer will be the only
lexer on the stack, without this the token stack will be empty and EOF
won't be returned.
This fixes PR7072.
llvm-svn: 108124
a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.
Also, avoid skipping randomly after a declaration if a
semicolon is missing. Before we'd get:
t.c:3:1: error: expected function body after function declarator
void bar();
^
Now we get:
t.c:1:11: error: invalid token after top level declarator
void foo()
^
;
llvm-svn: 108105
As a bonus, fix the warning for || and && operators; it was emitted even if one of the operands had side effects, e.g:
x || test_logical_foo1();
emitted a bogus "expression result unused" for 'x'.
llvm-svn: 107274
For
void f( a:🅱️:c );
we would cache the tokens "a:🅱️:" but then we would try to annotate them using the range "a::".
Before annotating them with the (invalid) C++ scope spec, set it to the range of "a:🅱️:".
llvm-svn: 106536
Michael Han