15 Commits

Author SHA1 Message Date
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
Erich Keane
975740bf8d "Reapply "GH58368: Correct concept checking in a lambda defined in concept""
This reverts commit cecc9a92cfca71c1b6c2a35c5e302ab649496d11.

The problem ended up being how we were handling the lambda-context in
code generation: we were assuming any decl context here would be a
named-decl, but that isn't the case.  Instead, we just replace it with
the concept's owning context.

Differential Revision: https://reviews.llvm.org/D136451
2022-10-24 12:36:54 -07:00
Erich Keane
cecc9a92cf Revert "Reapply "GH58368: Correct concept checking in a lambda defined in concept"""
This reverts commit b876f6e2f28779211a829d7d4e841fe68885ae20.

Still getting build failures on PPC AIX that aren't obvious what is causing
them, so reverting while I try to figure this out.
2022-10-24 12:20:23 -07:00
Erich Keane
b876f6e2f2 Reapply "GH58368: Correct concept checking in a lambda defined in concept""
This reverts commit 52930162870fee52d0d9c07c5d66e5dce32b08e8.

Now with updating the ASTBitcodes to show that this AST is incompatible
from the last.
2022-10-24 11:46:54 -07:00
Erich Keane
5293016287 Revert "GH58368: Correct concept checking in a lambda defined in concept"
This reverts commit b7c922607c5ba93db8b893d4ba461052af8317b5.

This seems to cause some problems with some modules related things,
which makes me think I should have updated the version-major in
ast-bit-codes?  Going to revert to confirm this was a problem, then
change that and re-try a commit.
2022-10-24 10:21:22 -07:00
Erich Keane
b7c922607c GH58368: Correct concept checking in a lambda defined in concept
As that bug reports, the problem here is that the lambda's
'context-decl' was not set to the concept, and the lambda picked up
template arguments from the concept.  SO, we failed to get the correct
template arguments in SemaTemplateInstantiate.

However, a Concept Specialization is NOT a decl, its an expression, so
we weren't able to put the concept in the decl tree like we needed.
This patch introduces a ConceptSpecializationDecl, which is the smallest
type possible to use for this purpose, containing only the template
arguments.

The net memory impliciation of this is turning a
trailing-objects into a pointer to a type with trailing-objects,  so it
should be minor.

As future work, we may consider giving this type more responsibility, or
figuring out how to better merge duplicates, but as this is just a
template-argument collection at the moment, there isn't much value to
it.

Differential Revision: https://reviews.llvm.org/D136451
2022-10-24 06:32:18 -07:00
Haojian Wu
dc7b1e9db5 [AST] Fix the CXXFoldExpr source range when parentheses range is invalid.
The CXXFoldExpr's range is invalid if the cxxfoldexpr is formed via the
Concept's TypeContraints (because the parentheses are not written in the
source code). We fallback to use the range from the pattern.

Differential Revision: https://reviews.llvm.org/D85645
2020-08-12 09:20:23 +02:00
Haojian Wu
626d0f5818 [Concepts] Dump template arguments for immediately declared constraint.
The template arguments were dumped as part of the TemplateTypeParmDecl, which
was incorrect.

Differential Revision: https://reviews.llvm.org/D85282
2020-08-10 09:11:55 +02:00
Haojian Wu
1c0a0dfa02 [Concepts] Include the found concept decl when dumping the ConceptSpecializationExpr
Differential Revision: https://reviews.llvm.org/D85124
2020-08-04 15:58:12 +02:00
Nathan Ridge
4ede396849 [clang] Include trailing-requires-clause in FunctionDecl's source range
Fixes https://github.com/clangd/clangd/issues/476

Differential Revision: https://reviews.llvm.org/D85108
2020-08-04 02:52:01 -04:00
Nathan Ridge
89247792c5 [clang] Fix ConceptSpecializationExpr::getEndLoc()
Summary:
It returned an invalid location in case of a constrained-parameter
with no explicit arguments.

Reviewers: hokein

Subscribers: cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D84613
2020-07-29 02:44:26 -04:00
Haojian Wu
c0bd9fa137 [Concepts] Fix ast dump for immediately declared constraint.
Reviewed By: nridge

Differential Revision: https://reviews.llvm.org/D84461
2020-07-28 12:10:03 +02:00