[PATCH] D74103: Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Ugh, you mentioned template argument lists and made me realize we can still reach problem cases that way. And with array bounds. :(

I've added back in a diagnostic for the case where we compute the linkage too early for a "C-like" struct. Hopefully people won't hit it too much.



================
Comment at: clang/lib/Sema/SemaDecl.cpp:4394
+        isa<EnumDecl>(D))
+      continue;
+
----------------
rjmccall wrote:
> rsmith wrote:
> > rjmccall wrote:
> > > This is essentially part of the next paragraph.
> > > 
> > > I believe `friend` declarations also do not declare "members", under the same logic allowing `static_assert`.
> > I think you're right, but that's a defect in the wording -- a friend definition, at least, could use the class in a way that requires a linkage calculation, and the design intent as approved by the Evolution Working Group did not permit friend declarations. I'll take this back to the committee for some rewording, but I think it makes sense to proceed under the assumption that friends won't be allowed. In any case, I'm updating the diagnostic to treat friends as a special case, since they're not member declarations.
> Could it?  I think the same inability to write a self-reference that makes the C-like cases okay should also apply to friends.  If you can write a self-reference in a friend declaration, you can write one in a template argument list in the type of a field declaration.  Well, okay,  I suppose a friend function *definition* might need to be forbidden.
> 
> Anyway, I don't think it's actually a problem if the committee wants to outlaw friends here, just wondering at the effective rule they're aiming for in case we need to figure out how to apply it to extensions.
Hm. Now you come to mention it, I think friends might actually be fine -- or at least no worse than non-static data members -- from a linkage perspective.

The intended rule is described [in P1766R1 section 2.3](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1766r1.html#proposed-resolution). If there are extensions that we permit in C structs, it would presumably be reasonable to permit them here too, but I would expect that C++-specific extensions should be disallowed here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74103