A friend function defined in a befriended class cannot access the granting class's private members

[Saldivarcher]

Issue Summary

A friend function that is defined inside a befriended class does not get that
class's access. Class X declares class Y a friend. A hidden friend
function that Y defines cannot name a private member of X. The front end
rejects the access in the function body. In a trailing return type, the access
failure removes the candidate during deduction, and overload resolution then
finds no match.

In the reproducer, each __wrap_iter<T> befriends every __wrap_iter<U>.
The operator- that __wrap_iter<const char *> defines reads __wrap_iter<char *>::__i_.

Reproducing Source Code

namespace std {
template <class _Iter>
class __wrap_iter {
private:
  _Iter __i_;
public:
  constexpr __wrap_iter() noexcept : __i_() {}
private:
  constexpr explicit __wrap_iter(_Iter __x) noexcept : __i_(__x) {}
  template <class _Up>
  friend class __wrap_iter;
  template <class _Iter2>
  friend constexpr auto
  operator-(const __wrap_iter& __x, const __wrap_iter<_Iter2>& __y) noexcept->decltype(__x.__i_ - __y.__i_)
  {
    return __x.__i_ - __y.__i_;
  }
};
}
int main() {
  std::__wrap_iter<char *> a;
  std::__wrap_iter<const char *> b;
  b - a;
}

https://godbolt.org/z/9G3GK5n66

Command-line Options

cpfe --gnu_version=150301 --c++20 --no_wrap_diagnostics --no_code_gen friend_access.cpp

Type of Issue

[Front End] This code SHOULD compile with these options.

Additional Details

Output:

"friend_access.cpp", line 23: error: no operator "-" matches these operands
            operand types are: std::__wrap_iter<const char *> - std::__wrap_iter<char *>
    b - a;
      ^
"friend_access.cpp", line 14: note: function template "std::operator-(const std::__wrap_iter<char *> &, const std::__wrap_iter<_Iter2> &)->decltype((<expression>)) noexcept" does not match because argument #1 does not match parameter
    operator-(const __wrap_iter& __x, const __wrap_iter<_Iter2>& __y) noexcept->decltype(__x.__i_ - __y.__i_)
    ^
"friend_access.cpp", line 14: note: candidate function template "std::operator-(const std::__wrap_iter<const char *> &, const std::__wrap_iter<_Iter2> &)->decltype((<expression>)) noexcept" failed deduction
    operator-(const __wrap_iter& __x, const __wrap_iter<_Iter2>& __y) noexcept->decltype(__x.__i_ - __y.__i_)
    ^
"friend_access.cpp", line 23: note: built-in operator-(<promoted arithmetic>, <promoted arithmetic>) does not match because argument #1 does not match parameter
    b - a;
      ^
"friend_access.cpp", line 23: note: built-in operator-(<pointer to object>, <ptrdiff_t>) does not match because argument #1 does not match parameter
    b - a;
      ^

1 error detected in the compilation of "friend_access.cpp".

--clang_version=210000 and the default mode give the same error. EDG 6.5,
7.0 and trunk on Compiler Explorer give the same error too.

Expected: no diagnostic. [class.friend]/2 lets a befriended class name
private members of the granting class in its member declarations. The friend
definition of operator- is a member-declaration of
__wrap_iter<const char *>. GCC 15 and Clang 21 accept the program at
-std=c++20.

Analysis

The access check is the cause:

• When __i_ is public, the front end accepts the program.

• When the trailing return type is removed, the front end reports the access
  failure in the body directly:

  "friend_access.cpp", line 16: error: member "std::__wrap_iter<_Iter>::__i_ [with _Iter=char *]" (declared at line 5) is inaccessible
        return __x.__i_ - __y.__i_;
  

MSVC also rejects the program (error C2676, with the note
'std::__wrap_iter<char *>::__i_': cannot access private member).
CWG1699 ("Does befriending
a class befriend its friends?") is open. Thus the strict conformance answer is
not settled. But GCC and Clang both accept the program. Thus the front end
should accept it, at least in the GNU and Clang emulation modes.

Possibly related: #158 (GNATS 27807) reports a spurious "is inaccessible"
error in Boost's rbtree_best_fit.hpp. That report also names a friend. I did
not examine the Boost code, so I do not know if the cause is the same.

Reproducing (Standard) Configuration(s)

linux-gcc-debug

Reproducing (Non-standard) Configuration

No response

I acknowledge that:

• I have checked open issues and existing discussions before filing this report.
• The reproducing source code that I have provided does not depend on headers that I have not included with my submission.
• I have reduced the reproducing source code to the best of my ability.
• I have selected at least one standard configuration or uploaded a non-standard configuration dump.
• I understand code shared via this form is NOT confidential.
• I have permission to share the reproducing source code and grant permission for the project to use the source code (or derivatives of the source code) to create tests.
• I agree that any tests created using the reproducing source code (or deriatives of it) will be licensed under project license unless I included a LICENSE.txt file in my .zip or .tar.gz upload. If I included a LICENSE.txt file, any tests created using the reproducing source code will be governed by the terms of the license I provided instead.