================ @@ -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:
> 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. Okay, let's see if we're converging on our next steps. :-) We'd like two diagnostics, they don't have to be done in the same PR. One diagnostic is `-Wchanges-meaning` and it only is enabled by `-fexperimental-late-parse-attributes` or `-fbounds-safety` and only triggers on the attribute case where meaning is actually changed today. This is intended to help bounds safety users see where the extension is changing the default lookup rules of the language. The other diagnostic is harder to name, but it's disabled by default and when enabled points out scenarios where the use of a name within a parameter list could be confusing. We expect this to be focused on array size specifiers and attribute arguments, but other scenarios within a parameter list could be supported if we found a need. It should not trigger outside of parameter lists. We might add related diagnostics for other contexts later. Does that seem about right? https://github.com/llvm/llvm-project/pull/181550 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
