Revert "[Clang] Implement CWG2369 "Ordering between constraints and substitution"" (#122130)

Unfortunately that breaks some code on Windows when lambdas come into
play, as reported in
https://github

Revert "[Clang] Implement CWG2369 "Ordering between constraints and substitution"" (#122130)

Unfortunately that breaks some code on Windows when lambdas come into
play, as reported in
https://github.com/llvm/llvm-project/pull/102857#issuecomment-2577861178

This reverts commit 96eced624e0f120155256033fdcb8342e7e58d6e.

show more ...

[Clang] Implement CWG2369 "Ordering between constraints and substitution" (#102857)

This patch partially implements CWG2369 for non-lambda-constrained
functions.

Lambdas are left intact at this poi

[Clang] Implement CWG2369 "Ordering between constraints and substitution" (#102857)

This patch partially implements CWG2369 for non-lambda-constrained
functions.

Lambdas are left intact at this point because we need extra work to
correctly instantiate captures before the function instantiation.

As a premise of CWG2369, this patch also implements CWG2770 to ensure
the function parameters are instantiated on demand.

Closes https://github.com/llvm/llvm-project/issues/54440

show more ...

Revert "[clang] Reland: Instantiate concepts with sugared template arguments (#101782)" (#102551)

[clang] Reland: Instantiate concepts with sugared template arguments (#101782)

[Sema] `setInvalidDecl` for error deduction declaration

Fixed: https://github.com/llvm/llvm-project/issues/62408
`setInvalidDecl` for invalid `CXXDeductionGuideDecl` to
avoid crashes during semantic

[Sema] `setInvalidDecl` for error deduction declaration

Fixed: https://github.com/llvm/llvm-project/issues/62408
`setInvalidDecl` for invalid `CXXDeductionGuideDecl` to
avoid crashes during semantic analysis.

Reviewed By: aaron.ballman

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

show more ...

Revert "[Sema] `setInvalidDecl` for error deduction declaration"

This reverts commit eb5902ffc97163338bab95d2fd84a953ee76e96f.

Caused buildbot failures on:
https://lab.llvm.org/buildbot/#/builder

Revert "[Sema] `setInvalidDecl` for error deduction declaration"

This reverts commit eb5902ffc97163338bab95d2fd84a953ee76e96f.

Caused buildbot failures on:
https://lab.llvm.org/buildbot/#/builders/139/builds/41248
https://lab.llvm.org/buildbot/#/builders/216/builds/21637

show more ...

[Sema] `setInvalidDecl` for error deduction declaration

Fixed: https://github.com/llvm/llvm-project/issues/62408
`setInvalidDecl` for invalid `CXXDeductionGuideDecl` to
avoid crashes during semantic

[Sema] `setInvalidDecl` for error deduction declaration

Fixed: https://github.com/llvm/llvm-project/issues/62408
`setInvalidDecl` for invalid `CXXDeductionGuideDecl` to
avoid crashes during semantic analysis.

Reviewed By: aaron.ballman

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

show more ...

Revert "[clang] Instantiate concepts with sugared template arguments"

This reverts commit b8064374b217db061213c561ec8f3376681ff9c8.

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

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.

show more ...

[clang][C++20] Add test for crash in NestedRequirement.

Make evaluation of nested requirement consistent with requires expr.

Fixes: https://github.com/llvm/llvm-project/issues/45563
```
template<class T> concept True = true;

template <class T>
concept

Make evaluation of nested requirement consistent with requires expr.

Fixes: https://github.com/llvm/llvm-project/issues/45563
```
template<class T> concept True = true;

template <class T>
concept C1 = requires (T) {
requires True<typename T::value> || True<T>;
};

template <class T>
constexpr bool foo()
requires True<typename T::value> || True<T> {
return true;
}
static_assert(C1<double>); // Previously failed due to SFINAE error
static_assert(foo<int>()); // but this works fine.
```
The issue here is the discrepancy between how a [nested requirement is evaluated](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaTemplateInstantiate.cpp#L2331) Vs how a [non-nested requirement is evaluated](https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaConcept.cpp#L167-L200).

This patch makes constraint checking consistent for nested requirement
and trailing requires expressions by reusing the same evaluator.

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

show more ...

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

[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

show more ...

Revert "[clang] Instantiate concepts with sugared template arguments"

This reverts commit d0a6de59c78010118fea811514e03ed9f400215a.

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

[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

show more ...

[C++2a] P0634r3: Down with typename!

This patch implements P0634r3 that removes the need for 'typename' in certain contexts.

For example,

```
template <typename T>
using foo = T::type; // ok
```

[C++2a] P0634r3: Down with typename!

This patch implements P0634r3 that removes the need for 'typename' in certain contexts.

For example,

```
template <typename T>
using foo = T::type; // ok
```

This is also allowed in previous language versions as an extension, because I think it's pretty useful. :)

Reviewed By: #clang-language-wg, erichkeane

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

show more ...

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to b

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.

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

show more ...

Revert "Rewording the "static_assert" to static assertion"

Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.

This

Revert "Rewording the "static_assert" to static assertion"

Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.

This reverts commit 6542cb55a3eb115b1c3592514590a19987ffc498.

show more ...

Rewording the "static_assert" to static assertion

This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should n

Rewording the "static_assert" to static assertion

This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.

consider a c file having code

_Static_assert(0, "oh no!");

In clang the output is like:

<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1

Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:

<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1

The above can also be seen here. This patch is about rewording
the static_assert to static assertion.

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

show more ...

Revert "Rewording "static_assert" diagnostics"

This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.

Reason: Broke sanitizer builds bots + libcxx. 'static assertion
expression is not an int

Revert "Rewording "static_assert" diagnostics"

This reverts commit b7e77ff25fb2412f6ab6d6cc756666b0e2f97bd3.

Reason: Broke sanitizer builds bots + libcxx. 'static assertion
expression is not an integral constant expression'. More details
available in the Phabricator review: https://reviews.llvm.org/D129048

show more ...

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to b

Rewording "static_assert" diagnostics

This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.

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

show more ...

[Concepts] Make constraint expressions unevaluated until satisfaction checking

As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become c

[Concepts] Make constraint expressions unevaluated until satisfaction checking

As per P1980R0, constraint expressions are unevaluated operands, and their constituent atomic
constraints only become constant evaluated during satisfaction checking.

Change the evaluation context during parsing and instantiation of constraints to unevaluated.

show more ...

[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 impl

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

show more ...

[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 Re

[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

show more ...

[Concepts] Requires Expressions

Implement support for C++2a requires-expressions.

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