Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg, rupprecht
Differential Revision: https://reviews.llvm.org/D136554
This feature causes clang to crash when compiling Chrome - see
https://crbug.com/1405031 and
https://github.com/llvm/llvm-project/issues/59675
Revert "[clang] Fix a clang crash on invalid code in C++20 mode."
This reverts commit 32d7aae04fdb58e65a952f281ff2f2c3f396d98f.
Revert "[clang] Remove overly restrictive aggregate paren init logic"
This reverts commit c77a91bb7ba793ec3a6a5da3743ed55056291658.
Revert "[clang][C++20] P0960R3 and P1975R0: Allow initializing aggregates from a parenthesized list of values"
This reverts commit 40c52159d3ee337dbed14e4c73b5616ea354c337.
Looking through the list, I discovered this was implemented and has been
for as long as Clang shows up on godbolt, so this patch updates the
CXXStatus list and adds a test.
This patch implements P0960R3, which allows initialization of aggregates
via parentheses.
As an example:
```
struct S { int i, j; };
S s1(1, 1);
int arr1[2](1, 2);
```
This patch also implements P1975R0, which fixes the wording of P0960R3
for single-argument parenthesized lists so that statements like the
following are allowed:
```
S s2(1);
S s3 = static_cast<S>(1);
S s4 = (S)1;
int (&&arr2)[] = static_cast<int[]>(1);
int (&&arr3)[2] = static_cast<int[2]>(1);
```
This patch was originally authored by @0x59616e and completed by
@ayzhao.
Fixes#54040, Fixes#54041
Co-authored-by: Sheng <ox59616e@gmail.com>
Full write up : https://discourse.llvm.org/t/c-20-rfc-suggestion-desired-regarding-the-implementation-of-p0960r3/63744
Reviewed By: ilya-biryukov
Differential Revision: https://reviews.llvm.org/D129531
This reverts commit f1f1b60c7ba607e9ffe3bc012161d43ef95ac773.
Temporary revert, possibly triggers a new assertion failure on
QualType::getCommonPtr.
We're working on a reproducer, to follow-up on
https://reviews.llvm.org/D136554.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
to member naming a weak member to nullptr.
This fixes a miscompile where constant evaluation would incorrectly
determine that a weak member function pointer is never null.
In passing, also improve the diagnostics for constant evaluation of some
nearby cases.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
This implements WG14 N2975 relaxing requirements for va_start
(https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf), which
does two things:
1) Allows the declaration of a variadic function without any named
arguments. e.g., void f(...) is now valid, as in C++.
2) Modified the signature of the va_start macro to be a variadic macro
that accepts one or more arguments; the second (and later) arguments
are not expanded or evaluated.
I followed the GCC implementation in terms of not modifying the
behavior of `__builtin_va_start` (it still requires exactly two
arguments), but this approach has led to several QoI issues that I've
documented with FIXME comments in the test. Specifically, the
requirement that we do not evaluate *or expand* the second and later
arguments means it's no longer possible to issue diagnostics for
compatibility with older C versions and C++. I am reaching out to
folks in WG14 to see if we can get an NB comment to address these
concerns (the US comment period has already closed, so I cannot file
the comment myself), so the diagnostic behavior may change in the
future.
I took this opportunity to add some documentation for all the related
builtins in this area, since there was no documentation for them yet.
Differential Revision: https://reviews.llvm.org/D139436
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
P1787: //CWG600 is resolved by explaining that accessibility affects naming a member in the sense of the ODR.//
Wording: see changes to [class.access] p1 and p4.
Additional references: [[ http://eel.is/c++draft/basic.def.odr#8.sentence-2 | basic.def.odr/8 ]]: //A function is odr-used if it is named by a potentially-evaluated expression or conversion.//
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139173
P1787: //CWG554 is resolved by using the word “scope” instead of “declarative region”, consistent with its very common use in phrases like “namespace scope”.//
Reviewed By: #clang-language-wg, cor3ntin, aaron.ballman, shafik
Differential Revision: https://reviews.llvm.org/D139172
P1787: //CWG405 is resolved by stating that argument-dependent lookup (sometimes) occurs after an ordinary unqualified lookup (making statements like “finding a variable prevents argument-dependent lookup” formally correct).//
Wording: see changes to [basic.lookup.argdep] p1 and p3
This issue seems a duplicate of CWG218, even though it is not officially recognized. A part of a test for CWG218 is reused here, adding cross-references.
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139095
P1787: // [[ https://wg21.link/cwg952 | CWG952 ]] is resolved by refining the definition of “naming class” per Richard’s suggestion in [[ https://lists.isocpp.org/core/2020/09/9963.php | “CWG1621 and [class.static/2”]].//
Wording:
- [class.static]/2 removed;
- [class.access.base]/5 rephrased.
Currently behavior is the following: unqualified names undergo //unqualified name lookup// [1], which perform //unqualified search// in immediate scope [2]. This scope is the scope the definition of //naming class// [3] refers to. `A::I` is not //accessible// when named in classes `C` and `D` per [3]. In particular, the last item regarding base class ([class.access.base]/5.4) is not applicable, because class `A` is not //accessible// in both classes `C` and `D` per [4].
References:
1. [[ https://eel.is/c++draft/basic.lookup#unqual-4.sentence-2 | basic.lookup.unqual/4 ]]
2. [[ https://eel.is/c++draft/basic.lookup#unqual-3 | basic.lookup.unqual/3 ]]
3. [[ https://eel.is/c++draft/class.access#base-5.sentence-4 | class.access.base/5 ]]
4. [[ https://eel.is/c++draft/class.access#base-4 | class.access.base/4 ]]
Reviewed By: #clang-language-wg, erichkeane, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139326
P1787: "CWG360 is resolved by applying access control to using-declarations."
[[ http://eel.is/c++draft/class.access#general-4.sentence-3 | class.access.general#4 ]]: "When a using-declarator is named, access control is applied to it, not to the declarations that replace it."
Reviewed By: #clang-language-wg, aaron.ballman
Differential Revision: https://reviews.llvm.org/D139090
This reverts commit 26fa17ed2914bd80c066d36b325fd3104e45554c.
This reverts commit 4403c4f9e77e673a2771edfc7ab0ebb234e97485.
There is still an ODR issue causing linker errors, investigating.
Implement https://cplusplus.github.io/CWG/issues/2631.html.
Immediate calls in default arguments and defaults members
are not evaluated.
Instead, we evaluate them when constructing a
`CXXDefaultArgExpr`/`BuildCXXDefaultInitExpr`.
The immediate calls are executed by doing a
transform on the initializing expression.
Note that lambdas are not considering subexpressions so
we do not need to transform them.
As a result of this patch, unused default member
initializers are not considered odr-used, and
errors about members binding to local variables
in an outer scope only surface at the point
where a constructor is defined.
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D136554
A follow-up to D136133. It was mentioned in #58382 that there is a need
to test for DRs that have not been officially resolved yet. This patch
aims to replace original "hackery" with proper handling for such cases.
Highlights:
- Availability can be suffixed (further) with "open", "drafting", or
"review", e.g. // dr2565: 16 open, // drXXXX: 16 c++17 drafting
- Checks are implemented to ensure that this suffix corresponds to
actual issue status
- Non-resolved DRs are counted (stdout of make_cxx_dr_status)
- No changes made to cxx_dr_status.html
- 'c++20' availability suffix added
- Remove 'concurrency' status since it's no longer
on the list of statuses in CWG Active Issues
Differential Revision: https://reviews.llvm.org/D138901
After accepted in Kona, update the code to accept static operator[] as well.
No big code changes: accept this operator as static in SemaDeclCXX, update AST call generation in SemaOverload and update feature macros + tests accordingly.
Reviewed By: cor3ntin, erichkeane, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D138387
CWG2635 prohibits adding a constraint to a structured as a defect
report. This patch implements that restriction.
Differential Revision: https://reviews.llvm.org/D138852
This implement the C++23 paper P2647R1 (adopted in Kona)
Reviewed By: #clang-language-wg, erichkeane
Differential Revision: https://reviews.llvm.org/D138851
This documentation aims to make it cleare how the libc++ pre-commit CI
works. For libc++ developers and other LLVM projects whose changes can
affect libc++.
This was discusses with @aaron.ballman as a follow on some unclearities
for the Clang communitee how the libc++ pre-commit CI works.
Note some parts depend on patches under review as commented in the
documentation.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D133249
The changes in this paper add a new recommended practice. I had
originally marked Clang as supporting this paper because we're not
obligated to follow a recommended practice. However, in retrospect, it
seems more useful to document whether we implement the recommendation
or not. This adds a test for those changes.
template-template parameters. Although it effects whether a template can be
used as an argument for another template, the constraint seems not to
be checked, nor other major implementations (GCC, MSVC, et al.) check it.
Additionally, Part-A of the document seems to have been implemented.
So mark P0857R0 as completed.
Differential Revision: https://reviews.llvm.org/D134128
Implement P2513
This change allows initializing an array of unsigned char,
or char from u8 string literals.
This was done both to support legacy code and for compatibility
with C where char8_t will be typedef to unsigned char.
This is backported to C++20 as per WG21 guidance.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D136449
This introduces support for nullptr and nullptr_t in C2x mode. The
proposal accepted by WG14 is:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3042.htm
Note, there are quite a few incompatibilities with the C++ feature in
some of the edge cases of this feature. Therefore, there are some FIXME
comments in tests for testing behavior that might change after WG14 has
resolved national body comments (a process we've not yet started). So
this implementation might change slightly depending on the resolution
of comments. This is called out explicitly in the release notes as
well.
Differential Revision: https://reviews.llvm.org/D135099
