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
Richard Smith