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.
> Dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53364
We previously ignored dependent access checks to private members.
These are visible only to the `RequiresExprBodyExpr` (through `PerformDependentDiagnositcs`) and not to the individual requirements.
---
> Non-dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53334
Access to members in a non-dependent context would always yield an
invalid expression. When it appears in a requires-expression, then this
is a hard error as this would always result in a substitution failure.
https://eel.is/c++draft/expr.prim.req#general-note-1
> Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]
> If the substitution of template arguments into a requirement would always result in a substitution failure, the program is ill-formed; no diagnostic required.
The main issue here is the delaying of the diagnostics.
Use a `ParsingDeclRAIIObject` creates a separate diagnostic pool for diagnositcs associated to the `RequiresExprBodyDecl`.
This is important because dependent diagnostics should not be leaked/delayed to higher scopes (Eg. inside a template function or in a trailing requires). These dependent diagnostics must be attached to the `DeclContext` of the parameters of `RequiresExpr` (which is the `RequiresExprBodyDecl` in this case).
Non dependent diagnostics, on the other hand, should not delayed and surfaced as hard errors.
Differential Revision: https://reviews.llvm.org/D140547
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
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
requires-expression
As reported: https://github.com/llvm/llvm-project/issues/57487
We properly treated a failed instantiation of a concept as a
unsatisified constraint, however, we need to do this at the 'requires
clause' level as well. This ensures that the parameters on a requires
clause that fail instantiation will cause a satisfaction failure.
This patch implements this by running requires parameter clause
instantiation under a SFINAE trap, then stores any such failure as a
requirement failure, so it can be diagnosed later.
Given a dependent `T` (maybe an undeduced `auto`),
Before:
new T(z) --> new T((z)) # changes meaning with more args
new T{z} --> new T{z}
T(z) --> T(z)
T{z} --> T({z}) # forbidden if T is auto
After:
new T(z) --> new T(z)
new T{z} --> new T{z}
T(z) --> T(z)
T{z} --> T{z}
Depends on D113393
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D120608
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.
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
