https://cplusplus.github.io/CWG/issues/2496.html
We failed to diagnose the following in C++23 mode
```
struct S {
virtual void f(); // expected-note {{previous declaration is here}}
};
struct T : S {
virtual void f() &;
};
```
Remove `[expr.prim.req.nested]` check which restrict that local
parameters in constraint-expressions can only appear as unevaluated
operands. This change makes the treatment of examples like `requires`
expressions and other constant expression contexts uniform, consistent
with the adoption of P2280.
References: https://cplusplus.github.io/CWG/issues/2517.html
Fixes #132825
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
The previous approach broke code generation for the MS ABI due to an
unintended code path during constraint substitution. This time we
address the issue by inspecting the evaluation contexts and thereby
avoiding that code path.
This reapplies 96eced624 (#102857).
We already attempted to implement this (it was the intent of the paper),
in that parameters were never considered name-independent. However, we
failed to check that any previously found parameter declaration was also
name-independent.
Note that, as worded, the current resolution is insufficient (I wrote to
CWG with better wording), but there is some consensus on the design
outcome.
Fixes#136373
CWG472 is one of the CWG issues that were assigned to Mike Miller with
`drafting` status, but recently got back to `open`, because Mike is no
longer active in CWG. Nothing to be done here, except for changing the
status.
CWG1432 was recently reopened after a CWG reflector discussion. I
changed the status to claim that we test for the previous resolution.
The resolution of [CWG2285](https://wg21.link/cwg2285) adds the point of
declaration of a structured binding, and was implemented in
bdb84f374c
.
Drive-by changes: modify comment and diagnostic messages mentioned in
CWG2285.
This patch adds test for
[CWG170](https://cplusplus.github.io/CWG/issues/170.html). The
resolution adds explicit undefined behavior, so I think the best we can
do is to put the test into constexpr evaluator. Change to
[expr.static.cast] is not tested, because it was a drive-by fix that
removed an impossible case (I confirmed it using minutes). Minutes
mention several times a comprehensive paper in this design space which
no one seem to remember. I believe it's
[P0149R0](https://wg21.link/p0149r0) "Generalised member pointers".
This patch adds test for
[CWG203](https://cplusplus.github.io/CWG/issues/203.html). Author was
asking to change the type of pointer-to-member expression to be closer
to how it's written as opposed to where the resulting member belongs to,
but was turned down due to backwards compatibility concerns, so we're
testing the status quo.
There are a total of 6 examples in the filing, so I decided to just
throw all of them into the test. I had to turn example 2 into
`constexpr` test that unfortunately requires C++20. Outcomes in example
5 that Tomasz expected are not in line with implementation behavior and
my reading of the Standard. I think he got confused by the fact that
unlike regular pointers, pointers-to-members can be implicitly
_downcasted_, but not upcasted. I left comments in the example.
This patch adds a test for
[CWG794](https://cplusplus.github.io/CWG/issues/794.html), which is an
NB comment closed as NAD. Author was asked to bring a paper to
Evolution, which never happened. So we test for the absence of
base-derived conversion in pointer-to-member conversion.
This patch adds test for
[CWG190](https://cplusplus.github.io/CWG/issues/190.html), leveraging
`__is_layout_compatible` intrinsic added for C++20
`std::is_layout_compatible`. I conservatively set the status to Clang
19, as it's the first release that implemented said intrinsic.
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
This patch brings our C++ DR status page up to date with WG21 updates.
[CWG1223](https://cplusplus.github.io/CWG/issues/1223.html) "Syntactic
disambiguation and _trailing-return-types_" is resolved by
[P2915R0](https://wg21.link/p2915r0) "Proposed resolution for CWG1223".
Both the test and the paper were written by @cor3ntin, so I presume no
updates are needed.
[CWG2819](https://cplusplus.github.io/CWG/issues/2819.html) "Cast from
null pointer value in a constant expression" was revisited and marked as
not a DR, so I updated the test to ensure that the example is not
accepted in C++23 and earlier modes. CC @offsetof.
Tentantive resolutions to the following issues were simply promoted to
actual resolutions, so tests don't require any meaningful changes:
- [CWG2913](https://cplusplus.github.io/CWG/issues/2913.html) "Grammar
for deduction-guide has requires-clause in the wrong position"
(@zyn0217)
- [CWG2915](https://cplusplus.github.io/CWG/issues/2915.html) "Explicit
object parameters of type void" (@MitalAshok)
- [CWG2922](https://cplusplus.github.io/CWG/issues/2922.html) "constexpr
placement-new is too permissive" (@cor3ntin)
As a drive-by fix, I updated the `make_cxx_dr_status` script to
accommodate for `C++23 onwards` and `C++26 onwards` statuses, which are
useful for Core issues that are not DRs.
This is a rebase of #95112 with my own feedback apply as @MitalAshok has
been inactive for a while.
It's fairly important this makes clang 20 as it is a blocker for #107451
---
[CWG2813](https://cplusplus.github.io/CWG/issues/2813.html)
prvalue.member_fn(expression-list) now will not materialize a temporary
for prvalue if member_fn is an explicit object member function, and
prvalue will bind directly to the object parameter.
The E1 in E1.static_member is now a discarded-value expression, so if E1
was a call to a [[nodiscard]] function, there will now be a warning.
This also affects C++98 with [[gnu::warn_unused_result]] functions.
This should not affect C where TemporaryMaterializationConversion is a
no-op.
Closes#100314Fixes#100341
---------
Co-authored-by: Mital Ashok <mital@mitalashok.co.uk>
Unlike the previous version
(https://github.com/llvm/llvm-project/pull/114978), this patch also
removes an unnecessary assert that causes Clang to crash when compiling
such tests. (clang/lib/AST/DeclCXX.cpp)
https://lab.llvm.org/buildbot/#/builders/52/builds/4021
```c++
template <class T>
class X {
public:
X() = default;
virtual ~X() = default;
virtual int foo(int x, int y, T &entry) = 0;
void bar() {
struct Y : public X<T> {
Y() : X() {}
int foo(int, int, T &) override {
return 42;
}
};
}
};
```
the assertions:
```c++
llvm-project/clang/lib/AST/DeclCXX.cpp:2508: void clang::CXXMethodDecl::addOverriddenMethod(const CXXMethodDecl *): Assertion `!MD->getParent()->isDependentContext() && "Can't add an overridden method to a class template!"' failed.
```
I believe that this assert is unnecessary and contradicts the logic of
this patch. After its removal, Clang was successfully built using
itself, and all tests passed.
Currently the following example is a compilation failure:
```cpp
template<typename T> struct A {
typedef int M;
struct B {
typedef void M;
struct C;
};
};
template<typename T> struct A<T>::B::C : A<T> {
M m; // void or int ?
};
```
According to the point 13.8.3.2
```
A dependent base class is a base class that is a dependent type and is not the current instantiation.
Note 2 : A base class can be the current instantiation in the case of a nested class naming an enclosing class as a base.
```
The base class `A` is the current instantiation, because `C` is a nested
class for an enclosing class `A<T>`, it's is the not-dependent base
class and we need to search the names through its scope.
This patch makes this example compile
[CWG279](https://cplusplus.github.io/CWG/issues/279.html) Correspondence
of "names for linkage purposes"
====================
[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.
In both cases discussed in the issue, declaration matching succeeds per
[[basic.link]/8](https://eel.is/c++draft/basic.link#8), thanks to the
> considering declarations of unnamed types to introduce their names for
linkage purposes, if any ([dcl.typedef], [dcl.enum])
and
> they both declare names with external linkage
parts. Which means that both pairs of declarations of `S` and `S2`
declare the same entity.
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) is also
satisfied, because in all cases type is declared.
Then cases diverge. `S` is a pair of a forward declaration and a
definition, which means it's not a subject to
[[basic.def.odr]/15](https://eel.is/c++draft/basic.def.odr#15), hence
it's well-formed. Whereas `S2` is a pair of two definitions, so they are
subjects to
[[basic.def.odr]/15](https://eel.is/c++draft/basic.def.odr#15), which
they do not satisfy due to the violation of the following requirement:
> — Each such definition shall consist of the same sequence of tokens,
<...>
Because per [[class.pre/2]](https://eel.is/c++draft/class#pre-2), class
definition is class-specifier, which includes class-head, but class-head
is different between definitions.
[CWG338](https://cplusplus.github.io/CWG/issues/338.html) Enumerator
name with linkage used as class name in other translation unit
====================
[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.
I believe this CWG issue points to the same underlying issue with old
[basic.link]/9 as CWG1884 (see below), so I'm calling it a duplicate of
CWG1884. Cases described there are a part of an extensive CWG1884 test.
Also worth noting that enumerators don't have linkage these days.
[CWG1884](https://cplusplus.github.io/CWG/issues/1898.html) Unclear
requirements for same-named external-linkage entities
====================
[P1787R6](https://wg21.link/p1787r6):
> CWG1884, CWG279, and CWG338 are resolved by defining entity identity
explicitly.
[basic.link]/9 quoted in the issue is now split into several pieces.
> Two names that are the same (6.1 [basic.pre])
I believe this is corresponding declarations now, defined in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4).
> and that are declared in different scopes shall denote the same
variable, function, type, enumerator, template or namespace if
This is covered by
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) after it's
determined by [[basic.link]/8](https://eel.is/c++draft/basic.link#8)
that two declarations declare the same entity.
> — both names have external linkage or else both names have internal
linkage and are declared in the same translation unit; and
> — both names refer to members of the same namespace or to members, not
by inheritance, of the same class; and
Most of this is covered by
[[basic.link]/8](https://eel.is/c++draft/basic.link#8).
> — when both names denote functions, the parameter-type-lists of the
functions (9.3.4.6 [dcl.fct]) are identical; and
> — when both names denote function templates, the signatures (13.7.7.2
[temp.over.link]) are the same.
This is corresponding overloads now, defined in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4).
> Among other things, it should be clarified that "declared in" refers
to the namespace of which the name is a member, not the lexical scope in
which the declaration appears (which affects friend declarations,
block-scope extern declarations, and elaborated-type-specifiers).
This is addressed by "have the same target scope" part of
[[basic.link]/8](https://eel.is/c++draft/basic.link#8).
The tests basically test
[[basic.link]/11](https://eel.is/c++draft/basic.link#11) from the
following standpoint:
> The intent is that this rule prevents declaring a name with extenal
linkage to be, for instance, a type in one translation unit and a
namespace in a different translation unit.
See the comment in the beginning of the test for details on testing
approach. Reviewers are advised to check compiler output for any
surprises, but if they are in a hurry, they can search for `FIXME`,
`OK`, and `#cwg1884` to see the most of irregularities in Clang behavior
across the test (not all of them are incorrect behavior, though).
[CWG1898](https://cplusplus.github.io/CWG/issues/1898.html) Use of
“equivalent” in overload resolution
====================
[P1787R6](https://wg21.link/p1787r6):
> CWG1898 is resolved by explicitly using the defined term
parameter-type-list.
Except that now it's called non-object-parameter-type-list, which is
defined in [dcl.fct] [p8](https://eel.is/c++draft/dcl.fct#8) and
[p4](https://eel.is/c++draft/dcl.fct#8).
As for the wording, the first sentence
[\_N4140\_.[over.dcl]/1](https://timsong-cpp.github.io/cppwp/n4140/over.dcl#1)
where the word "equivalent" was used:
> Two function declarations of the same name refer to the same function
if they are in the same scope and have equivalent parameter declarations
([over.load]).
was replaced with what is now known as "corresponding overloads",
defined in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4).
The definition is present in P1787R6, but it's hard to reference,
because the "corresponding overloads" term was coined later.
[P1787R6](https://wg21.link/p1787r6):
> [CWG110](https://cplusplus.github.io/CWG/issues/110.html) is resolved
by reducing the restriction in [temp.pre] to a note (matching the
behavior of GCC, Clang, and ICC).
Wording: see changes to [temp.pre]/7
I believe the wording for the questions raised in the issue is now the
definition of corresponding declarations that is given in
[[basic.scope.scope]/4](https://eel.is/c++draft/basic.scope#scope-4):
> Two declarations correspond if they (re)introduce the same name, both
declare constructors, or both declare destructors, unless
> — either is a using-declarator, or
> — one declares a type (not a typedef-name) and the other declares a
variable, non-static data member other than of an anonymous union
([class.union.anon]), enumerator, function, or function template, or
> — each declares a function or function template and they do not
declare corresponding overloads.
Then it's used as an input for the definition of potentially conflicting
declarations given in
[[basic.scope.scope]/6](https://eel.is/c++draft/basic.scope#scope-6).
Answering the question in the title: yes, having a function template and
a type with the same name that has the same target scope is well-formed.
A keen eye might spot that the current
[[temp.pre]/7](https://eel.is/c++draft/temp.pre#7) note doesn't reflect
all of the exceptions from the definition of corresponding declarations
in [basic.scope.scope]/4, namely 4.1 and 4.2. I believe the note is
defective, and I opened an editorial PR against the draft to fix that:
https://github.com/cplusplus/draft/pull/7284.
https://cplusplus.github.io/CWG/issues/2915.html
Previously, `struct A { void f(this void); };` was accepted with `A::f`
being a member function with no non-object arguments, but it was still a
little wonky because it was still considered an explicit object member
function. Now, this is rejected immediately.
This applies to any language mode with explicit object parameters as
this is a DR (C++23 and C++26)
The PR reapply https://github.com/llvm/llvm-project/pull/97308.
- Implement [CWG1815](https://wg21.link/CWG1815): Support lifetime
extension of temporary created by aggregate initialization using a
default member initializer.
- Fix crash that introduced in
https://github.com/llvm/llvm-project/pull/97308. In
`InitListChecker::FillInEmptyInitForField`, when we enter
rebuild-default-init context, we copy all the contents of the parent
context to the current context, which will cause the `MaybeODRUseExprs`
to be lost. But we don't need to copy the entire context, only the
`DelayedDefaultInitializationContext` was required, which is used to
build `SourceLocExpr`, etc.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
This reverts commit 45c8766973bb3bb73dd8d996231e114dcf45df9f
and 049512e39d96995cb373a76cf2d009a86eaf3aab.
This change triggers failed asserts on inputs like this:
struct a {
} constexpr b;
class c {
public:
c(a);
};
class B {
public:
using d = int;
struct e {
enum { f } g;
int h;
c i;
d j{};
};
};
B::e k{B::e::f, int(), b};
Compiled like this:
clang -target x86_64-linux-gnu -c repro.cpp
clang: ../../clang/lib/CodeGen/CGExpr.cpp:3105: clang::CodeGen::LValue
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(const clang::DeclRefExpr*):
Assertion `(ND->isUsed(false) || !isa<VarDecl>(ND) || E->isNonOdrUse() ||
!E->getLocation().isValid()) && "Should not use decl without marking it used!"' failed.
https://cplusplus.github.io/CWG/issues/2749.html
This DR's effects are backported to C++98.
Does not affect C where integral constant expressions cannot involve
pointers.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
[CWG2486](https://cplusplus.github.io/CWG/issues/2486.html) "Call to
`noexcept` function via `noexcept(false)` pointer/lvalue" allows
`noexcept` functions to be called via `noexcept(false)` pointers or
values. There appears to be no implementation divergence whatsoever:
https://godbolt.org/z/3afTfeEM8. That said, in C++14 and earlier we do
not issue all the diagnostics we issue in C++17 and newer, so I'm
specifying the status of the issue accordingly.
This patch updates `make_cxx_dr_status` script to use the same
spoiler-like way to hide additional details that `cxx_status.html` uses.
This gives implemented yet unresolved DRs new but very familiar look:
I also took an opportunity to fix spelling inconsistency pointed out by
@zygoloid in
https://github.com/llvm/llvm-project/pull/106299#discussion_r1733592539.
I got tired of counting `%s`s when we substitute data into HTML
template, so I replaced them with an f-string (available since Python
3.6), because I had to touch this code anyway.
