summaryrefslogtreecommitdiffstats
path: root/libcxx/test/std/utilities/variant/variant.variant/variant.assign/conv.fail.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add option to disable variant narrowing conversion changes.Eric Fiselier2019-07-121-52/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [libc++] Recommit r363692 to implement P0608R3Zhihao Yuan2019-06-201-0/+52
| | | | | | | | | | | | 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
* [libc++] Revert r363692 which implements P0608R3Zhihao Yuan2019-06-191-52/+0
| | | | | | | The change caused a large number of compiler failures in Google's codebase. People need time to evaluate the impact. llvm-svn: 363764
* [libc++] Implement P0608R3 - A sane variant converting constructorZhihao Yuan2019-06-181-0/+52
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
OpenPOWER on IntegriCloud