|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
aee49255 |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
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 Ha
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).
show more ...
|
| #
f9ad1d1c |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them ou
Revert "Compress formatting of array type names (int [4] -> int[4])"
Looks like lldb has some issues with this - somehow it causes lldb to
treat a "char[N]" type as an array of chars (prints them out
individually) but a "char [N]" is printed as a string. (even though the
DWARF doesn't have this string in it - it's something to do with the
string lldb generates for itself using clang)
This reverts commit 277623f4d5a672d707390e2c3eaf30a9eb4b075c.
show more ...
|
| #
277623f4 |
| 14-Oct-2021 |
David Blaikie <[email protected]> |
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 HasEmptyPlac
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).
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1 |
|
| #
f7f2e426 |
| 13-Oct-2020 |
Richard Smith <[email protected]> |
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 ...
|
| #
69f7c006 |
| 14-Oct-2020 |
Richard Smith <[email protected]> |
Revert "PR47805: Use a single object for a function parameter in the caller and"
Breaks a clangd unit test.
This reverts commit 8f8b9f2cca0b73314342c721186ae9c860ca273c.
|
| #
8f8b9f2c |
| 13-Oct-2020 |
Richard Smith <[email protected]> |
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 ...
|
| #
ab870f30 |
| 13-Oct-2020 |
Richard Smith <[email protected]> |
Revert "PR47805: Use a single object for a function parameter in the caller and"
The buildbots are displeased.
This reverts commit 8d03a972ce8e92815ffe3d5d86aa027605ed92e2.
|
| #
8d03a972 |
| 13-Oct-2020 |
Richard Smith <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2 |
|
| #
6f339367 |
| 19-Aug-2020 |
Richard Smith <[email protected]> |
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.
|
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
e7545b33 |
| 29-Apr-2016 |
Alexey Bataev <[email protected]> |
Implementation of VlA of GNU C++ extension, by Vladimir Yakovlev.
This enables GNU C++ extension "Variable length array" by default.
Differential Revision: http://reviews.llvm.org/D18823
llvm-svn:
Implementation of VlA of GNU C++ extension, by Vladimir Yakovlev.
This enables GNU C++ extension "Variable length array" by default.
Differential Revision: http://reviews.llvm.org/D18823
llvm-svn: 268018
show more ...
|
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
774c6d03 |
| 06-Feb-2014 |
Serge Pavlov <[email protected]> |
Allow transformation of VariableArray to ConstantArray.
In the following code:
struct A { static const int sz; };
template<class T> void f() { T arr[A::sz]; }
the array 'arr' is represente
Allow transformation of VariableArray to ConstantArray.
In the following code:
struct A { static const int sz; };
template<class T> void f() { T arr[A::sz]; }
the array 'arr' is represented as a variable size array in the template.
If 'A::sz' gets value below in the translation unit, the array in
instantiation can turn into constant size array.
This change fixes PR18633.
Differential Revision: http://llvm-reviews.chandlerc.com/D2688
llvm-svn: 200899
show more ...
|
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1 |
|
| #
44ecdbdc |
| 31-Jan-2013 |
Richard Smith <[email protected]> |
Improve 'failed template argument deduction' diagnostic for the case where we
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says
Improve 'failed template argument deduction' diagnostic for the case where we
have a direct mismatch between some component of the template and some
component of the argument. The diagnostic now says what the mismatch was, but
doesn't yet say which part of the template doesn't match.
llvm-svn: 174039
show more ...
|
| #
6c926ccb |
| 23-Jan-2013 |
Dmitri Gribenko <[email protected]> |
Implement -Wvla correctly
GCC implements -Wvla as "warn on every VLA" (this is useful to find every VLA,
for example, if they are forbidden by coding guidelines). Currently Clang
implements -Wvla a
Implement -Wvla correctly
GCC implements -Wvla as "warn on every VLA" (this is useful to find every VLA,
for example, if they are forbidden by coding guidelines). Currently Clang
implements -Wvla as "warn on VLA when it is an extension".
The attached patch makes our behavior match GCC. The existing vla extwarn is
moved under -Wvla-extension and is still included into -Wgnu.
This fixes PR5953.
llvm-svn: 173286
show more ...
|
|
Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3, llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1, llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2, llvmorg-3.1.0-rc1 |
|
| #
dd053f6f |
| 07-Feb-2012 |
Eli Friedman <[email protected]> |
Misc improvements to the diagnostic when a variable is odr-used in a context that is not allowed to capture variables.
Fixes PR11883.
llvm-svn: 149937
|
| #
f7f102f8 |
| 25-Jan-2012 |
Eli Friedman <[email protected]> |
Fix a crash involving a multi-dimensional dependent VLA. PR11744.
llvm-svn: 148989
|
| #
e434590b |
| 29-Dec-2011 |
Richard Smith <[email protected]> |
Change the diagnostics which said 'accepted as an extension' to instead say
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
|
Revision tags: llvmorg-3.0.0, llvmorg-3.0.0-rc4, llvmorg-3.0.0-rc3, llvmorg-3.0.0-rc2, llvmorg-3.0.0-rc1 |
|
| #
f35de48c |
| 14-Jun-2011 |
Chris Lattner <[email protected]> |
when compiling in a GNU mode (e.g. gnu99) treat VLAs with a size that can be folded to a constant
as constant size arrays. This has slightly different semantics in some insane cases, but allows
us t
when compiling in a GNU mode (e.g. gnu99) treat VLAs with a size that can be folded to a constant
as constant size arrays. This has slightly different semantics in some insane cases, but allows
us to accept some constructs that GCC does. Continue to be pedantic in -std=c99 and other
modes. This addressed rdar://8733881 - error "variable-sized object may not be initialized"; g++ accepts same code
llvm-svn: 132983
show more ...
|
|
Revision tags: llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2, llvmorg-2.9.0-rc1, llvmorg-2.8.0 |
|
| #
3999e15d |
| 06-Oct-2010 |
Douglas Gregor <[email protected]> |
Reject the allocation of variably-modified types in C++ 'new'
expressions. Fixes PR8209 in the narrowest way possible. I'm still
considering whether I want to implement the extension that permits the
Reject the allocation of variably-modified types in C++ 'new'
expressions. Fixes PR8209 in the narrowest way possible. I'm still
considering whether I want to implement the extension that permits the
use of VLA types in a 'new' expression.
llvm-svn: 115790
show more ...
|
|
Revision tags: llvmorg-2.8.0-rc3, llvmorg-2.8.0-rc2, llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0 |
|
| #
9a414458 |
| 24-May-2010 |
Douglas Gregor <[email protected]> |
Don't complain about VLAs of non-POD types when the array type is
dependent. Fixes <rdar://problem/8021385>.
llvm-svn: 104550
|
| #
5a5073e4 |
| 24-May-2010 |
Douglas Gregor <[email protected]> |
Make sure that we instantiate variably modified types, even if they
aren't dependent. Fixes <rdar://problem/8020206>.
llvm-svn: 104511
|
| #
a09387df |
| 23-May-2010 |
Douglas Gregor <[email protected]> |
It turns out that people love using VLAs in templates, too. Weaken our
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (wh
It turns out that people love using VLAs in templates, too. Weaken our
VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).
llvm-svn: 104471
show more ...
|
| #
4b636a70 |
| 23-May-2010 |
Douglas Gregor <[email protected]> |
Put the VLA-is-an-extension warning into its own warning group (-Wvla)
so that it can be selectively enabled/disabled.
llvm-svn: 104462
|
| #
5e8c8c0e |
| 23-May-2010 |
Douglas Gregor <[email protected]> |
Even though we don't unique VLA types, we still need to build a
canonical type where the element type is canonical. Fixes PR7206.
llvm-svn: 104461
|
| #
959d5a0c |
| 22-May-2010 |
Douglas Gregor <[email protected]> |
Implement support for variable length arrays in C++. VLAs are limited
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ template
Implement support for variable length arrays in C++. VLAs are limited
in several important ways:
- VLAs of non-POD types are not permitted.
- VLAs cannot be used in conjunction with C++ templates.
These restrictions are intended to keep VLAs out of the parts of the
C++ type system where they cause the most trouble. Fixes PR5678 and
<rdar://problem/8013618>.
llvm-svn: 104443
show more ...
|