[PATCH] D92024: [clang] Implement P0692R1 from C++20 (access checking on specializations and instantiations)

[Alex Orlov via Phabricator via cfe-commits]

aorlov added inline comments.


================
Comment at: clang/test/CXX/temp/temp.spec/func.spec.cpp:105
+template <typename T> void func10(A::B<T>, int x) {}
+template <typename T> void func11(A::C, A::D<T>, int) {}
+template <typename T> void func12() {}
----------------
krisb wrote:
> aorlov wrote:
> > krisb wrote:
> > > Before this patch clang diagnosed cases like 
> > > 
> > > ```
> > > class A { class C {}; };
> > > template <typename T> void func(A::C) {}
> > > ```
> > > Why is it no longer the case?
> > > 
> > Your example generates an error `error: 'C' is a private member of 'A'` on latest clang.
> > This patch is intended to implement a proposal [[ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0692r1.html | p0692r1]] and consider this example as valid.
> > Did I understand your question correctly?
> It doesn't seem the aforementioned example falls under any of the cases from P0692R1 unless I misinterpreted its wordings.
> It's a primary template, right?
> Consider also the following example for which clang issues the error in both cases (before and after the patch):
> ```
> class A { class C {}; };
> template <class T> A::C func();
> ```
> I'm also wondering about something like:
> ```
> class A { class C {}; };
> template <typename T> T func() {}
> template <> A::C func<A::C>();
> ```
Oh, I caught the point.
The paper says that the usual access checking rules do **not** apply to:
  - partial specialization
  - explicit instantiation
  - explicit specialization
Also it comes out from the Standard that the usual access checking rules **applies** to __primary__ templates, only if they are not declared as //friends//.

> ```
> class A { class C {}; };
> template <typename T> void func(A::C) {}
> ```
> It's a primary template, right?
Yes, it is a primary template.  The access checking rules should work here. But they do not after this patch. This is a mistake I will sort out.

> Consider also the following example for which clang issues the error in both cases (before and after the patch):
> ```
> class A { class C {}; };
> template <class T> A::C func();
> ```
This is also a primary template and should be handled with the access rules. The patch turns it off. This is a mistake. I'll handle.
> I'm also wondering about something like:
> ```
> class A { class C {}; };
> template <typename T> T func() {}
> template <> A::C func<A::C>();
> ```
This is an explicit specialization. It should not issue any errors here. The patch handles it correctly. It's OK.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92024/new/

https://reviews.llvm.org/D92024