================
@@ -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:
Thinking out loud... Do we actually want two things?
1) `-Wchanges-meaning` implementation which diagnoses the declarations when
their meanings change. This diagnostic would be tied to
`-fexperimental-late-parse-attributes` for the cases discussed in this PR.
2) `-Wpotentially-confusing-use-of-identifier-thanks-to-lookup-rules` (let's
pick a much better name for this, obviously) which diagnoses id expressions
where the lookup rules find an unambiguous declaration but a human reader of
the source code could reasonably expect a different lookup result. We have to
be careful here though because this is not the expression form of `-Wshadow`.
e.g., we would not want to diagnose this as potentially confusing because it's
hard to argue that the lookup rules are unclear:
```
void func() {
int n;
{
int n; // Shadow warning makes sense
n = 12; // Not confusing as an expression
}
};
```
so we'd have to figure out what rules we use to determine whether something is
potentially confusing or not.
https://github.com/llvm/llvm-project/pull/181550
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
