Commit Graph

75 Commits

Author SHA1 Message Date
Louis Dionne cb793e1a36 [libc++][NFCI] Remove uses of _LIBCPP_INLINE_VAR
All supported compilers provide support for inline variables in C++17 now.
Also, as a fly-by fix, replace some uses of _LIBCPP_CONSTEXPR by just
constexpr.

The only exception in this patch is `std::ignore`, which is provided
prior to C++17. Since it is defined in an anonymous namespace, it always
has internal linkage anyway, so using an inline variable there doesn't
provide any benefit. Instead, `inline` was removed entirely on `std::ignore`.

Differential Revision: https://reviews.llvm.org/D110243
2021-09-22 16:03:00 -04:00
Yuanfang Chen 45c0ebe00e [libc++] Surpress -Wunused-value warning in variant
The idiom helps with parameter unpacking so the return value is not
important. Make it explicit.
2021-09-21 15:33:10 -07:00
Louis Dionne a4cb5aefd5 [libc++] Remove some workarounds for unsupported GCC and Clang versions
There is a lot more we can do, in particular in <type_traits>, but this
removes some workarounds that were gated on checking a specific compiler
version.

Differential Revision: https://reviews.llvm.org/D108923
2021-09-01 10:57:14 -04:00
Louis Dionne 3557c7c122 [libc++] Remove workarounds for [[nodebug]] not working properly on typedefs in older Clangs
Clang used to support [[nodebug]] everywhere except on typedefs. Since
we don't support such old Clangs anymore, we can get rid of _LIBCPP_NODEBUG_TYPE
in favour of always using _LIBCPP_NODEBUG.

Differential Revision: https://reviews.llvm.org/D108996
2021-09-01 10:51:09 -04:00
Louis Dionne b28cb53eac [libc++][NFC] Format expression-equivalent wrappers consistently
Differential Revision: https://reviews.llvm.org/D108144
2021-08-17 12:00:32 -04:00
zoecarver 1a29403d2f [libcxx][ranges] Add common_iterator.
Differential Revision: https://reviews.llvm.org/D103335
2021-07-20 08:12:44 -07:00
zoecarver 0849427fae [libcxx][nfc] Remove <variant>'s dependence on <array>.
This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`.

Differential Revision: https://reviews.llvm.org/D105597
2021-07-09 10:13:57 -07:00
Mark de Wever 321c2ea91c [libc++][NFC] Move monostate to its own header.
The format library uses `std::monostate`, but not a `std::variant`.
Moving `std::monostate` to its own header allows the format library to
reduce the amount of included code.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D105582
2021-07-08 17:35:26 +02:00
Christopher Di Bella 6adbc83ee9 [libcxx][modularisation] moves <utility> content out of <type_traits>
Moves:

* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
  `__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
  `__algorithm/${FUNCTION_NAME}`

Differential Revision: https://reviews.llvm.org/D103734
2021-06-24 17:57:29 +00:00
Arthur O'Dwyer bfbd73f87d [libc++] Alphabetize and include-what-you-use. NFCI.
Differential Revision: https://reviews.llvm.org/D102781
2021-05-29 19:54:48 -04:00
Arthur O'Dwyer ab3fcc5065 [libc++] s/_VSTD::declval/declval/g. NFCI. 2021-05-11 12:23:55 -04:00
Louis Dionne 4cd6ca102a [libc++] NFC: Normalize `#endif //` comment indentation 2021-04-20 12:03:32 -04:00
Arthur O'Dwyer 2d0f1fa472 [libc++] Header inclusion tests.
As mandated by the Standard's various synopses, e.g. [iterator.synopsis].
Searching the TeX source for '#include' is a good way to find all of these
mandates.

The new tests are all autogenerated by utils/generate_header_inclusion_tests.py.
I was SHOCKED by how many mandates there are, and how many of them
libc++ wasn't conforming with.

Differential Revision: https://reviews.llvm.org/D99309
2021-04-06 15:31:56 -04:00
Marek Kurdej 0324b46cd8 [libc++] [C++2b] [P2162] Allow inheritance from std::variant.
This patch changes the variant even in pre-C++2b.
It should not break anything, only allow use cases that didn't work previously.

