[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.
The ClangSA documentation lives in RST format, and the FAQ section of
the old webpage is also migrated from HTML with this change.
---------
Co-authored-by: Donát Nagy <donat.nagy@ericsson.com>
This paper adds 'i' and 'j' as suffixes for forming a _Complex constant.
This feature has been supported in Clang since at least Clang 3.0, so
only test coverage is needed.
It does remove -Wgnu-imaginary-constant in C mode (still used in C++
mode) because the feature is now a C2y feature rather than a GNU one.
[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)
Basically clang already implemented 90% of the feature as an extension.
This commit disables warnings for C23 and aligns types of enumerators
according to the recent wording.
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.
Compiler-rt does support Windows just fine, even if outdated docs pages
didn't list it as one of the supported OSes, this is being rectified in
https://github.com/llvm/llvm-project/pull/106874.
MinGW is another environment configuration on Windows, where compiler-rt
or libgcc is linked in automatically, so there's no issue with having
such builtins functions available.
For MSVC style environments, compiler-rt builtins do work just fine, but
Clang doesn't automatically link them in. See e.g.
https://discourse.llvm.org/t/improve-autolinking-of-compiler-rt-and-libc-on-windows-with-lld-link/71392
for a discussion on how to improve this situation. But none of that
issue is that compiler-rt itself wouldn't support Windows.
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.
WG14 N2401 was removed from the list because it was library-only changes
that don't impact the compiler.
Everything having to do with decimal floating-point types was changed to
No because we do not currently have any support for those.
WG14 N2314 remains Unknown because it has changes to Annex F for binary
floating-point types.
Per [CWG2351](https://wg21.link/CWG2351), allow `void{}`, treated the
same as `void()`: a prvalue expression of type `void` that performs no
initialization.
Note that the AST for the expression `T{}` looks like:
```
// using T = int;
CXXFunctionalCastExpr 'T':'int' functional cast to T <NoOp>
`-InitListExpr 'T':'int'
// using T = const int;
CXXFunctionalCastExpr 'int' functional cast to T <NoOp>
`-InitListExpr 'int'
// using T = void;
CXXFunctionalCastExpr 'T':'void' functional cast to T <ToVoid>
`-InitListExpr 'void'
// using T = const void;
CXXFunctionalCastExpr 'void' functional cast to T <ToVoid>
`-InitListExpr 'void'
```
As for `void()`/`T() [T = const void]`, that looked like
`CXXScalarValueInitExpr 'void'` and is unchanged after this.
For reference, C++98 [5.2.3p2] says:
> The expression `T()`, where `T` is a simple-type-specifier (7.1.5.2)
for a non-array complete object type or the (possibly cv-qualified) void
type, creates an rvalue of the specified type, whose value is determined
by default-initialization (8.5; no initialization is done for the
`void()` case). [*Note:* if `T` is a non-class type that is
*cv-qualified*, the `cv-qualifiers` are ignored when determining the
type of the resulting rvalue (3.10). ]
Though it is a bit of a misnomer that, for `T = void`,
`CXXScalarValueInitExpr` does not perform value initialization, it would
be a breaking change to change the AST node for `void()`, so I simply
reworded the doc comment.
https://cplusplus.github.io/CWG/issues/722.html
nullptr passed to a variadic function now converted to void* in C++.
This does not affect C23 nullptr.
Also fixes -Wformat-pedantic so that it no longer warns for nullptr
passed to %p (because it is converted to void* in C++ and it is allowed
for va_arg(ap, void*) in C23)
Previously, the type of explicit object parameters was not considered
for relational operators. This was defined by CWG2586,
<https://cplusplus.github.io/CWG/issues/2586.html>. This fix also means
CWG2547 <https://cplusplus.github.io/CWG/issues/2547.html> is now fully
implemented. Fixes#100329, fixes#104413.
Now start rejecting invalid rvalue reference parameters, which weren't
checked for, and start accepting non-reference explicit object
parameters (like `bool operator==(this C, C) = default;`) which were
previously rejected for the object param not being a reference.
Also start rejecting non-reference explicit object parameters for
defaulted copy/move assign operators (`A& operator=(this A, const A&) =
default;` is invalid but was previously accepted). Fixes#104414.
Put the newest standards first, same as for the [C++ status
page](https://clang.llvm.org/cxx_status.html).
The diff is pretty busted, but I swear I copy & pasted faithfully 😅
The only change beyond shuffling sections around is unfolding the
sections for C99/C11 (6dbce28763153ca20138b139b9455056f173ee22), which
isn't necessary anymore now that they're safely tucked away towards the
end of the page.
...because it is too noisy to be useful right now, and its architecture
is terrible, so it can't act a starting point of future development.
The main problem with this checker is that it tries to do (or at least
fake) path-sensitive analysis without actually using the established
path-sensitive analysis engine.
Instead of actually tracking the symbolic values and the known
constraints on them, this checker blindly gropes the AST and uses
heuristics like "this variable was seen in a comparison operator
expression that is not a loop condition, so it's probably not too large"
(which was improved in a separate commit to at least ignore comparison
operators that appear after the actual `malloc()` call).
This might have been acceptable in 2011 (when this checker was added),
but since then we developed a significantly better standard approach for
analysis and this old relic doesn't deserve to remain in the codebase.
Needless to say, this primitive approach causes lots of false positives
(and presumably false negatives as well), which ensures that this alpha
checker won't be missed by the users.
Moreover, the goals of this checker would be questionable even if it had
a perfect implementation. It's very aggressive to assume that the
argument of malloc can overflow by default (unless the checker sees a
bounds check); and this produces too many false positives -- perhaps
even for an optin checker. It may be possible to eventually create a
useful (and properly path-sensitive) optin checker for these kinds of
suspicious code, but this is a very low priority goal.
Also note that we already have `alpha.security.TaintedAlloc` which
provides more practical heuristics for detecting somewhat similar
"argument of malloc may be too large" vulnerabilities.
https://cplusplus.github.io/CWG/issues/2627.html
It is no longer a narrowing conversion when converting a bit-field to a
type smaller than the field's declared type if the bit-field has a width
small enough to fit in the target type. This includes integral
promotions (`long long i : 8` promoted to `int` is no longer narrowing,
allowing `c.i <=> c.i`) and list-initialization (`int n{ c.i };`)
Also applies back to C++11 as this is a defect report.
[CWG2137](https://cplusplus.github.io/CWG/issues/2137.html)
This was previously implemented and then reverted in Clang 18 as #77768
This also implements a workaround for
[CWG2311](https://cplusplus.github.io/CWG/issues/2311.html), similarly
to the 2024-03-01 comment for
[CWG2742](https://cplusplus.github.io/CWG/issues/2742.html).
The exact wording this tries to implement, relative to the C++26 draft:
[over.match.list]p(1.2)
> Otherwise, or if no viable initializer-list constructor is found
<ins>and the initializer list does not consist of exactly a single
element with the same cv-unqualified class type as `T`</ins>, overload
resolution is performed again, [...]
[dcl.init.list]p(3.7)
> Otherwise, if `T` is a class type, constructors are considered. The
applicable constructors are enumerated and the best one is chosen
through overload resolution. <ins>If no constructor is found and the
initializer list consists of exactly a single element with the same
cv-unqualified class type as `T`, the object is initialized from that
element (by copy-initialization for copy-list-initialization, or by
direct-initialization for direct-list-initialization). Otherwise,</ins>
if a narrowing conversion (see below) is required [...]
The crux of this paper is that floating point expressions can be
evaluated in a wider format, but the return statement in a function
should still return a value of the function's return type rather than
the wider format type.
Note, this is an Annex F conformance requirement and we do not currently
claim conformance to Annex F, so technically we conform either way.
