Recommit of r335084 after revert in r335516.
... instead of prepending it at the beginning (the original behavior
since implemented in r122535 2010-12-23). This builds up an
AttributeList in the the order in which the attributes appear in the
source.
The reverse order caused nodes for attributes in the AST (e.g. LoopHint)
to be in the reverse order, and therefore printed in the wrong order in
-ast-dump. Some TODO comments mention this. The order was explicitly
reversed for enable_if attribute overload resolution and name mangling,
which is not necessary anymore with this patch.
The change unfortunately has some secondary effect, especially on
diagnostic output. In the simplest cases, the CHECK lines or expected
diagnostic were changed to the the new output. If the kind of
error/warning changed, the attributes' order was changed instead.
This unfortunately causes some 'previous occurrence here' hints to be
textually after the main marker. This typically happens when attributes
are merged, but are incompatible to each other. Interchanging the role
of the the main and note SourceLocation will also cause the case where
two different declaration's attributes (in contrast to multiple
attributes of the same declaration) are merged to be reverse. There is
no easy fix because sometimes previous attributes are merged into a new
declaration's attribute list, sometimes new attributes are added to a
previous declaration's attribute list. Since 'previous occurrence here'
pointing to locations after the main marker is not rare, I left the
markers as-is; it is only relevant when the attributes are declared in
the same declaration anyway.
Differential Revision: https://reviews.llvm.org/D48100
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@338800 91177308-0d34-0410-b5e6-96231b3b80d8
Since The type no longer contains the 'next' item anymore, it isn't a list,
so rename it to ParsedAttr to be more accurate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@337005 91177308-0d34-0410-b5e6-96231b3b80d8
Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is
switched to use a TinyPtrVector (and a ParsedAttributesView is created to
have a non-allocating attributes list). DeclaratorChunk gets the later kind,
Declarator/DeclSpec keep ParsedAttributes.
Iterators are added to the ParsedAttribute types so that for-loops work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@336945 91177308-0d34-0410-b5e6-96231b3b80d8
This reapplies r334224 and adds explicit triples to some tests to fix
them on Windows (where otherwise they would have run with the default
windows-msvc triple, which I'm changing the behavior for).
Original commit message:
The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).
Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.
Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those. In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.
The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.
Differential Revision: https://reviews.llvm.org/D47564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334251 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r334224.
This is causing buildbot failures on Windows, presumably because some
tests don't specify a triple. I'll test this on Windows locally and
recommit with the tests fixed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334240 91177308-0d34-0410-b5e6-96231b3b80d8
The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@finally` body is emitted as a normal (non-exceptional) cleanup,
and then a catch-all is emitted which branches to that cleanup (the
cleanup has code to conditionally re-throw based on a flag which is set
by the catch-all).
Unfortunately, we can't use the same approach for MSVC exceptions, where
the catch-all will be emitted as a catchpad. We can't just branch to the
cleanup from within the catchpad, since we can only exit it via a
catchret, at which point the exception is destroyed and we can't
rethrow. We could potentially emit the finally body inside the catchpad
and have the normal cleanup path somehow branch into it, but that would
require some new IR construct that could branch into a catchpad.
Instead, after discussing it with Reid Kleckner, we decided that
frontend outlining was the best approach, similar to how SEH `__finally`
works today. We decided to use CapturedStmt (which was also suggested by
Reid) rather than CaptureFinder (which is what `__finally` uses) since
the latter doesn't handle a lot of cases we care about, e.g. self
accesses, property accesses, block captures, etc. Extending
CaptureFinder to handle those additional cases proved unwieldy, whereas
CapturedStmt already took care of all of those. In theory `__finally`
could also be moved over to CapturedStmt, which would remove some
existing limitations (e.g. the inability to capture this), although
CaptureFinder would still be needed for SEH filters.
The one case supported by `@finally` but not CapturedStmt (or
CaptureFinder for that matter) is arbitrary control flow out of the
`@finally`, e.g. having a return statement inside a `@finally`. We can
add that support as a follow-up, but in practice we've found it to be
used very rarely anyway.
Differential Revision: https://reviews.llvm.org/D47564
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@334224 91177308-0d34-0410-b5e6-96231b3b80d8
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331834 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of the 'concept' token is moved into the machinery that recognizes declaration-specifiers - this allows us to leverage the attribute handling machinery more seamlessly.
See the test file to get a sense of the basic parsing that this patch supports.
There is much more work to be done before concepts are usable...
Thanks Changyu!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@330794 91177308-0d34-0410-b5e6-96231b3b80d8
...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328276 91177308-0d34-0410-b5e6-96231b3b80d8
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can use static-asserts to harden the code and ensure the bit-fields are wide enough. The bots still complain of warnings being seen.
- to silence the warnings requires specifying the bit-fields with the underlying enum type (as opposed to the enum type itself), which then requires lots of unnecessary static casts of each enumerator within DeclSpec to the underlying-type, which even though could be seen as implementation details, it does hamper readability - and given the additional litterings, makes me question the value of the change.
So in short - I give up (for now at least).
Sorry about the noise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321628 91177308-0d34-0410-b5e6-96231b3b80d8
- the enum changes to TypeSpecifierType are breaking some tests - and will require a more careful integration.
Sorry about rushing these changes - thought I could sneak them in prior to heading out for new years ;)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@321616 91177308-0d34-0410-b5e6-96231b3b80d8
as identifiers in Objective-C++
This commit improves the 'expected identifier' errors that are presented when a
C++ keyword is used as an identifier in Objective-C++ by mentioning that this is
a C++ keyword in the diagnostic message. It also improves the error recovery:
the parser will now treat the C++ keywords as identifiers to prevent unrelated
parsing errors.
rdar://20626062
Differential Revision: https://reviews.llvm.org/D26503
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299950 91177308-0d34-0410-b5e6-96231b3b80d8
Some clients (eg the cling interpreter) need to recover their parser from
errors.
Patch by Axel Naumann (D31190)!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@298606 91177308-0d34-0410-b5e6-96231b3b80d8
This patch ensures that the typo fixit for the @try/@finally/@autoreleasepool {}
directive is shown only when we're parsing an actual statement where such
directives can actually be present.
rdar://19669565
Differential Revision: https://reviews.llvm.org/D26916
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@288334 91177308-0d34-0410-b5e6-96231b3b80d8
The ObjC class protocol list assumes there is an associated location for each protocol but no location is provided
when the protocol list comes from a typedef, and we end up with a buffer overflow when trying to get locations for the protocol names.
Fixes crash of rdar://28980278.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@286331 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a crash-on-invalid.
When parsing type arguments and protocols,
parseObjCTypeArgsOrProtocolQualifiers() calls ParseTypeName(), which tries to
find matching tokens for '[', '(', etc whenever they appear among potential
type names. If unmatched, ParseTypeName() yields a tok::eof token stream. This
leads to crashes since the parsing at this point is not expected to go beyond
the param list closing '>'.
Fix that by properly handling tok::eof in
parseObjCTypeArgsOrProtocolQualifiers() callers.
Differential Revision: https://reviews.llvm.org/D23852
rdar://problem/25063557
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@281383 91177308-0d34-0410-b5e6-96231b3b80d8
Sema actions on ObjCDictionaryLiteral and ObjCArryLiteral are currently
done as a side-effect of Sema upon parent expressions, which incurs of
delayed typo corrections for such literals to be performed by TypoTransforms
upon the ObjCDictionaryLiteral and ObjCArryLiteral themselves instead of
its elements individually.
This is specially bad because it was not designed to act on several
elements; searching through all possible combinations of corrections for
several elements is very expensive. Additionally, when one of the
elements has no correction candidate, we still explore all options and
at the end emit no typo corrections whatsoever.
Do the proper sema actions by acting on each element alone during appropriate
literal parsing time to get proper diagonistics and decent compile time
behavior.
Differential Revision: http://reviews.llvm.org/D22183
rdar://problem/21046678
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276020 91177308-0d34-0410-b5e6-96231b3b80d8
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272963 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of setting DeclSpec's range end to point to the next token
after the DeclSpec, we use getLocForEndOfToken to insert fix-it after a type
name.
Before this fix, fix-it will change
^(NSView view) to ^(*NSView view)
This commit correctly updates the source to ^(NSView* view).
rdar://21042144
Differential Revision: http://reviews.llvm.org/D20844
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@271448 91177308-0d34-0410-b5e6-96231b3b80d8
constructor's definition is in an implementation block.
Without this commit, ptr doesn't get initialized to null in the
following code:
struct S {
S();
void *ptr = nullptr;
};
@implementation I
S::S() {}
@end
rdar://problem/25693624
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266645 91177308-0d34-0410-b5e6-96231b3b80d8
Under certain conditions clang currently fails to properly diagnostic ObjectC
parameter list when type args and protocols are mixed in the same list. This
happens when the first item in the parameter list is a (1) protocol, (2)
unknown type or (3) a list of protocols/unknown types up to the first type
argument. Fix the problem to report the proper error, example:
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
NSNumber *bar = foo[0];
NSLog(@"%@", bar);
$ clang ...
x.m:7:13: error: angle brackets contain both a type ('NSValue') and a protocol ('M')
NSArray<M, NSValue *, NSURL, NSArray <id <M>>> *foo = @[@"a"];
~ ^
Differential Revision: http://reviews.llvm.org/D18997
rdar://problem/22204367
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@266245 91177308-0d34-0410-b5e6-96231b3b80d8
While this won't help fix things like the bug that r260219 addressed, it
seems like good tidy up to have anyway.
(it might be nice if "makeArrayRef" always produced a MutableArrayRef &
let it decay to an ArrayRef when needed - then I'd use that for the
MutableArrayRefs in this patch)
If we had std::dynarray I'd use that instead of unique_ptr+size_t,
ideally (but then it'd have to be threaded down through the Preprocessor
all the way - no idea how painful that would be)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260246 91177308-0d34-0410-b5e6-96231b3b80d8
Add "enum ObjCPropertyQueryKind" to a few APIs that used to only take the name
of the property: ObjCPropertyDecl::findPropertyDecl,
ObjCContainerDecl::FindPropertyDeclaration,
ObjCInterfaceDecl::FindPropertyVisibleInPrimaryClass,
ObjCImplDecl::FindPropertyImplDecl, and Sema::ActOnPropertyImplDecl.
ObjCPropertyQueryKind currently has 3 values:
OBJC_PR_query_unknown, OBJC_PR_query_instance, OBJC_PR_query_class
This extra parameter specifies that we are looking for an instance property with
the given name, or a class property with the given name, or any property with
the given name (if both exist, the instance property will be returned).
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@259070 91177308-0d34-0410-b5e6-96231b3b80d8
This is the third patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258834 91177308-0d34-0410-b5e6-96231b3b80d8
Stephen Kelly