Skip to content

Commit d83485a

Browse files
authored
[clang][NFC] Add test for CWG issues about linkage in cross-TU context (#113736)
[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).
1 parent 1f6741c commit d83485a

File tree

6 files changed

+705
-3
lines changed

6 files changed

+705
-3
lines changed

0 commit comments

Comments
 (0)