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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
