[all-commits] [llvm/llvm-project] 4a505e: [clang] Add tests for CWG issues about friend decl...

Mon Sep 2 07:21:05 PDT 2024

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4a505e15e768011e47101cf9aeb0c7787fdc9acf
      https://github.com/llvm/llvm-project/commit/4a505e15e768011e47101cf9aeb0c7787fdc9acf
  Author: Vlad Serebrennikov <serebrennikov.vladislav at gmail.com>
  Date:   2024-09-02 (Mon, 02 Sep 2024)

  Changed paths:
    M clang/test/CXX/drs/cwg14xx.cpp
    M clang/test/CXX/drs/cwg19xx.cpp
    M clang/test/CXX/drs/cwg1xx.cpp
    M clang/test/CXX/drs/cwg3xx.cpp
    M clang/www/cxx_dr_status.html

  Log Message:
  -----------
  [clang] Add tests for CWG issues about friend declaration matching (#106117)

This patch covers CWG issues regarding declaration matching when
`friend` declarations are involved:
[CWG138](https://cplusplus.github.io/CWG/issues/138.html),
[CWG386](https://cplusplus.github.io/CWG/issues/386.html),
[CWG1477](https://cplusplus.github.io/CWG/issues/1477.html), and
[CWG1900](https://cplusplus.github.io/CWG/issues/1900.html). Atypical
for our CWG tests, the ones in this patch are quite extensively
commented in-line, explaining the mechanics. PR description focuses on
high-level concerns and references.

[CWG138](https://cplusplus.github.io/CWG/issues/138.html) "Friend
declaration name lookup"
-----------

[P1787R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html):
> [CWG138](https://cplusplus.github.io/CWG/issues/138.html) is resolved
according to [N1229](http://wg21.link/n1229), except that
using-directives that nominate nested namespaces are considered.

I find it hard to pin down the scope of this issue, so I'm relying on
three examples from the filing to define it. Because of that, it's also
hard to pinpoint exact wording changes that resolve it. Relevant
references are:
[[dcl.meaning.general]/2](http://eel.is/c++draft/dcl.meaning#general-2),
[[namespace.udecl]/10](https://eel.is/c++draft/namespace.udecl#10),
[[dcl.type.elab]/3](https://eel.is/c++draft/dcl.type.elab#3),
[[basic.lookup.elab]/1](https://eel.is/c++draft/basic.lookup.elab#1).

[CWG386](https://cplusplus.github.io/CWG/issues/386.html) "Friend
declaration of name brought in by _using-declaration_"
-----------

[P1787R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html):
> [CWG386](https://cplusplus.github.io/CWG/issues/386.html),
[CWG1839](https://cplusplus.github.io/CWG/issues/1839.html),
[CWG1818](https://cplusplus.github.io/CWG/issues/1818.html),
[CWG2058](https://cplusplus.github.io/CWG/issues/2058.html),
[CWG1900](https://cplusplus.github.io/CWG/issues/1900.html), and
Richard’s observation in [“are non-type names ignored in a
class-head-name or
enum-head-name?”](http://lists.isocpp.org/core/2017/01/1604.php) are
resolved by describing the limited lookup that occurs for a
declarator-id, including the changes in Richard’s [proposed resolution
for
CWG1839](http://wiki.edg.com/pub/Wg21cologne2019/CoreWorkingGroup/cwg1839.html)
(which also resolves CWG1818 and what of CWG2058 was not resolved along
with CWG2059) and rejecting the example from
[CWG1477](https://cplusplus.github.io/CWG/issues/1477.html).

Wording
([[dcl.meaning.general]/2](http://eel.is/c++draft/dcl.meaning#general-2)):
> — If the
[id-expression](http://eel.is/c++draft/expr.prim.id.general#nt:id-expression)
E in the
[declarator-id](http://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
of the
[declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator) is a
[qualified-id](http://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id)
or a [template-id](http://eel.is/c++draft/temp.names#nt:template-id):
>      — [...]
>      — The
[declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator)
shall correspond to one or more declarations found by the lookup; they
shall all have the same target scope, and the target scope of the
[declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator) is
that
scope[.](http://eel.is/c++draft/dcl.meaning#general-2.2.2.sentence-1)

This issue focuses on interaction of `friend` declarations with
template-id and qualified-id with using-declarations. The short answer
is that terminal name in such declarations undergo lookup, and
using-declarations do what they usually do helping that lookup. Target
scope of such friend declaration is the target scope of lookup result,
so no conflicts arise with the using-declarations.

[CWG1477](https://cplusplus.github.io/CWG/issues/1477.html) "Definition
of a `friend` outside its namespace"
-----------

[P1787R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html):
> [...] and rejecting the example from
[CWG1477](https://cplusplus.github.io/CWG/issues/1477.html).

Wording
([[dcl.meaning.general]/3.4](http://eel.is/c++draft/dcl.meaning#general-3.4)):
> Otherwise, the terminal name of the
[declarator-id](http://eel.is/c++draft/dcl.decl.general#nt:declarator-id)
is not looked
up[.](http://eel.is/c++draft/dcl.meaning#general-3.4.sentence-1)
If it is a qualified name, the
[declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator)
shall correspond to one or more declarations nominable in S; all the
declarations shall have the same target scope and the target scope of
the [declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator)
is that
scope[.](http://eel.is/c++draft/dcl.meaning#general-3.4.sentence-2)

This issue focuses on befriending a function in one scope, then defining
it from other scope using qualified-id. Contrary to what P1787R6 says in
prose, this example is accepted by the wording in that paper. In the
wording quote above, note the absence of a statement like "terminal name
of the declarator-id is not bound", contrary to similar statements made
before that in [dcl.meaning.general] about friend declarations and
template-ids.

There's also a note in [basic.scope.scope] that supports the rejection,
but it's considered incorrect and expected to be removed in the future.
This is tracked in https://github.com/cplusplus/draft/pull/7238.

[CWG1900](https://cplusplus.github.io/CWG/issues/1900.html) "Do `friend`
declarations count as “previous declarations”?"
------------------

[P1787R6](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html):
> [CWG386](https://cplusplus.github.io/CWG/issues/386.html),
[CWG1839](https://cplusplus.github.io/CWG/issues/1839.html),
[CWG1818](https://cplusplus.github.io/CWG/issues/1818.html),
[CWG2058](https://cplusplus.github.io/CWG/issues/2058.html),
[CWG1900](https://cplusplus.github.io/CWG/issues/1900.html), and
Richard’s observation in [“are non-type names ignored in a
class-head-name or
enum-head-name?”](http://lists.isocpp.org/core/2017/01/1604.php) are
resolved by describing the limited lookup that occurs for a
declarator-id, including the changes in Richard’s [proposed resolution
for
CWG1839](http://wiki.edg.com/pub/Wg21cologne2019/CoreWorkingGroup/cwg1839.html)
(which also resolves CWG1818 and what of CWG2058 was not resolved along
with CWG2059) and rejecting the example from
[CWG1477](https://cplusplus.github.io/CWG/issues/1477.html).

Wording
([[dcl.meaning.general]/2.3](http://eel.is/c++draft/dcl.meaning#general-2.3)):
> The declaration's target scope is the innermost enclosing namespace
scope; if the declaration is contained by a block scope, the declaration
shall correspond to a reachable
([[module.reach]](http://eel.is/c++draft/module.reach)) declaration that
inhabits the innermost block
scope[.](http://eel.is/c++draft/dcl.meaning#general-2.3.sentence-2)

Wording
([[basic.scope.scope]/7](http://eel.is/c++draft/basic.scope#scope-7)):
> A declaration is
[nominable](http://eel.is/c++draft/basic.scope#def:nominable) in a
class, class template, or namespace E at a point P if it precedes P, it
does not inhabit a block scope, and its target scope is the scope
associated with E or, if E is a namespace, any element of the inline
namespace set of E
([[namespace.def]](http://eel.is/c++draft/namespace.def))[.](http://eel.is/c++draft/basic.scope#scope-7.sentence-1)

Wording
([[dcl.meaning.general]/3.4](http://eel.is/c++draft/dcl.meaning#general-3.4)):
> If it is a qualified name, the
[declarator](http://eel.is/c++draft/dcl.decl.general#nt:declarator)
shall correspond to one or more declarations nominable in S; [...]

In the new wording it's clear that while `friend` declarations of
functions do not bind names, declaration is still introduced, and is
nominable, making it eligible for a later definition by qualified-id.

To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications