llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.45k stars 12.18k forks source link

An explicit specialization declaration shall not be a friend declaration #54352

Open namniav opened 2 years ago

namniav commented 2 years ago

n4861-temp.expl.spec

An explicit specialization declaration shall not be a friend declaration.

Clang compiles this code: https://godbolt.org/z/eeah47bvb

template<int N>
consteval int foo();

template<int N>
struct Foo {
  friend consteval
  int foo<N>() {
      return 1;
  }
};

struct Bar {
    friend consteval
    int foo<1>() {
        return 2;
    }
};

int main() {
  Foo<0> f;
  return foo<0>() + foo<1>();
}
namniav commented 2 years ago

I am not even sure if they are explicit specializations because of missed template<>.

llvmbot commented 2 years ago

@llvm/issue-subscribers-clang-frontend

languagelawyer commented 2 years ago

I am not even sure if they are explicit specializations because of missed template<>.

Thats right, they are not.

namniav commented 2 years ago

@languagelawyer May I ask if this is valid code or Clang incorrectly accepts invalid code or it is UB/ill-formed NDR ?

languagelawyer commented 2 years ago

See e.g. https://stackoverflow.com/questions/63648248/difference-in-behaviour-between-clang-and-gcc-when-using-a-function-definition-a and the change by p1787 (currently http://eel.is/c++draft/dcl.meaning.general#1.sentence-2)

So, according to the current wording, such friend declarations are ill-formed because they are not of those forms where a template-id as a declarator-id is allowed.

I'm surprised I couldn't find an earlier bug report about this. Although, it could be claimed that the new clarified wording is too fresh.