================
@@ -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.
> We could then extend it to struct fields in a follow-up, perhaps as
> `-Warray-size-confusion-fields`:
>
> ```c
> constexpr int n = 10;
> struct f {
> int n;
> int arr[n]; // warn: potential array size confusion
> };
> ```
>
> That said, the struct field case may be more controversial — the suppression
> story is less clear, since renaming a field or a global has broader impact
> than renaming a parameter.
Good point about the suppression mechanism. We also don't have a particularly
good way to say "I know the array parameter may be potentially confusing but
it's fine and I don't want to rename it" short of disabling the diagnostic. We
use parens in other places to suppress diagnostics, but I'm not certain that's
a good idea here. e.g.,
```
constexpr int n = 10;
void func1(int arr[n], int n); // warn: potential array size confusion
void func2(int arr[(n)], int n); // no warning about n being confusing
```
it just seems too clever as a suppression, but I also don't have other ideas
currently.
https://github.com/llvm/llvm-project/pull/181550
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
