PR40642: Fix determination of whether the final statement of a statement
expression is a discarded-value expression.

Summary:
We used to get this wrong in three ways:

1) During parsing, an expressi

PR40642: Fix determination of whether the final statement of a statement
expression is a discarded-value expression.

Summary:
We used to get this wrong in three ways:

1) During parsing, an expression-statement followed by the }) ending a
statement expression was always treated as producing the value of the
statement expression. That's wrong for ({ if (1) expr; })
2) During template instantiation, various kinds of statement (most
statements not appearing directly in a compound-statement) were not
treated as discarded-value expressions, resulting in missing volatile
loads (etc).
3) In all contexts, an expression-statement with attributes was not
treated as producing the value of the statement expression, eg
({ [[attr]] expr; }).

Also fix incorrect enforcement of OpenMP rule that directives can "only
be placed in the program at a position where ignoring or deleting the
directive would result in a program with correct syntax". In particular,
a label (be it goto, case, or default) should not affect whether
directives are permitted.

Reviewers: aaron.ballman, rjmccall

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57984

llvm-svn: 354090

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Refactor the way we handle diagnosing unused expression results.

Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expressio

Refactor the way we handle diagnosing unused expression results.

Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.

This patch fixes PR39837.

llvm-svn: 350404

show more ...

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separat

NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)

We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637

show more ...

Port getLocStart -> getBeginLoc

Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

Differential Revision: https://reviews.llvm.org/D50350

llvm-svn: 339385

Append new attributes to the end of an AttributeList.

Recommit of r335084 after revert in r335516.

... instead of prepending it at the beginning (the original behavior
since implemented in r122535

Append new attributes to the end of an AttributeList.

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

llvm-svn: 338800

show more ...

Remove trailing space

sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h}

llvm-svn: 338291

[NFC] Rename clang::AttributeList to clang::ParsedAttr

Since The type no longer contains the 'next' item anymore, it isn't a list,
so rename it to ParsedAttr to be more accurate.

llvm-svn: 337005

AttributeList de-listifying:

Basically, "AttributeList" loses all list-like mechanisms, ParsedAttributes is
switched to use a TinyPtrVector (and a ParsedAttributesView is created to
have a non-alloc

AttributeList de-listifying:

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.

llvm-svn: 336945

show more ...

Fix allocation of Nullability attribute.

Existing code always allocates for on the declarator's attribute pool,
but sometimes adds it to the declspec. This patch ensures that the
correct pool is

Fix allocation of Nullability attribute.

Existing code always allocates for on the declarator's attribute pool,
but sometimes adds it to the declspec. This patch ensures that the
correct pool is used.


Discovered while testing: https://reviews.llvm.org/D48788

llvm-svn: 336225

show more ...

Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

This reapplies r334224 and adds explicit triples to some tests to fix
them on Windows (where otherwise they would have run with the default
wi

Reapply "[Parse] Use CapturedStmt for @finally on MSVC"

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

llvm-svn: 334251

show more ...

Revert "[Parse] Use CapturedStmt for @finally on MSVC"

This reverts commit r334224.

This is causing buildbot failures on Windows, presumably because some
tests don't specify a triple. I'll test thi

Revert "[Parse] Use CapturedStmt for @finally on MSVC"

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.

llvm-svn: 334240

show more ...

[Parse] Use CapturedStmt for @finally on MSVC

The body of a `@finally` needs to be executed on both exceptional and
non-exceptional paths. On landingpad platforms, this is straightforward:
the `@fin

[Parse] Use CapturedStmt for @finally on MSVC

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

llvm-svn: 334224

show more ...

Remove \brief commands from doxygen comments.

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. Thi

Remove \brief commands from doxygen comments.

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

llvm-svn: 331834

show more ...

Revert rC330794 and some dependent tiny bug fixes

See Richard's humbling feedback here:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html
http://lists.llvm.org/pipermail

Revert rC330794 and some dependent tiny bug fixes

See Richard's humbling feedback here:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226486.html

Wish I'd had the patience to solicit the feedback prior to committing :)

Sorry for the noise guys.

Thank you Richard for being the steward that clang deserves!

llvm-svn: 330888

show more ...

[c++2a] [concepts] Add rudimentary parsing support for template concept declarations


This patch is a tweak of changyu's patch: https://reviews.llvm.org/D40381. It differs in that the recognition of

[c++2a] [concepts] Add rudimentary parsing support for template concept declarations


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!

llvm-svn: 330794

show more ...

Sink PrettyDeclStackTrace down to the AST library

...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.

llvm-svn: 328

Sink PrettyDeclStackTrace down to the AST library

...and add some very basic stack trace entries for module building.
This would have helped track down rdar://problem/38434694 sooner.

llvm-svn: 328276

show more ...

Allow the NS, CF, and ObjC attributes to be used with -fdouble-square-bracket-attributes. The syntactic locations for such attributes on ObjC constructs have been specifically chosen to follow the GN

Allow the NS, CF, and ObjC attributes to be used with -fdouble-square-bracket-attributes. The syntactic locations for such attributes on ObjC constructs have been specifically chosen to follow the GNU attribute syntactic locations.

llvm-svn: 324890

show more ...

Again reverting an attempt to convert the DeclSpec enums into scoped enums.
- reverts r321622, r321625, and r321626.
- the use of bit-fields is still resulting in warnings - even though we can us

Again reverting an attempt to convert the DeclSpec enums into scoped enums.
- 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.

llvm-svn: 321628

show more ...

[NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & TypeSpecifierType into scoped enums with underlying types.
- Since these enums are used as bit-fields - for the bit-fields to be interp

[NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & TypeSpecifierType into scoped enums with underlying types.
- Since these enums are used as bit-fields - for the bit-fields to be interpreted as unsigned, the underlying type must be specified as unsigned.

Previous failed attempt - wherein I did not specify an underlying type - was the sum of:
https://reviews.llvm.org/rC321614
https://reviews.llvm.org/rC321615

llvm-svn: 321622

show more ...

Revert r321614 and r321615
- 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

Revert r321614 and r321615
- 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 ;)

llvm-svn: 321616

show more ...

[NFC] Modernize enums TypeSpecifierWidth, TypeSpecifierSign & TypeSpecifierType into scoped enums.



llvm-svn: 321614

[NFC] Modernize enum DeclSpecContext into a scoped enum.

llvm-svn: 321590

[NFC] Modernize enum Declarator::TheContext to a type-safe scoped enum.

Note, we don't do any bitwise manipulations when using them.

llvm-svn: 321546

[Modules TS] Added module re-export support.

This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax.
Differential

[Modules TS] Added module re-export support.

This implements [dcl.modules.export] from the C++ Modules TS, which lets a module re-export another module with the "export import" syntax.
Differential Revision: https://reviews.llvm.org/D40270

llvm-svn: 318744

show more ...