previously didn't work if a mem-initializer-id had a template argument which
contained parentheses or braces.
We now implement a simple rule: just look for a ') {' or '} {' that is not
nested. The '{' is assumed to start the function-body. There are still two
cases which we misparse, where the ') {' comes from a compound literal or
from a lambda. The former case is not valid C++, and the latter will probably
not be valid C++ once DR1607 is resolved, so these seem to be of low value,
and we do not regress on them with this change. EDG and g++ also misparse
both of these cases.
llvm-svn: 185598
When we are consuming the current token just to enter a new token stream, we push
the current token in the back of the stream so that we get it again.
Unfortunately this had the effect where if the current token is a code-completion one,
we would code-complete once during consuming it and another time after the stream ended.
Fix this by making sure that, in this case, ConsumeAnyToken() will consume a code-completion
token without invoking code-completion.
rdar://12842503
llvm-svn: 178199
template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.
This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.
This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.
The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template. That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.
rdar://12350696
llvm-svn: 177003
This required plumbing through a new flag to determine whether a ParmVarDecl is
actually a parameter of a function declaration (as opposed to a function
typedef etc, where the attribute is prohibited). Weirdly, this attribute (just
like [[noreturn]]) cannot be applied to a function type, just to a function
declaration (and its parameters).
llvm-svn: 173726
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
refactorings in that revision, and some of the subsequent bugfixes, which
seem to be relevant even without delayed exception specification parsing.
llvm-svn: 156031
exception specifications on member functions until after the closing
'}' for the containing class. This allows, for example, a member
function to throw an instance of its own class. Fixes PR12564 and a
fairly embarassing oversight in our C++98/03 support.
llvm-svn: 154844
in the declaration of a non-static member function after the
(optional) cv-qualifier-seq, which in practice means in the exception
specification and late-specified return type.
The new scheme here used to manage 'this' outside of a member function
scope is more general than the Scope-based mechanism previously used
for non-static data member initializers and late-parsesd attributes,
because it can also handle the cv-qualifiers on the member
function. Note, however, that a separate pass is required for static
member functions to determine whether 'this' was used, because we
might not know that we have a static function until after declaration
matching.
Finally, this introduces name mangling for 'this' and for the implicit
'this', which is intended to match GCC's mangling. Independent
verification for the new mangling test case would be appreciated.
Fixes PR10036 and PR12450.
llvm-svn: 154799
paren/brace/bracket tracking (the Consume* functions already did it),
removing the use of ConsumeAnyToken(), and moving the hot paths inline
with the error paths out-of-line.
llvm-svn: 152274
default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:
(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.
llvm-svn: 151011
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
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
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
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
llvm-svn: 131228
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
Richard Smith