Notes:
 `__as_variant` is used in `__visitation::__variant::__visit_alt`, but I haven't used it in `__visitation::__variant::__visit_alt_at`.
That's because it is used only in `__visit_value_at`, which in turn is always used on variant specializations (that's in comparison operators).

* https://wg21.link/P2162

Reviewed By: ldionne, #libc, Quuxplusone

Differential Revision: https://reviews.llvm.org/D97394
2021-03-25 18:20:50 +01:00
Nico Weber a206d991f9 libcxx: Try to fix build after D92044 2021-01-25 15:10:41 -05:00
Ruslan Arutyunyan 9d50958757 [libc++] Fix build after 51faba35fd
Differential Revision: https://reviews.llvm.org/D95372
2021-01-25 13:40:47 -05:00
Ruslan Arutyunyan 51faba35fd [libc++] Implement P0655R1 visit<R>: Explicit Return Type for visit
Differential Revision: https://reviews.llvm.org/D92044
2021-01-25 11:14:45 -05:00
Arthur O'Dwyer d586f92c94 [libc++] Consistently replace `std::` qualification with `_VSTD::` or nothing. NFCI.
I used a lot of `git grep` to find places where `std::` was being used
outside of comments and assert-messages. There were three outcomes:

- Qualified function calls, e.g. `std::move` becomes `_VSTD::move`.
    This is the most common case.

- Typenames that don't need qualification, e.g. `std::allocator` becomes `allocator`.
    Leaving these as `_VSTD::allocator` would also be fine, but I decided
    that removing the qualification is more consistent with existing practice.

- Names that specifically need un-versioned `std::` qualification,
    or that I wasn't sure about. For example, I didn't touch any code in
    <atomic>, <math.h>, <new>, or any ext/ or experimental/ headers;
    and I didn't touch any instances of `std::type_info`.

In some deduction guides, we were accidentally using `class Alloc = typename std::allocator<T>`,
despite `std::allocator<T>`'s type-ness not being template-dependent.
Because `std::allocator` is a qualified name, this did parse as we intended;
but what we meant was simply `class Alloc = allocator<T>`.

Differential Revision: https://reviews.llvm.org/D92250
2020-12-01 22:13:39 -05:00
Arthur O'Dwyer bbf8a9ca3f [libc++] ADL-proof <variant> by adding _VSTD:: qualification on calls.
Differential Revision: https://reviews.llvm.org/D92036
2020-11-25 09:19:37 -05:00
Eric Fiselier 9c09757bca [libc++] Revert switch-based std::variant implementation again.
These changes cause substantial binary size increases for non-opt builds.
For example, the visit.pass.cpp test grows from 20k to 420k.

Further work will be done to re-land this patch without the size increases,
but that work is proving too tricky to fix forward.

This patch fully reverts:

* 35d2269111

And it partially reverts:

* bb43a0cd4a

The latter of which added XFAIL's to new variant tests
because the new implementation needlessly makes non-throwing code
paths in variant invoke throwing code.

This means the reverted change also breaks source backwards compat
with code compiled on OS X targeting older system dylibs. There is no
need for this to be the case. We should fix it before recommitting.

Reviewed as:
https://reviews.llvm.org/D91662
2020-11-17 23:09:31 -05:00
Louis Dionne bb43a0cd4a [libc++] Add a Buildkite job that tests back-deployment on Apple
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.

At the same time, also fix some tests that were failing when back
deploying.

Differential Revision: https://reviews.llvm.org/D90869
2020-11-05 18:26:08 -05:00
Louis Dionne 2eadbc8614 [libc++] Rework the whole availability markup implementation
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.

For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.

In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.

Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).

Differential Revision: https://reviews.llvm.org/D90843
2020-11-05 12:28:52 -05:00
Michael Park 35d2269111 [libc++] Re-apply the switch-based std::variant implementation
This commit is a mass re-application of the following commits:

  7d15ece79c
  e0ec7a0206
  02197f7e50
  a175a96517

