Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...