[clang] Diagnose potential size confusion with VLA params [contd.] (PR #181550)

[Yeoul Na via cfe-commits]

================
@@ -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">;
----------------
rapidsna wrote:

> > To clarify my earlier point: -fexperimental-late-parse-attributes is intended to change parsing behavior within attributes (as the flag name suggests), not array sizes — and the same applies to -fbounds-safety. The reason these dialects are relevant to this PR, however, is that what we learn here may inform decisions about them down the road — for example, whether this name lookup behavior remains experimental and gets superseded by whatever approach array sizes end up taking, or whether it evolves into something more broadly applicable to the core language.
> 
> But it's the same two approaches whether we're diagnosing arrays or attributes, right? e.g.,
> 
> ```
> constexpr int n = 10; // #first
> void func(
>   int * __counted_by(n) arr,  // expected-warning: use of 'n' is potentially confusing \
>                                  expected-note@#first: 'n' refers to this declaration \
>                                  expected-ntoe@#second: but could potentially be confused for this 'n'
>   int n // #second
> );
> ```
> 
> as opposed to the changes meaning form:
> 
> ```
> constexpr int n = 10; // #second
> void func(
>   int * __counted_by(n) arr, // #first
>   int n  // expected-warning: declaration of 'n' changes meaning \
>             expected-note@#first: this use of 'n' refers to the parameter declaration \
>             expected-note@#second: not this declaration of 'n'
> );
> ```

Yes, for the -Warray-parameter-size-confusion case. You're right that it can be extended to cover attributes as well. The distinction, though, is that the "changes meaning" form would only apply to attributes for now — not to arrays — at least not until the core language itself potentially adopts that behavior, which is likely far off if it happens at all.

https://github.com/llvm/llvm-project/pull/181550