Those were temporarily reverted in 057028ed39, and never re-applied.
Re-committed by @ldionne (author edited for credit).

Differential Revision: https://reviews.llvm.org/D90168
2020-10-28 17:09:11 -04:00
Louis Dionne fe7245b772 [libc++] NFC: Rename variant helpers to avoid name clashes
Some system headers define __constructor and __destructor macros (for
Clang attributes constructor and destructor). While this is badly
behaved, it is easy for libc++ to work around this issue.
2020-10-05 16:41:25 -04:00
Eric Fiselier 057028ed39 Revert switch based variant temporarily.
There are currently some failures caused by this change internally. I'm working
to debug them and hopefully these series of patches should be recommitted by
the end of the week.

Thank you to Micheal Park for the contributions, and for allowing the temporary
rollback.

The commits reverted by this change are:

7d15ece79c
e0ec7a0206
02197f7e50
a175a96517
2020-09-01 22:15:33 -04:00
Michael Park 7d15ece79c [libcxx/variant] Implement workaround for GCC bug.
A parameter pack is deemed to be uncaptured, which is bogus... but it seems to
be because it's within an expression that involves `decltype` of an uncaptured
pack or something: https://godbolt.org/z/b8z3sh

Drive-by fix for uglified name.

Differential Revision: https://reviews.llvm.org/D86827
2020-08-30 12:43:14 -04:00
Michael Park e0ec7a0206
[libcxx/variant] Correctly propagate return type of the visitor.
The tests for it were missing so I've added them.

Reviewed By: #libc, EricWF

Differential Revision: https://reviews.llvm.org/D86006
2020-08-17 10:53:59 -07:00
Michael Park 02197f7e50
[libcxx/variant] Avoided variable name shadowing. 2020-08-14 16:30:27 -07:00
Michael Park a175a96517
[libcxx/variant] Introduce `switch`-based mechanism for `std::visit`.
This patch introduces mechanism for `std::visit` backed by `switch`.
The `switch` is structured such that it's a flattened manual vtable (an n-ary array).
The `switch` mechanism is enabled if `(1 * ... * vs.size()) < 1024`.

The following are performance numbers from the benchmarks added in D85419, tested on my 2017 Macbook Pro.

