================
@@ -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:
> > > To keep the scope of this PR manageable, should we focus specifically on
> > > array parameter size confusion — which is what the C standard committee
> > > is most immediately concerned with?
> >
> >
> > I think that's the important use case to consider, but...
> > > We could introduce something like `-Warray-size-confusion-parameters`:
> > > ```c
> > > constexpr int n = 10;
> > > void func(int arr[n], int n); // warn: potential array size confusion
> > > ```
> >
> >
> > I think it's worth diagnosing the use of `n` as an expression, but what the
> > diagnostic says depends on what other flags are enabled, right? e.g., this
> > is either "potential array size confusion" when in standards mode, but when
> > in a dialect mode, it's a "changes meaning" issue that's worth calling out
> > with a distinct diagnostic.
>
> Could you clarify what you mean by "diagnosing the use of n as an expression"?
e.g.,
```
constexpr int n = 10; // #first
void func(
int arr[n], // 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 arr[n], // #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'
);
```
>
> What `-fexperimental-late-parse-attributes` and
> `-fexperimental-bounds-safety` affect is name lookup within the attribute
> itself — not array sizes — so I think we can treat that as a separate concern
> for now, and revisit it when we've made more progress toward removing the
> "experimental" prefix.
https://github.com/llvm/llvm-project/pull/181550
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
