Disambiguate type names when printing NTTP types

When printing NTTP template types, ensure that type name of the NTTP is
printed.

Fixes #57562

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

Disambiguate type names when printing NTTP types

When printing NTTP template types, ensure that type name of the NTTP is
printed.

Fixes #57562

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

show more ...

Fix build error in StmtPrinterTest.cpp

[clangd] Avoid crash when printing call to string literal operator template

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

[CodeCompletion][clangd] Clean __uglified parameter names in completion & hover

Underscore-uglified identifiers are used in standard library implementations to
guard against collisions with macros,

[CodeCompletion][clangd] Clean __uglified parameter names in completion & hover

Underscore-uglified identifiers are used in standard library implementations to
guard against collisions with macros, and they hurt readability considerably.
(Consider `push_back(Tp_ &&__value)` vs `push_back(Tp value)`.
When we're describing an interface, the exact names of parameters are not
critical so we can drop these prefixes.

This patch adds a new PrintingPolicy flag that can applies this stripping
when recursively printing pieces of AST.
We set it in code completion/signature help, and in clangd's hover display.
All three features also do a bit of manual poking at names, so fix up those too.

Fixes https://github.com/clangd/clangd/issues/736

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

show more ...

[clang] Refactor AST printing tests to share more infrastructure

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

Revert "[clang] Refactor AST printing tests to share more infrastructure"

This reverts commit 20176bc7dd3f431db4c3d59b51a9f53d52190c82 as some
versions of GCC do not seem to handle the new code very

Revert "[clang] Refactor AST printing tests to share more infrastructure"

This reverts commit 20176bc7dd3f431db4c3d59b51a9f53d52190c82 as some
versions of GCC do not seem to handle the new code very well. They
complain about:

/tmp/ccqUQZyw.s: Assembler messages:
/tmp/ccqUQZyw.s:1151: Error: symbol `_ZNSt14_Function_base13_Base_managerIN5clangUlPKNS1_4StmtEE2_EE10_M_managerERSt9_Any_dataRKS7_St18_Manager_operation' is already defined
/tmp/ccqUQZyw.s:11963: Error: symbol `_ZNSt17_Function_handlerIFbPKN5clang4StmtEENS0_UlS3_E2_EE9_M_invokeERKSt9_Any_dataOS3_' is already defined

This seems like it is some GCC issue, but multiple buildbots (and my
local machine) are all failing because of it.

show more ...

[clang] Refactor AST printing tests to share more infrastructure

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

Remove references to the ast_type_traits namespace

Follow up to cd62511496938e33c061c90796dd23a5288ff843 /
https://reviews.llvm.org/D74499

Reviewed By: aaron.ballman

Differential Revision: https:/

Remove references to the ast_type_traits namespace

Follow up to cd62511496938e33c061c90796dd23a5288ff843 /
https://reviews.llvm.org/D74499

Reviewed By: aaron.ballman

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

show more ...

Set traversal explicitly where needed in tests

Reviewers: aaron.ballman, shafik

Subscribers: cfe-commits

Tags: #clang

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

[ASTMatchers] StringRef'ify hasName

This was just inconvenient, and we make a copy anyways.

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly m

Make llvm::StringRef to std::string conversions explicit.

This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.

show more ...

[clang] Respect TerseOutput when printing lambdas

Reviewers: ilya-biryukov, hokein, sammccall

Subscribers: cfe-commits

Tags: #clang

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

llvm-sv

[clang] Respect TerseOutput when printing lambdas

Reviewers: ilya-biryukov, hokein, sammccall

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 361771

show more ...

[c++20] Implement P0428R2 - Familiar template syntax for generic lambdas

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

llvm-svn: 359967

[clang][OpeMP] Model OpenMP structured-block in AST (PR40563)

Summary:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3:
```
structured block

For C/C++, an executa

[clang][OpeMP] Model OpenMP structured-block in AST (PR40563)

Summary:
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf, page 3:
```
structured block

For C/C++, an executable statement, possibly compound, with a single entry at the
top and a single exit at the bottom, or an OpenMP construct.

COMMENT: See Section 2.1 on page 38 for restrictions on structured
blocks.
```
```
2.1 Directive Format

Some executable directives include a structured block. A structured block:
• may contain infinite loops where the point of exit is never reached;
• may halt due to an IEEE exception;
• may contain calls to exit(), _Exit(), quick_exit(), abort() or functions with a
_Noreturn specifier (in C) or a noreturn attribute (in C/C++);
• may be an expression statement, iteration statement, selection statement, or try block, provided
that the corresponding compound statement obtained by enclosing it in { and } would be a
structured block; and

Restrictions
Restrictions to structured blocks are as follows:
• Entry to a structured block must not be the result of a branch.
• The point of exit cannot be a branch out of the structured block.
C / C++
• The point of entry to a structured block must not be a call to setjmp().
• longjmp() and throw() must not violate the entry/exit criteria.
```

Of particular note here is the fact that OpenMP structured blocks are as-if `noexcept`,
in the same sense as with the normal `noexcept` functions in C++.
I.e. if throw happens, and it attempts to travel out of the `noexcept` function
(here: out of the current structured-block), then the program terminates.

Now, one of course can say that since it is explicitly prohibited by the Specification,
then any and all programs that violate this Specification contain undefined behavior,
and are unspecified, and thus no one should care about them. Just don't write broken code /s

But i'm not sure this is a reasonable approach.
I have personally had oss-fuzz issues of this origin - exception thrown inside
of an OpenMP structured-block that is not caught, thus causing program termination.
This issue isn't all that hard to catch, it's not any particularly different from
diagnosing the same situation with the normal `noexcept` function.

Now, clang static analyzer does not presently model exceptions.
But clang-tidy has a simplisic [[ https://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | bugprone-exception-escape ]] check,
and it is even refactored as a `ExceptionAnalyzer` class for reuse.
So it would be trivial to use that analyzer to check for
exceptions escaping out of OpenMP structured blocks. (D59466)

All that sounds too great to be true. Indeed, there is a caveat.
Presently, it's practically impossible to do. To check a OpenMP structured block
you need to somehow 'get' the OpenMP structured block, and you can't because
it's simply not modelled in AST. `CapturedStmt`/`CapturedDecl` is not it's representation.

Now, it is of course possible to write e.g. some AST matcher that would e.g.
match every OpenMP executable directive, and then return the whatever `Stmt` is
the structured block of said executable directive, if any.
But i said //practically//. This isn't practical for the following reasons:
1. This **will** bitrot. That matcher will need to be kept up-to-date,
and refreshed with every new OpenMP spec version.
2. Every single piece of code that would want that knowledge would need to
have such matcher. Well, okay, if it is an AST matcher, it could be shared.
But then you still have `RecursiveASTVisitor` and friends.
`2 > 1`, so now you have code duplication.

So it would be reasonable (and is fully within clang AST spirit) to not
force every single consumer to do that work, but instead store that knowledge
in the correct, and appropriate place - AST, class structure.

Now, there is another hoop we need to get through.
It isn't fully obvious //how// to model this.
The best solution would of course be to simply add a `OMPStructuredBlock` transparent
node. It would be optimal, it would give us two properties:
* Given this `OMPExecutableDirective`, what's it OpenMP structured block?
* It is trivial to check whether the `Stmt*` is a OpenMP structured block (`isa<OMPStructuredBlock>(ptr)`)

But OpenMP structured block isn't **necessarily** the first, direct child of `OMP*Directive`.
(even ignoring the clang's `CapturedStmt`/`CapturedDecl` that were inserted inbetween).
So i'm not sure whether or not we could re-create AST statements after they were already created?
There would be other costs to a new AST node: https://bugs.llvm.org/show_bug.cgi?id=40563#c12
```
1. You will need to break the representation of loops. The body should be replaced by the "structured block" entity.
2. You will need to support serialization/deserialization.
3. You will need to support template instantiation.
4. You will need to support codegen and take this new construct to account in each OpenMP directive.
```

Instead, there **is** an functionally-equivalent, alternative solution, consisting of two parts.

Part 1:
* Add a member function `isStandaloneDirective()` to the `OMPExecutableDirective` class,
that will tell whether this directive is stand-alone or not, as per the spec.
We need it because we can't just check for the existance of associated statements,
see code comment.
* Add a member function `getStructuredBlock()` to the OMPExecutableDirective` class itself,
that assert that this is not a stand-alone directive, and either return the correct loop body
if this is a loop-like directive, or the captured statement.
This way, given an `OMPExecutableDirective`, we can get it's structured block.
Also, since the knowledge is ingrained into the clang OpenMP implementation,
it will not cause any duplication, and //hopefully// won't bitrot.

Great we achieved 1 of 2 properties of `OMPStructuredBlock` approach.

Thus, there is a second part needed:
* How can we check whether a given `Stmt*` is `OMPStructuredBlock`?
Well, we can't really, in general. I can see this workaround:
```
class FunctionASTVisitor : public RecursiveASTVisitor<FunctionASTVisitor> {
using Base = RecursiveASTVisitor<FunctionASTVisitor>;
public:
bool VisitOMPExecDir(OMPExecDir *D) {
OmpStructuredStmts.emplace_back(D.getStructuredStmt());
}
bool VisitSOMETHINGELSE(???) {
if(InOmpStructuredStmt)
HI!
}
bool TraverseStmt(Stmt *Node) {
if (!Node)
return Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node)
++InOmpStructuredStmt;
Base::TraverseStmt(Node);
if (OmpStructuredStmts.back() == Node) {
OmpStructuredStmts.pop_back();
--InOmpStructuredStmt;
}
return true;
}
std::vector<Stmt*> OmpStructuredStmts;
int InOmpStructuredStmt = 0;
};
```
But i really don't see using it in practice.
It's just too intrusive; and again, requires knowledge duplication.

.. but no. The solution lies right on the ground.
Why don't we simply store this `i'm a openmp structured block` in the bitfield of the `Stmt` itself?
This does not appear to have any impact on the memory footprint of the clang AST,
since it's just a single extra bit in the bitfield. At least the static assertions don't fail.
Thus, indeed, we can achieve both of the properties without a new AST node.

We can cheaply set that bit right in sema, at the end of `Sema::ActOnOpenMPExecutableDirective()`,
by just calling the `getStructuredBlock()` that we just added.
Test coverage that demonstrates all this has been added.

This isn't as great with serialization though. Most of it does not use abbrevs,
so we do end up paying the full price (4 bytes?) instead of a single bit.
That price, of course, can be reclaimed by using abbrevs.
In fact, i suspect that //might// not just reclaim these bytes, but pack these PCH significantly.

I'm not seeing a third solution. If there is one, it would be interesting to hear about it.
("just don't write code that would require `isa<OMPStructuredBlock>(ptr)`" is not a solution.)

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=40563 | PR40563 ]].

Reviewers: ABataev, rjmccall, hfinkel, rsmith, riccibruno, gribozavr

Reviewed By: ABataev, gribozavr

Subscribers: mgorny, aaron.ballman, steveire, guansong, jfb, jdoerfert, cfe-commits

Tags: #clang, #openmp

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

llvm-svn: 356570

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

[unittests] Merge the PrintedStmtCXX..Matches functions (NFC)

This was reviewed as part of https://reviews.llvm.org/D36527

llvm-svn: 348589

Allow StmtPrinter to supress implicit 'this' and 'self' base expressions

This will be useful for certain refactoring actions.

rdar://34202062

llvm-svn: 316631

Remove deprecated methods ast_matchers::BoundNodes::{getStmtAs,getDeclAs}

llvm-svn: 289543

Rename AST node matchers to match the AST node names directly. Part of this rename also splits recordDecl() (which used to match CXXRecordDecl) into recordDecl() (that matches RecordDecl) and cxxReco

Rename AST node matchers to match the AST node names directly. Part of this rename also splits recordDecl() (which used to match CXXRecordDecl) into recordDecl() (that matches RecordDecl) and cxxRecordDecl (that matches CXXRecordDecl). Also adds isStruct(), isUnion(), and isClass() narrowing matchers for RecordDecl objects.

llvm-svn: 247885

show more ...

Use 'override/final' instead of 'virtual' for overridden methods

Summary:
The patch is generated using clang-tidy misc-use-override check.

This command was used:

tools/clang/tools/extra/clang-ti

Use 'override/final' instead of 'virtual' for overridden methods

Summary:
The patch is generated using clang-tidy misc-use-override check.

This command was used:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
-checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D8926

llvm-svn: 234678

show more ...

Lex: Use the correct types for MS integer suffixes

Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.

Original

Lex: Use the correct types for MS integer suffixes

Something went wrong with r211426, it is an older version of this code
and should not have been committed. It was reverted with r211434.

Original commit message:
We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.

This fixes PR20008.

Differential Revision: http://reviews.llvm.org/D4132

llvm-svn: 211441

show more ...

Revert "Lex: Use the correct types for MS integer suffixes"

This reverts commit r211426.

This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -ver

Revert "Lex: Use the correct types for MS integer suffixes"

This reverts commit r211426.

This broke the arm bots. The crash can be reproduced on X86 by running.
./bin/clang -cc1 -fsyntax-only -verify -fms-extensions ~/llvm/clang/test/Lexer/ms-extensions.c -triple arm-linux

llvm-svn: 211434

show more ...

Lex: Use the correct types for MS integer suffixes

We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appr

Lex: Use the correct types for MS integer suffixes

We didn't properly implement support for the sized integer suffixes.
Suffixes like i16 were essentially ignored instead of mapping them to
the appropriately sized integer type.

This fixes PR20008.

Differential Revision: http://reviews.llvm.org/D4132

llvm-svn: 211426

show more ...

Removing an "if (this == nullptr)" check from two print methods. The condition
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so i

Removing an "if (this == nullptr)" check from two print methods. The condition
will never be true in a well-defined context. The checking for null pointers
has been moved into the caller logic so it does not rely on undefined behavior.

llvm-svn: 210498

show more ...

[C++11] Use 'nullptr'. Unittests edition.

llvm-svn: 210423