```
$ ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
2020-08-09 23:55:14
Running ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.03, 2.36, 2.43
------------------------------------------------------------
Benchmark                 Time             CPU   Iterations
------------------------------------------------------------
BM_Visit<1, 1>        0.260 ns        0.260 ns   1000000000
BM_Visit<1, 2>         1.56 ns         1.56 ns    435925220
BM_Visit<1, 3>         1.55 ns         1.55 ns    444416228
BM_Visit<1, 4>         1.57 ns         1.57 ns    427951336
BM_Visit<1, 5>         1.57 ns         1.56 ns    444766371
BM_Visit<1, 6>         1.70 ns         1.68 ns    446639358
BM_Visit<1, 7>         1.64 ns         1.64 ns    400441630
BM_Visit<1, 8>         1.56 ns         1.56 ns    430729471
BM_Visit<1, 9>         1.58 ns         1.58 ns    449894596
BM_Visit<1, 10>        1.54 ns         1.54 ns    449660506
BM_Visit<1, 20>        1.56 ns         1.56 ns    450813074
BM_Visit<1, 30>        1.59 ns         1.59 ns    440032940
BM_Visit<1, 40>        1.59 ns         1.59 ns    443731656
BM_Visit<1, 50>        1.56 ns         1.56 ns    444709859
BM_Visit<1, 60>        1.59 ns         1.58 ns    439527320
BM_Visit<1, 70>        1.57 ns         1.57 ns    438450890
BM_Visit<1, 80>        1.58 ns         1.58 ns    443001525
BM_Visit<1, 90>        1.63 ns         1.62 ns    448456349
BM_Visit<1, 100>       1.57 ns         1.57 ns    445740630

$ ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
2020-08-09 23:59:35
Running ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 1.40, 1.94, 2.22
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<2, 1>       0.261 ns        0.260 ns   1000000000
BM_Visit<2, 2>        1.55 ns         1.54 ns    432844219
BM_Visit<2, 3>        1.30 ns         1.30 ns    532529974
BM_Visit<2, 4>        1.54 ns         1.54 ns    446055910
BM_Visit<2, 5>        1.31 ns         1.31 ns    531099680
BM_Visit<2, 6>        1.56 ns         1.56 ns    443203475
BM_Visit<2, 7>        1.29 ns         1.29 ns    526478087
BM_Visit<2, 8>        1.56 ns         1.56 ns    439000834
BM_Visit<2, 9>        1.30 ns         1.30 ns    528756817
BM_Visit<2, 10>       1.56 ns         1.55 ns    442923039
BM_Visit<2, 20>       1.35 ns         1.35 ns    517021072
BM_Visit<2, 30>       1.60 ns         1.59 ns    419724661
BM_Visit<2, 40>       1.45 ns         1.44 ns    472137163
BM_Visit<2, 50>       1.65 ns         1.65 ns    421389743

$ ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
2020-08-10 00:01:32
Running ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.20, 2.01, 2.21
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<3, 1>       0.272 ns        0.271 ns   1000000000
BM_Visit<3, 2>        1.87 ns         1.86 ns    361858090
BM_Visit<3, 3>        1.77 ns         1.77 ns    391192579
BM_Visit<3, 4>        1.84 ns         1.84 ns    374694223
BM_Visit<3, 5>        1.75 ns         1.75 ns    408270392
BM_Visit<3, 6>        1.88 ns         1.88 ns    378759185
BM_Visit<3, 7>        1.79 ns         1.79 ns    395498102
BM_Visit<3, 8>        1.85 ns         1.85 ns    371660366
BM_Visit<3, 9>        1.80 ns         1.80 ns    386872851
BM_Visit<3, 10>       1.84 ns         1.84 ns    362367606
BM_Visit<3, 15>       1.77 ns         1.77 ns    392060220
BM_Visit<3, 20>       1.85 ns         1.85 ns    379157188
```

```
$ ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
2020-08-10 00:05:57
Running ./projects/libcxx/benchmarks/variant_visit_1.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.27, 2.36, 2.34
------------------------------------------------------------
Benchmark                 Time             CPU   Iterations
------------------------------------------------------------
BM_Visit<1, 1>        0.271 ns        0.271 ns   1000000000
BM_Visit<1, 2>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 3>        0.271 ns        0.271 ns   1000000000
BM_Visit<1, 4>        0.270 ns        0.270 ns   1000000000
BM_Visit<1, 5>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 6>        0.270 ns        0.269 ns   1000000000
BM_Visit<1, 7>        0.265 ns        0.265 ns   1000000000
BM_Visit<1, 8>        0.269 ns        0.269 ns   1000000000
BM_Visit<1, 9>        0.268 ns        0.268 ns   1000000000
BM_Visit<1, 10>       0.269 ns        0.269 ns   1000000000
BM_Visit<1, 20>       0.267 ns        0.267 ns   1000000000
BM_Visit<1, 30>       0.272 ns        0.272 ns   1000000000
BM_Visit<1, 40>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 50>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 60>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 70>       0.269 ns        0.269 ns   1000000000
BM_Visit<1, 80>       0.266 ns        0.266 ns   1000000000
BM_Visit<1, 90>       0.268 ns        0.268 ns   1000000000
BM_Visit<1, 100>      0.267 ns        0.267 ns   1000000000

$ ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
2020-08-12 04:09:59
Running ./projects/libcxx/benchmarks/variant_visit_2.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 2.17, 4.20, 4.78
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<2, 1>       0.302 ns        0.301 ns   1000000000
BM_Visit<2, 2>       0.297 ns        0.295 ns   1000000000
BM_Visit<2, 3>       0.353 ns        0.351 ns   1000000000
BM_Visit<2, 4>       0.276 ns        0.276 ns   1000000000
BM_Visit<2, 5>       0.285 ns        0.283 ns   1000000000
BM_Visit<2, 6>       0.290 ns        0.287 ns   1000000000
BM_Visit<2, 7>       0.282 ns        0.280 ns   1000000000
BM_Visit<2, 8>       0.290 ns        0.287 ns   1000000000
BM_Visit<2, 9>       0.291 ns        0.285 ns   1000000000
BM_Visit<2, 10>      0.293 ns        0.287 ns   1000000000
BM_Visit<2, 20>       1.70 ns         1.68 ns    391400375
BM_Visit<2, 30>       1.64 ns         1.63 ns    418925874
BM_Visit<2, 40>       1.63 ns         1.62 ns    423623677
BM_Visit<2, 50>       1.68 ns         1.67 ns    411687212

$ ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
2020-08-12 04:10:43
Running ./projects/libcxx/benchmarks/variant_visit_3.libcxx.out
Run on (8 X 3100 MHz CPU s)
CPU Caches:
  L1 Data 32K (x4)
  L1 Instruction 32K (x4)
  L2 Unified 262K (x4)
  L3 Unified 8388K (x1)
Load Average: 1.57, 3.76, 4.59
-----------------------------------------------------------
Benchmark                Time             CPU   Iterations
-----------------------------------------------------------
BM_Visit<3, 1>       0.271 ns        0.270 ns   1000000000
BM_Visit<3, 2>       0.344 ns        0.334 ns   1000000000
BM_Visit<3, 3>       0.347 ns        0.336 ns   1000000000
BM_Visit<3, 4>       0.300 ns        0.296 ns   1000000000
BM_Visit<3, 5>       0.290 ns        0.286 ns   1000000000
BM_Visit<3, 6>       0.272 ns        0.271 ns   1000000000
BM_Visit<3, 7>        1.72 ns         1.71 ns    415765841
BM_Visit<3, 8>        1.73 ns         1.72 ns    408909555
BM_Visit<3, 9>        2.16 ns         2.04 ns    380898485
BM_Visit<3, 10>       2.45 ns         2.40 ns    295714256
BM_Visit<3, 15>       1.92 ns         1.85 ns    375990332
BM_Visit<3, 20>       1.66 ns         1.65 ns    414456233
```

