llvm-project/clang/test/Sema/vla.cpp

// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-vla

void f1(int n) {
  typedef int x[n];
  const x y; // expected-error {{default initialization of an object of const type 'const x' (aka 'const int[n]')}}
}
Diagnose use of VLAs in C++ by default Reapplication of 7339c0f782d5c70e0928f8991b0c05338a90c84c with a fix for a crash involving arrays without a size expression. Clang supports VLAs in C++ as an extension, but we currently only warn on their use when you pass -Wvla, -Wvla-extension, or -pedantic. However, VLAs as they're expressed in C have been considered by WG21 and rejected, are easy to use accidentally to the surprise of users (e.g., https://ddanilov.me/default-non-standard-features/), and they have potential security implications beyond constant-size arrays (https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range). C++ users should strongly consider using other functionality such as std::vector instead. This seems like sufficiently compelling evidence to warn users about VLA use by default in C++ modes. This patch enables the -Wvla-extension diagnostic group in C++ language modes by default, and adds the warning group to -Wall in GNU++ language modes. The warning is still opt-in in C language modes, where support for VLAs is somewhat less surprising to users. RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109 Fixes https://github.com/llvm/llvm-project/issues/62836 Differential Revision: https://reviews.llvm.org/D156565 2023-10-20 13:08:50 -04:00			`// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-vla`
Improve printing of const variable sized arrays Follow-on from 40acc0adad59ac39e9a7a02fcd93161298500c00 with help from Richard Smith on how to provoke this particular case. 2021-10-12 15:24:05 -07:00
			`void f1(int n) {`
			`typedef int x[n];`
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int ") behave as though there is a non-empty placeholder (because the "" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc). 2021-10-14 14:52:47 -07:00			`const x y; // expected-error {{default initialization of an object of const type 'const x' (aka 'const int[n]')}}`
Improve printing of const variable sized arrays Follow-on from 40acc0adad59ac39e9a7a02fcd93161298500c00 with help from Richard Smith on how to provoke this particular case. 2021-10-12 15:24:05 -07:00			`}`