[PATCH] D125167: [WIP] Fix member access of anonymous struct/union fields in C

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.


================
Comment at: clang/docs/ReleaseNotes.rst:152-157
+- When forming a member expression, now consider any qualifiers written on an
+  anonymous structure or union as also applying to the field being referenced.
+  This fixes an issue where qualifiers were being ignored, allowing you to
+  assign to a ``const`` field. Note that qualifiers are ignored in C++ and for
+  Microsoft's extension of anonymous objects. This fixes
+  `Issues 48099 <https://github.com/llvm/llvm-project/issues/48099>`_.
----------------
tahonermann wrote:
> Perhaps the first sentence should clarify that it applies only to C modes? Though the code changes don't appear to be specific to C.
> 
> I'm confused by "Note that qualifiers are ignored in C++ and for Microsoft's extension of anonymous objects". I find it very surprising that cv-qualifiers would be ignored in C++. Unless there is a relevant core issue?
I can definitely clarify if we decide to go this route.

The C++ behavior is intentional (https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaDecl.cpp#L5352) but perhaps emergent as the C++ standard is silent on qualifiers on the anonymous union object, but all C++ implementations agree to ignore the qualifiers: https://godbolt.org/z/7Wd8Kn5Mf.


================
Comment at: clang/test/Sema/anonymous-struct-union.c:137-140
+  // It's the access path that picks up the qualifiers, not the direct
+  // declaration of the field itself. So 'i' and 'j' are both 'int'.
+  _Static_assert(_Generic(x.i, int : 1, default : 0), "i is not int?");
+  _Static_assert(_Generic(x.j, int : 1, default : 0), "j is not int?");
----------------
tahonermann wrote:
> Top-level cv-qualifiers are ignored in generic selection expressions, so I'm not sure what these assertions are intended to ensure.
I think this is the second time I've been caught by that. I keep expecting that the "no two associations can use compatible types" to make that situation an error.

I almost wonder if we should give a warning in cases where an association type is qualified (or is an array/function type rather than a decayed pointer)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125167