Differential Revision: https://reviews.llvm.org/D85420
2020-08-14 12:54:58 -07:00
Louis Dionne 9798b2311f [libc++] Make sure we only consider _GNUC_VER_NEW when the compiler is GCC
When the compiler is Clang, _GNUC_VER_NEW is 0, which messes up the logic.
2020-07-22 16:08:19 -04:00
Louis Dionne e9748a7255 [libc++] Workaround broken support for C++17 in GCC 5 2020-07-22 15:38:58 -04:00
Michael Park 6ab3208d77
Remove the unnecessary `is_nothrow_swappable` condition in `swap`.
Thanks to @lewissbaker who pointed out the unnecessary condition in
https://reviews.llvm.org/D81954#inline-756872. Since this codepath does not
make use of `swap` anyway (that codepath is a different branch), we can safely
remove this condition and produce better codegen when all types are nothrow
movable but are potentially-throwing swappable.

See codegen in https://gcc.godbolt.org/z/uDFZjz

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D83274
2020-07-08 10:46:38 -07:00
Michael Park 8fbd6d99a0
[libcxx/variant] Fix build error for when exceptions disabled.
Reviewers: #libc!

Subscribers: libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D81973
2020-06-18 07:21:42 -07:00
Michael Park ada2a8ea4a
Remove the try/catch codepath if `swap` is `noexcept`.
Summary:
In the case where `swap` is `noexcept`, we should avoid the extension to provide strong-exception guarantee.

Fixes https://bugs.llvm.org/show_bug.cgi?id=46342

Reviewers: #libc, ldionne

Reviewed By: #libc, ldionne

Subscribers: dexonsmith, mclow.lists, miscco, ldionne, zoecarver, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D81954
2020-06-16 14:51:22 -07:00
Eric Fiselier 4066978cb7 Improve compile time of variant.
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.

Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.

llvm-svn: 366033
2019-07-14 21:29:39 +00:00
Eric Fiselier aae0cb67ed Cleanup whitespace in <variant>. NFC.
llvm-svn: 366026
2019-07-14 18:31:55 +00:00
Eric Fiselier 194b337f33 Avoid eager template instantiation caused by the variant narrowing checks.
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.

