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

Reply via email to