================
@@ -1114,7 +1114,8 @@ def VexingParse : DiagGroup<"vexing-parse">;
def VLAUseStaticAssert : DiagGroup<"vla-extension-static-assert">;
def VLACxxExtension : DiagGroup<"vla-cxx-extension", [VLAUseStaticAssert]>;
def VLAExtension : DiagGroup<"vla-extension", [VLACxxExtension]>;
-def VLA : DiagGroup<"vla", [VLAExtension]>;
+def VLASizeConfusion : DiagGroup<"vla-potential-size-confusion">;
----------------
AaronBallman wrote:
Thanks for your patience, WG14 meetings got in the way of my getting back to
this review until now.
I think `-Wchanges-meaning` is an interesting mental model but that's about a
subsequent definition changing the meaning of a previously defined identifier
and I think we're in a different situation here. At the point of declaration
for the name, we don't know if it's a problem (beyond what `-Wshadow` covers).
It's at the point of use as an id expression that we want to diagnose potential
confusion. And it's not necessarily even about whether the name is hidden via
shadowing, such as with `double n; struct S { int n; int array[sizeof(n)]; };`
because there's no shadowing involved there; the member `n` is entirely
invisible within the structure member list in C.
That said, another way to look at this could be: when bounds safety is enabled,
`-Wchanges-meaning` is more relevant because the subsequent declaration may
change the meaning of what's looked up and what we want to diagnose is the
declaration and not the use. e.g., `int n; void func(int n, int array[n]);`
would diagnose the `int n` parameter declaration as changing the meaning of
`int array[n]`, but not diagnose something like `int n; void func(int n, int
array[12]);` because the parameter declaration of `n` did not change the
meaning of anything.
https://github.com/llvm/llvm-project/pull/181550
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
