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

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

show more ...

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm

Revert "Diagnose use of VLAs in C++ by default"

This reverts commit 7339c0f782d5c70e0928f8991b0c05338a90c84c.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

show more ...

Diagnose use of VLAs in C++ by default

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'r

Diagnose use of VLAs in C++ by default

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

show more ...

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resulting in the destructor for the parameter applying to
the original argument value, ignoring any modifications made in the
function body. This also meant that the 'this' pointer of the function
parameter could be observed changing between the caller and the callee.

This change completely reimplements how we model function parameters
during constant evaluation. We now model them roughly as if they were
variables living in the caller, albeit with an artificially reduced
scope that covers only the duration of the function call, instead of
modeling them as temporaries in the caller that we partially "reparent"
into the callee at the point of the call. This brings some minor
diagnostic improvements, as well as significantly reduced stack usage
during constant evaluation.

show more ...

Revert "PR47805: Use a single object for a function parameter in the caller and"

Breaks a clangd unit test.

This reverts commit 8f8b9f2cca0b73314342c721186ae9c860ca273c.

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resulting in the destructor for the parameter applying to
the original argument value, ignoring any modifications made in the
function body. This also meant that the 'this' pointer of the function
parameter could be observed changing between the caller and the callee.

This change completely reimplements how we model function parameters
during constant evaluation. We now model them roughly as if they were
variables living in the caller, albeit with an artificially reduced
scope that covers only the duration of the function call, instead of
modeling them as temporaries in the caller that we partially "reparent"
into the callee at the point of the call. This brings some minor
diagnostic improvements, as well as significantly reduced stack usage
during constant evaluation.

show more ...

Revert "PR47805: Use a single object for a function parameter in the caller and"

The buildbots are displeased.

This reverts commit 8d03a972ce8e92815ffe3d5d86aa027605ed92e2.

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resultin

PR47805: Use a single object for a function parameter in the caller and
callee in constant evaluation.

We previously made a deep copy of function parameters of class type when
passing them, resulting in the destructor for the parameter applying to
the original argument value, ignoring any modifications made in the
function body. This also meant that the 'this' pointer of the function
parameter could be observed changing between the caller and the callee.

This change completely reimplements how we model function parameters
during constant evaluation. We now model them roughly as if they were
variables living in the caller, albeit with an artificially reduced
scope that covers only the duration of the function call, instead of
modeling them as temporaries in the caller that we partially "reparent"
into the callee at the point of the call. This brings some minor
diagnostic improvements, as well as significantly reduced stack usage
during constant evaluation.

show more ...

Explain why the array bound is non-constant in VLA diagnostics.

In passing, also use a more precise diagnostic to explain why an
expression is not an ICE if it's not of integral type.