17 Commits

Author SHA1 Message Date
Matheus Izvekov
91cdd35008
[clang] Improve nested name specifier AST representation (#147835)
This is a major change on how we represent nested name qualifications in
the AST.

* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.

This patch offers a great performance benefit.

It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.

This has great results on compile-time-tracker as well:

![image](https://github.com/user-attachments/assets/700dce98-2cab-4aa8-97d1-b038c0bee831)

This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.

It has some other miscelaneous drive-by fixes.

About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.

There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.

How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.

The rest and bulk of the changes are mostly consequences of the changes
in API.

PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.

Fixes #136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
2025-08-09 05:06:53 -03:00
Matheus Izvekov
d057811655
[clang] fix diagnostic printing of expressions ignoring LangOpts (#134693)
Currently when printing a template argument of expression type, the
expression is converted immediately into a string to be sent to the
diagnostic engine, unsing a fake LangOpts.

This makes the expression printing look incorrect for the current
language, besides being inneficient, as we don't actually need to print
the expression if the diagnostic would be ignored.

This fixes a nastiness with the TemplateArgument constructor for
expressions being implicit, and all current users just passing an
expression to a diagnostic were implicitly going through the template
argument path.

The expressions are also being printed unquoted. This will be fixed in a
subsequent patch, as the test churn is much larger.
2025-04-07 23:19:32 -03:00
Matheus Izvekov
dc17429ae6
[clang] improved preservation of template keyword (#133610) 2025-04-01 17:15:18 -03:00
Younan Zhang
8c1547055e
[Clang] Remove the special-casing for RequiresExprBodyDecl in BuildResolvedCallExpr() after fd87d765c0 (#111277)
The special-casing for RequiresExprBodyDecl caused a regression, as
reported in #110785.

The original fix for #84020 has been superseded by fd87d765c0, which
establishes a `DependentScopeDeclRefExpr` instead of a
`CXXDependentScopeMemberExpr` for the case in issue. So the spurious
diagnostic in #84020 would no longer occur.

This also merges the test for #84020 together with that for #110785 into
clang/test/SemaTemplate/instantiate-requires-expr.cpp.

No release note because I think this merits a backport.

Fixes #110785
2024-10-07 09:38:19 +08:00
Matheus Izvekov
00139ae1bc
Revert "[clang] Reland: Instantiate concepts with sugared template arguments (#101782)" (#102551) 2024-08-08 23:38:08 -03:00
Matheus Izvekov
748371183a
[clang] Reland: Instantiate concepts with sugared template arguments (#101782) 2024-08-04 22:11:11 -03:00
Younan Zhang
440fffad7e
[Clang][Concepts] Avoid substituting into constraints for invalid TemplateDecls (#75697)
Fixes https://github.com/llvm/llvm-project/issues/73885.

Substituting into constraints for invalid TemplateDecls might still
yield dependent expressions and end up crashing later in evaluation.
2024-07-17 19:17:01 +08:00
Matheus Izvekov
9c4a716c12
[clang] Preserve Qualifiers and type sugar in TemplateNames (#93433)
This patch improves the preservation of qualifiers and loss of type
sugar in TemplateNames.

This problem is analogous to https://reviews.llvm.org/D112374 and this
patch takes a very similar approach to that patch, except the impact
here is much lesser.

When a TemplateName was written bare, without qualifications, we
wouldn't produce a QualifiedTemplate which could be used to disambiguate
it from a Canonical TemplateName. This had effects in the TemplateName
printer, which had workarounds to deal with this, and wouldn't print the
TemplateName as-written in most situations.

There are also some related fixes to help preserve this type sugar along
the way into diagnostics, so that this patch can be properly tested.

- Fix dropping the template keyword.
- Fix type deduction to preserve sugar in TST TemplateNames.
2024-05-29 17:02:15 -03:00
Erich Keane
12cb1cb372 Revert "[clang] Instantiate concepts with sugared template arguments"
This reverts commit b8064374b217db061213c561ec8f3376681ff9c8.

Based on the report here:
https://github.com/llvm/llvm-project/issues/59271

this produces a significant increase in memory use of the compiler and a
large compile-time regression.  This patch reverts this so that we don't
branch for release with that issue.
2023-01-17 07:29:31 -08:00
Matheus Izvekov
b8064374b2
[clang] Instantiate concepts with sugared template arguments
Since we don't unique specializations for concepts, we can just instantiate
them with the sugared template arguments, at negligible cost.

If we don't track their specializations, we can't resugar them later
anyway, and that would be more expensive than just instantiating them
sugared in the first place since it would require an additional pass.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D136566
2022-10-27 06:18:53 +02:00
Matheus Izvekov
31074f5ec2
Revert "[clang] Instantiate concepts with sugared template arguments"
This reverts commit d0a6de59c78010118fea811514e03ed9f400215a.
2022-10-26 10:14:14 +02:00
Matheus Izvekov
d0a6de59c7
[clang] Instantiate concepts with sugared template arguments
Since we don't unique specializations for concepts, we can just instantiate
them with the sugared template arguments, at negligible cost.

If we don't track their specializations, we can't resugar them later
anyway, and that would be more expensive than just instantiating them
sugared in the first place since it would require an additional pass.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Differential Revision: https://reviews.llvm.org/D136566
2022-10-26 03:24:20 +02:00
Saar Raz
9769e1ee9a [Concepts] Fix incorrect DeclContext for transformed RequiresExprBodyDecl
We would assign the incorrect DeclContext when transforming the RequiresExprBodyDecl, causing incorrect
handling of 'this' inside RequiresExprBodyDecls (bug #45162).

Assign the current context as the DeclContext of the transformed decl.
2020-03-10 23:17:00 +02:00
Saar Raz
67c608a969 [Concepts] Deprecate -fconcepts-ts, enable Concepts under -std=c++2a
Now with concepts support merged and mostly complete, we do not need -fconcepts-ts
(which was also misleading as we were not implementing the TS) and can enable
concepts features under C++2a. A warning will be generated if users still attempt
to use -fconcepts-ts.
2020-01-24 00:48:59 +02:00
Saar Raz
a0f50d7316 [Concepts] Requires Expressions
Implement support for C++2a requires-expressions.

Re-commit after compilation failure on some platforms due to alignment issues with PointerIntPair.

Differential Revision: https://reviews.llvm.org/D50360
2020-01-19 00:23:26 +02:00
Saar Raz
baa84d8cde Revert "[Concepts] Requires Expressions"
This reverts commit 027931899763409e2c61a84bdee6057b5e838ffa.

There have been some failing tests on some platforms, reverting while investigating.
2020-01-18 14:58:01 +02:00
Saar Raz
0279318997 [Concepts] Requires Expressions
Implement support for C++2a requires-expressions.

Differential Revision: https://reviews.llvm.org/D50360
2020-01-18 09:15:36 +02:00