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
because the memory associated with them is going to get released.
We also don't want them to affect later parsing.
(We do the same for C++ inline methods.)
The underlying cause for the leftover tokens is going to be addressed in the
next commit.
Couldn't get a test case for the crash though. rdar://10583033.
llvm-svn: 146814
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
declaration tickles a bug in the way we handle visibility pragmas.
The improvement to error recovery for template function definitions declared
with the 'typedef' specifier in r145372 is unrelated and not reverted here.
llvm-svn: 145541
declaration at namespace scope is followed by a semicolon and an open-brace
(or in C++, a 'try', ':' or '='), then the error is probably a function
definition with a spurious ';', rather than a mysterious '{'.
llvm-svn: 145372
default", make a note of which is used when creating the
initial declaration. Previously, we would wait until later to handle
default/delete as a definition, but this is too late: when adding the
declaration, we already treated the declaration as "user-provided"
when in fact it was merely "user-declared".
Fixes PR10861 and PR10442, along with a bunch of FIXMEs.
llvm-svn: 144011
Microsoft __if_exists/__if_not_exists statement. Also note that we
weren't traversing DeclarationNameInfo *at all* within the
RecursiveASTVisitor, which would be rather fatal for variadic
templates.
llvm-svn: 142906
statements. As noted in the documentation for the AST node, the
semantics of __if_exists/__if_not_exists are somewhat different from
the way Visual C++ implements them, because our parsed-template
representation can't accommodate VC++ semantics without serious
contortions. Hopefully this implementation is "good enough".
llvm-svn: 142901
analysis to separate dependent names from non-dependent names. For
dependent names, we'll behave differently from Visual C++:
- For __if_exists/__if_not_exists at class scope, we'll just warn
and then ignore them.
- For __if_exists/__if_not_exists in statements, we'll treat the
inner statement as a compound statement, which we only instantiate
in templates where the dependent name (after instantiation)
exists. This behavior is different from VC++, but it's as close as
we can get without encroaching ridiculousness.
The latter part (dependent statements) is not yet implemented.
llvm-svn: 142864
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
C++11 mode but keep their sources compatible with C++98. This patch implements
the -Wc++98-compat-variadic-templates sub-flag and -Wc++98-compat to include
it.
llvm-svn: 141898
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
The main motivation was to do typo correction in C++ "new" statements,
though picking it up in other places where type names are expected was
pretty much a freebie.
llvm-svn: 141621
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
the information on to Sema. There's still an incorrectness in the way template instantiation
works now, but that is due to a far larger underlying representational problem.
Also add a test case for various list initialization cases of scalars, which test this
commit as well as the previous one.
llvm-svn: 140460
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
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
ctor-initializer, remember to call the Sema action to generate default
ctor-initializers. What a delightful little miscompile. Fixes PR10578
/ <rdar://problem/9877267>.
llvm-svn: 139253
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
llvm-svn: 138913
existing practice with Python extension modules. Not that Python
extension modules should be using a double-underscored identifier
anyway, but...
llvm-svn: 138870
and does the Sema on their body after the entire
class/category @implementation is seen. This change allows messaging
of forward private methods, as well as, access to
synthesized ivars of properties with foward synthesize
declarations; among others. In effect, this patch removes
several restrictions placed on objective-c due to in-place
semantics processing of methods.
This is part of // rdar://8843851.
llvm-svn: 138865
, such as list of forward @class decls, in a DeclGroup
node. Deal with its consequence throught clang. This
is in preparation for more Sema work ahead. // rdar://8843851.
Feel free to reverse if it breaks something important
and I am unavailable.
llvm-svn: 138709
loads the named module. The syntax itself is intentionally hideous and
will be replaced at some later point with something more
palatable. For now, we're focusing on the semantics:
- Module imports are handled first by the preprocessor (to get macro
definitions) and then the same tokens are also handled by the parser
(to get declarations). If both happen (as in normal compilation),
the second one is redundant, because we currently have no way to
hide macros or declarations when loading a module. Chris gets credit
for this mad-but-workable scheme.
- The Preprocessor now holds on to a reference to a module loader,
which is responsible for loading named modules. CompilerInstance is
the only important module loader: it now knows how to create and
wire up an AST reader on demand to actually perform the module load.
- We search for modules in the include path, using the module name
with the suffix ".pcm" (precompiled module) for the file name. This
is a temporary hack; we hope to improve the situation in the
future.
llvm-svn: 138679
from the given source. -emit-module behaves similarly to -emit-pch,
except that Sema is somewhat more strict about the contents of
-emit-module. In the future, there are likely to be more interesting
differences.
llvm-svn: 138595
to modernity. Instead of passing down individual
context objects from parser to sema, establish decl
context in parser and have sema access current context
as needed. I still need to take of Doug's comment for
minor cleanups.
llvm-svn: 138040
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
for-in statements; specifically, make sure to close over any
temporaries or cleanups it might require. In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.
rdar://problem/9817306
llvm-svn: 136204
FullSourceLoc::getInstantiationLoc to ...::getExpansionLoc. This is part
of the API and documentation update from 'instantiation' as the term for
macros to 'expansion'.
llvm-svn: 135914
Fariborz Jahanian