Revision tags: 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 |
|
#
9e406ef4 |
| 13-Mar-2024 |
Louis Dionne <ldionne.2@gmail.com> |
[libc++] Remove _LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT (#83928)
This was slated for removal in LLVM 19.
|
Revision tags: 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 |
|
#
5d73c7d1 |
| 22-Nov-2023 |
bgra8 <32298056+bgra8@users.noreply.github.com> |
[libc++] Re-introduce special support for narrowing conversions to bool in variant (#73121)
This patch re-introduces special support for narrowing conversions to
bool
in std::variant, which was re
[libc++] Re-introduce special support for narrowing conversions to bool in variant (#73121)
This patch re-introduces special support for narrowing conversions to
bool
in std::variant, which was removed in 170810fca6ee in order to make
libc++
Standards-conforming.
The special support is gated by the
`_LIBCPP_ENABLE_NARROWING_CONVERSIONS_IN_VARIANT`
macro and will be supported for LLVM 18 only as a courtesy to help large
code bases migrate over to the Standard behavior.
---------
Co-authored-by: Bogdan Graur <bgraur@google.com>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
show more ...
|
#
170810fc |
| 15-Nov-2023 |
David Benjamin <davidben@google.com> |
P1957R2: remove special-case for booleans in std::variant (#71502)
This picks up the std::variant half of P1957R2. Fixes #62332.
|
Revision tags: 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, working, 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 |
|
#
d4b59a05 |
| 30-Sep-2021 |
Arthur O'Dwyer <arthur.j.odwyer@gmail.com> |
[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI.
Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C+
[libc++] Remove "// -*- C++ -*-" comments from all .cpp files. NFCI.
Even if these comments have a benefit in .h files (for editors that care about language but can't be configured to treat .h as C++ code), they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
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, 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, 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 |
|
#
31cbe0f2 |
| 01-Jun-2020 |
Louis Dionne <ldionne@apple.com> |
[libc++] Remove the c++98 Lit feature from the test suite
C++98 and C++03 are effectively aliases as far as Clang is concerned. As such, allowing both std=c++98 and std=c++03 as Lit parameters is ju
[libc++] Remove the c++98 Lit feature from the test suite
C++98 and C++03 are effectively aliases as far as Clang is concerned. As such, allowing both std=c++98 and std=c++03 as Lit parameters is just slightly confusing, but provides no value. It's similar to allowing both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
show more ...
|
Revision tags: 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 |
|
#
80e088e1 |
| 13-Oct-2019 |
Casey Carter <Casey@Carter.net> |
[libc++][test] std::variant test cleanup
* Add the conventional `return 0` to `main` in `variant.assign/conv.pass.cpp` and `variant.ctor/conv.pass.cpp`
* Fix some MSVC signed-to-unsigned conversion
[libc++][test] std::variant test cleanup
* Add the conventional `return 0` to `main` in `variant.assign/conv.pass.cpp` and `variant.ctor/conv.pass.cpp`
* Fix some MSVC signed-to-unsigned conversion warnings by replacing `int` literarls with `unsigned int` literals
llvm-svn: 374723
show more ...
|
Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3 |
|
#
cc89063b |
| 21-Aug-2019 |
Nico Weber <nicolasweber@gmx.de> |
libcxx: Rename .hpp files in libcxx/test/support to .h
LLVM uses .h as its extension for header files.
Files renamed using:
for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done
libcxx: Rename .hpp files in libcxx/test/support to .h
LLVM uses .h as its extension for header files.
Files renamed using:
for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done
References to the files updated using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do a=$(basename $f); echo $a; rg -l $a libcxx | xargs sed -i '' "s/$a/${a%.hpp}.h/"; done
HPP include guards updated manually using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do echo ${f%.hpp}.h ; done | xargs mvim
Differential Revision: https://reviews.llvm.org/D66104
llvm-svn: 369481
show more ...
|
Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init |
|
#
128af315 |
| 12-Jul-2019 |
Eric Fiselier <eric@efcs.ca> |
Add option to disable variant narrowing conversion changes.
The paper P0608R3 - "A sane variant converting constructor" disallows narrowing conversions in variant. It was meant to address this surpr
Add option to disable variant narrowing conversion changes.
The paper P0608R3 - "A sane variant converting constructor" disallows narrowing conversions in variant. It was meant to address this surprising problem:
std::variant<std::string, bool> v = "abc"; assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For example:
variant<unsigned> v = 0; // ill-formed variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke on the order of a hundred thousand target with thousands of root causes responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them exposed outstanding bugs. However, the breakages caused by boolean conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes in variant until the offending code can be cleaned up. For non-trivial variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as clang-tidy, that can automatically fix code broken by this change. In order for clang-tidy to know the correct alternative to construct, it must know what alternative was being constructed previously, which means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change before the 9.0 release branch is cut. But that's a separate discussion that I will start on the lists.
For now this is the minimal first step.
llvm-svn: 365960
show more ...
|