[clang] [Clang] Don't diagnose VLA for `-std=gnu++*` by default (PR #89943)

[Erich Keane via cfe-commits]

erichkeane wrote:

> > > This was discussed in this RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 and our decision to move forward with that is independent of what GCC does.
> > 
> > 
> > I saw that discussion, but I do miss where it has been agreed to diverge from GCC on this. Maybe more generic question will clear my misunderstanding: what is a stance of Clang on`-std=gnu++*`? Can it be different to what GCC does?
> 
> Yes, we already differ in many, many ways from GCC in gnu modes, especially when it comes to diagnostics. We often aim for compatibility, but it's not a hard requirement that we follow GCC's lead. Other examples include (but certainly are not limited to): https://godbolt.org/z/sj3oEqj8Y
> 
> > > Without more justification for walking this back, I do not agree with moving forward with the revert.
> > 
> > 
> > We have library code that has to use VLA in source code in certain scenario and rely on compiler to optimize it away. The library is built with `-Wall` and after it started to use newer Clang, the error appear. The main concern is simple: GCC doesn't do that (yet). Understandably, if GCC agrees to diagnose it, that change will need to be reverted.
> 
> Yeah, this sort of problem crops up when we diverge in diagnostic behavior, but isn't a reason to revert a useful diagnostic. Due to the nature of the syntax for declaring a VLA, many instances of VLA use in C++ (and even in C) are purely accidental and C++ often has better alternatives. Because your use of VLAs is intentional, I'd recommend adding `-Wno-vla` to your build script.

Note that if this is troublesome, we support `#pragma clang diagnostic` that you can wrap around hte individual declarations: https://godbolt.org/z/8eb3bcfTW 

https://github.com/llvm/llvm-project/pull/89943