However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.

In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.

llvm-svn: 366022
2019-07-14 18:21:15 +00:00
Eric Fiselier 128af31595 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
2019-07-12 21:32:11 +00:00
Zhihao Yuan 4513f0f022 [libc++] Recommit r363692 to implement P0608R3
Re-apply the change which was reverted in r363764 as-is after
breakages being resolved.  Thanks Eric Fiselier for working
hard on this.

See also: https://bugs.llvm.org/show_bug.cgi?id=42330

Differential Revision: https://reviews.llvm.org/D44865

llvm-svn: 363993
2019-06-20 22:09:40 +00:00
Zhihao Yuan 3f0ae625eb [libc++] Revert r363692 which implements P0608R3
The change caused a large number of compiler failures in
Google's codebase.  People need time to evaluate the impact.

llvm-svn: 363764
2019-06-19 07:11:08 +00:00
Zhihao Yuan c74fc6d5f9 [libc++] Implement P0608R3 - A sane variant converting constructor
Summary:
Prefer user-defined conversions over narrowing conversions and conversions to bool.

References:
 http://wg21.link/p0608

Reviewers: EricWF, mpark, mclow.lists

Reviewed By: mclow.lists

Subscribers: zoecarver, ldionne, libcxx-commits, cfe-commits, christof

Differential Revision: https://reviews.llvm.org/D44865

llvm-svn: 363692
2019-06-18 15:26:50 +00:00
Chandler Carruth 57b08b0944 Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648
2019-01-19 10:56:40 +00:00
Louis Dionne 1d5f6a81f5 [libcxx] Reorganize tests since the application of P0602R4
Summary:
P0602R4 makes the special member functions of optional and variant
conditionally trivial based on the types in the optional/variant.
We already implemented that, but the tests were organized as if this
were a non-standard extension. This patch reorganizes the tests in a
way that makes more sense since this is not an extension anymore.

Reviewers: EricWF, mpark, mclow.lists

Subscribers: christof, jkorous, dexonsmith, libcxx-commits

Differential Revision: https://reviews.llvm.org/D54772

llvm-svn: 350884
2019-01-10 20:06:11 +00:00
Louis Dionne 5517aa6172 [NFC] Fix typo in comment
llvm-svn: 349932
2018-12-21 17:32:23 +00:00
Louis Dionne 8a063df194 [libcxx] Add availability markup for bad_optional_access, bad_variant_access and bad_any_cast
Reviewers: dexonsmith, EricWF

Subscribers: christof, arphaman, libcxx-commits

Differential Revision: https://reviews.llvm.org/D53256

llvm-svn: 347219
2018-11-19 15:37:04 +00:00
Eric Fiselier 7dca3127c2 Don't require relops on variant alternatives to all return the same
type.

Libc++ correctly asserts that a set of visitors for a variant all
return the same type. However, we use the visitation machinary to
perform relational operations. This causes a static assertion when
some of the alternatives relops return a UDT which is implicitly
convertible to bool instead of 'bool' exactly.

llvm-svn: 342560
2018-09-19 17:53:21 +00:00
Marshall Clow f56972e224 Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955
llvm-svn: 342073
2018-09-12 19:41:40 +00:00
Richard Smith 67c364dd9b Fix ODR violation: namespace-scope helpers should not be declared 'static'.
llvm-svn: 340778
2018-08-27 21:41:50 +00:00
Eric Fiselier cd5e6a35bf Partially Revert "Workaround GCC bug PR78489 - SFINAE order is not respected."
This partially reverts commit r328261. The GCC bug has been fixed in
trunk and has never existed in a released version. Therefore the changes
to variant are unneeded.

However, the additional tests have been left in place.

llvm-svn: 328388
2018-03-23 23:42:30 +00:00
Eric Fiselier a595456731 Workaround GCC bug PR78489 - SFINAE order is not respected.
This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.

See gcc.gnu.org/PR78489

llvm-svn: 328261
2018-03-22 22:32:55 +00:00