aboutsummaryrefslogtreecommitdiff
path: root/llvm/unittests/ADT/OptionalTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-12-20[ADT] Alias llvm::Optional to std::optionalBenjamin Kramer1-803/+0
This avoids the continuous API churn when upgrading things to use std::optional and makes trivial string replace upgrades possible. I tested this with GCC 7.5, the oldest supported GCC I had around. Differential Revision: https://reviews.llvm.org/D140332
2022-12-17Optional: Avoid value() usesFangrui Song1-2/+2
prerequisite to deprecate the new API value() whose counterpart in std::optional has undesired exception checking semantics and is unavailable in older Xcode.
2022-12-15[ADT] Remove llvm::Optional::transformKazu Hirata1-34/+0
I've removed the last uses of transform on Dec 14, 2022 in commit 230df792e17519071a9ef4dc0fb10132540dfbb8. Differential Revision: https://reviews.llvm.org/D140082
2022-12-11[ADT] Move MoveOnly to a header file (NFC)Kazu Hirata1-30/+1
This patch moves MoveOnly to a header file so that I can use it from another .cpp file. Differential Revision: https://reviews.llvm.org/D139781
2022-12-08[ADT] Use std::nullopt instead of llvm::None in OptionalTest.cppKazu Hirata1-7/+8
This patch updates the test for the streaming operator for llvm::Optional to use std::nullopt instead of llvm::None. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 Differential Revision: https://reviews.llvm.org/D139513
2022-12-02[llvm/unittests] Use std::nullopt instead of None (NFC)Kazu Hirata1-3/+3
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-11-08Reland "[llvm][NFC] Use c++17 style variable type traits"Nathan James1-9/+8
This reverts commit 632a389f96355cbe7ed8fa7b8d2ed6267c92457c. This relands commit 1834a310d060d55748ca38d4ae0482864c2047d8. Differential Revision: https://reviews.llvm.org/D137493
2022-11-08Revert "[llvm][NFC] Use c++17 style variable type traits"Nathan James1-8/+9
This reverts commit 1834a310d060d55748ca38d4ae0482864c2047d8.
2022-11-08[llvm][NFC] Use c++17 style variable type traitsNathan James1-9/+8
This was done as a test for D137302 and it makes sense to push these changes Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D137493
2022-10-26[ADT] Add deduction guide for llvm::OptionalDavid Blaikie1-0/+9
Added to address some uses of implicit CTAD added in clang recently.
2022-08-13[ADT] Implement Optional::transformKazu Hirata1-0/+34
This patch implements Optional::transform for consistency with std::optional::transform in C++23. Note that the new function is identical to Optional::map. My plan is to deprecate Optional::map after migrating all of its uses to Optional::transform. Differential Revision: https://reviews.llvm.org/D131829
2022-08-12[ADT] Replace STLForwardCompat.h's C++17 equivalentsJoe Loser1-7/+7
STLForwardCompat.h defines several utilities and type traits to mimic that of the ones in the C++17 standard library. Now that LLVM is built with the C++17 standards mode, remove use of these equivalents in favor of the ones from the standard library. Differential Revision: https://reviews.llvm.org/D131717
2022-07-25[ADT] Deprecate Optional::getValueOr (NFC)Kazu Hirata1-19/+0
This patch deprecates getValueOr in favor of value_or. Differential Revision: https://reviews.llvm.org/D130140
2022-07-13[llvm] Use value instead of getValue (NFC)Kazu Hirata1-1/+1
2022-07-12[llvm] Use has_value instead of hasValue (NFC)Kazu Hirata1-5/+5
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata1-6/+6
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata1-6/+6
2022-06-18[ADT] Add has_value, value, value_or to llvm::OptionalKazu Hirata1-0/+27
This patch adds has_value, value, value_or to llvm::Optional so that llvm::Optional looks more like std::optional. I will keep the existing functions while migrating their callers and then remove them later. Differential Revision: https://reviews.llvm.org/D128131
2022-02-02Remove redundant LLVM_HAS_RVALUE_REFERENCE_THIS and LLVM_LVALUE_FUNCTION definesSimon Pilgrim1-4/+0
Now that VS2017 support has been dropped (D114639), the LLVM_HAS_RVALUE_REFERENCE_THIS define is always true and the LLVM_LVALUE_FUNCTION define is always enabled for ref-qualifiers. This patch proposes we remove the defines and use the qualifiers directly. Differential Revision: https://reviews.llvm.org/D118609
2022-01-18[ADT] Fix Optional<> with llvm::is_trivially_move_constructibleSteven Wu1-0/+11
Fix the compatibility of Optional<> with some GCC versions that it will fail to compile when T is getting checked for `is_trivially_move_constructible` as mentioned here: https://reviews.llvm.org/D93510#2538983 Fix the problem by using `llvm::is_trivially_move_constructible`. Reviewed By: jplayer-nv, tatyana-krasnukha Differential Revision: https://reviews.llvm.org/D117254
2021-05-17[ADT] Factor out in_place_t and expose in Optional ctorScott Linder1-0/+50
Differential Revision: https://reviews.llvm.org/D100671
2021-05-14Bump googletest to 1.8.1Benjamin Kramer1-4/+5
We've accumulated a scary amount of local patches to this directory. I tried to merge them all, but if your favorite change is missing please reapply it manually (and send it upstream).
2021-01-16Fix llvm::Optional build breaks in MSVC using std::is_trivially_copyableJames Player1-0/+138
Current code breaks this version of MSVC due to a mismatch between `std::is_trivially_copyable` and `llvm::is_trivially_copyable` for `std::pair` instantiations. Hence I was attempting to use `std::is_trivially_copyable` to set `llvm::is_trivially_copyable<T>::value`. I spent some time root causing an `llvm::Optional` build error on MSVC 16.8.3 related to the change described above: ``` 62>C:\src\ocg_llvm\llvm-project\llvm\include\llvm/ADT/BreadthFirstIterator.h(96,12): error C2280: 'llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>>::operator =(const llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &)': attempting to reference a deleted function (compiling source file C:\src\ocg_llvm\llvm-project\llvm\unittests\ADT\BreadthFirstIteratorTest.cpp) ... ``` The "trivial" specialization of `optional_detail::OptionalStorage` assumes that the value type is trivially copy constructible and trivially copy assignable. The specialization is invoked based on a check of `is_trivially_copyable` alone, which does not imply both `is_trivially_copy_assignable` and `is_trivially_copy_constructible` are true. [[ https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable | According to the spec ]], a deleted assignment operator does not make `is_trivially_copyable` false. So I think all these properties need to be checked explicitly in order to specialize `OptionalStorage` to the "trivial" version: ``` /// Storage for any type. template <typename T, bool = std::is_trivially_copy_constructible<T>::value && std::is_trivially_copy_assignable<T>::value> class OptionalStorage { ``` Above fixed my build break in MSVC, but I think we need to explicitly check `is_trivially_copy_constructible` too since it might be possible the copy constructor is deleted. Also would be ideal to move over to `std::is_trivially_copyable` instead of the `llvm` namespace verson. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D93510
2021-01-14Revert "Fix llvm::Optional build breaks in MSVC using ↵Alexandre Ganea1-121/+0
std::is_trivially_copyable" This reverts commit 854f0984f0b7ab9a9a541a4bcda7ea173e4113d3. This breaks compilation with clang-cl on Windows, while in a MSVC 16.8 cmd.exe. This also breaks PPC: http://lab.llvm.org:8011/#/builders/93/builds/1435 And: https://reviews.llvm.org/D93510#2497737
2021-01-13Fix llvm::Optional build breaks in MSVC using std::is_trivially_copyableJames Player1-0/+121
Current code breaks this version of MSVC due to a mismatch between `std::is_trivially_copyable` and `llvm::is_trivially_copyable` for `std::pair` instantiations. Hence I was attempting to use `std::is_trivially_copyable` to set `llvm::is_trivially_copyable<T>::value`. I spent some time root causing an `llvm::Optional` build error on MSVC 16.8.3 related to the change described above: ``` 62>C:\src\ocg_llvm\llvm-project\llvm\include\llvm/ADT/BreadthFirstIterator.h(96,12): error C2280: 'llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>>::operator =(const llvm::Optional<std::pair<std::pair<unsigned int,llvm::Graph<4>::NodeSubset> *,llvm::Optional<llvm::Graph<4>::ChildIterator>>> &)': attempting to reference a deleted function (compiling source file C:\src\ocg_llvm\llvm-project\llvm\unittests\ADT\BreadthFirstIteratorTest.cpp) ... ``` The "trivial" specialization of `optional_detail::OptionalStorage` assumes that the value type is trivially copy constructible and trivially copy assignable. The specialization is invoked based on a check of `is_trivially_copyable` alone, which does not imply both `is_trivially_copy_assignable` and `is_trivially_copy_constructible` are true. [[ https://en.cppreference.com/w/cpp/named_req/TriviallyCopyable | According to the spec ]], a deleted assignment operator does not make `is_trivially_copyable` false. So I think all these properties need to be checked explicitly in order to specialize `OptionalStorage` to the "trivial" version: ``` /// Storage for any type. template <typename T, bool = std::is_trivially_copy_constructible<T>::value && std::is_trivially_copy_assignable<T>::value> class OptionalStorage { ``` Above fixed my build break in MSVC, but I think we need to explicitly check `is_trivially_copy_constructible` too since it might be possible the copy constructor is deleted. Also would be ideal to move over to `std::is_trivially_copyable` instead of the `llvm` namespace verson. Reviewed By: dblaikie Differential Revision: https://reviews.llvm.org/D93510
2020-12-08ADT: Add hash_value overload for OptionalDuncan P. N. Exon Smith1-0/+17
Add a `hash_value` for Optional so that other data structures with optional fields can easily hash them. I have a use for this in an upcoming patch. Differential Revision: https://reviews.llvm.org/D92676
2020-12-08ADT: Remove the unused explicit `OptionalTest` fixture, NFCDuncan P. N. Exon Smith1-31/+27
`OptionalTest` was empty; drop it and switch all the tests to use the shorter `TEST` instead of `TEST_F`. Differential Revision: https://reviews.llvm.org/D92675
2020-12-02Switch from llvm::is_trivially_copyable to std::is_trivially_copyableFangrui Song1-10/+9
GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1 we can migrate to std::is_trivially_copyable. The Optional.h change made MSVC choke (https://buildkite.com/llvm-project/premerge-checks/builds/18587#cd1bb616-ffdc-4581-9795-b42c284196de) so I leave it out for now. Differential Revision: https://reviews.llvm.org/D92514
2020-12-02Revert "Use std::is_trivially_copyable", breaks MSVC buildReid Kleckner1-9/+10
Revert "Delete llvm::is_trivially_copyable and CMake variable HAVE_STD_IS_TRIVIALLY_COPYABLE" This reverts commit 4d4bd40b578d77b8c5bc349ded405fb58c333c78. This reverts commit 557b00e0afb2dc1776f50948094ca8cc62d97be4.
2020-12-02Use std::is_trivially_copyableFangrui Song1-10/+9
GCC<5 did not support std::is_trivially_copyable. Now LLVM builds require 5.1 we can migrate to std::is_trivially_copyable.
2020-09-01[ADT] Make Optional a literal type.Varun Gandhi1-0/+13
This allows returning Optional values from constexpr contexts. Reviewed By: fhahn, dblaikie, rjmccall Differential Revision: https://reviews.llvm.org/D86354
2020-01-22Revert "Unconditionally enable lvalue function designators; NFC"Aaron Ballman1-0/+4
This reverts commit 968561bcdc34c7d74482fe3bb69a045abf08d2c1
2020-01-22Unconditionally enable lvalue function designators; NFCAaron Ballman1-4/+0
We previously had to guard against older MSVC and GCC versions which had rvalue references but not support for marking functions with ref qualifiers. However, having bumped our minimum required version to MSVC 2017 and GCC 5.1 mean we can unconditionally enable this feature. Rather than keeping the macro around, this replaces use of the macro with the actual ref qualifier.
2019-08-15Revert rL368939 "Remove LVALUE / RVALUE workarounds"Russell Gallop1-0/+4
This reverts commit cad8356d699b36c73abb267f65db575ddacbd652. To unbreak Windows bots llvm-svn: 368985
2019-08-14Remove LVALUE / RVALUE workaroundsJF Bastien1-4/+0
Summary: LLVM_HAS_RVALUE_REFERENCE_THIS and LLVM_LVALUE_FUNCTION shouldn't be needed anymore because the minimum compiler versions support them. Subscribers: jkorous, dexonsmith, cfe-commits, llvm-commits, hans, thakis, chandlerc, rnk Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D66240 llvm-svn: 368939
2019-02-18[NFC] Make Optional<T> trivially copyable when T is trivially copyableSerge Guelton1-0/+21
This is a follow-up to r354246 and a reimplementation of https://reviews.llvm.org/D57097?id=186600 that should not trigger any UB thanks to the use of an union. This may still be subject to the problem solved by std::launder, but I'm unsure how it interacts whith union. /me plans to revert if this triggers any relevant bot failure. At least this validates in Release mode with clang 6.0.1 and gcc 4.8.5. llvm-svn: 354264
2019-02-16Revert r354199: Make Optional<T> Trivially Copyable when T is trivially ↵Serge Guelton1-7/+0
copyable llvm-svn: 354200
2019-02-16Make Optional<T> Trivially Copyable when T is trivially copyableSerge Guelton1-0/+7
This is another attempt in the process, works nicely on my setup, let's check how it behaves on other targets. llvm-svn: 354199
2019-02-15Speculatively revert r354051 "Recommit Optional specialization for trivially ↵Hans Wennborg1-20/+0
copyable types" and r354055 "Optional specialization for trivially copyable types, part2" These are suspected to cause Clang to get miscompiled on Ubuntu 14.04 (Trusty) which uses GCC 4.8.4. Reverting for an hour to see if this helps. See llvm-commits thread. > Recommit Optional specialization for trivially copyable types > > Unfortunately the original code gets misscompiled by GCC (at least 8.1), > this is a tentative workaround using std::memcpy instead of inplace new > for trivially copyable types. I'll revert if it breaks. > > Original revision: https://reviews.llvm.org/D57097 llvm-svn: 354126
2019-02-14Recommit Optional specialization for trivially copyable typesSerge Guelton1-0/+20
Unfortunately the original code gets misscompiled by GCC (at least 8.1), this is a tentative workaround using std::memcpy instead of inplace new for trivially copyable types. I'll revert if it breaks. Original revision: https://reviews.llvm.org/D57097 llvm-svn: 354051
2019-02-13Revert r353962Serge Guelton1-20/+0
Specialization of Optional for trivially copyable types yields failure on the buildbots I fail to reproduce locally. Better safe than sorry, reverting. llvm-svn: 353982
2019-02-13Re-commit rL353927, patch includedSerge Guelton1-0/+20
Make llvm::Optional<T> trivially copyable when T is trivially copyable This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978) but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this. Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue, and using in-place new instead of memcpy should keep compiler bugs away. This patch is slightly different from the original revision https://reviews.llvm.org/rL353927 but achieves the same goal. It just avoids going through std::conditional which may the code more explicit. llvm-svn: 353962
2019-02-13Revert r353927Serge Guelton1-20/+0
llvm-svn: 353940
2019-02-13Missing headerSerge Guelton1-0/+2
llvm-svn: 353933
2019-02-13Make llvm::Optional<T> trivially copyable when T is trivially copyableSerge Guelton1-0/+20
This is an ever-recurring issue (see https://bugs.llvm.org/show_bug.cgi?id=39427 and https://bugs.llvm.org/show_bug.cgi?id=35978) but I believe that thanks to https://reviews.llvm.org/D54472 we can now ship a decent implementation of this. Basically the fact that llvm::is_trivially_copyable has a consistent behavior across compilers should prevent any ABI issue, and using in-place new instead of memcpy should keep compiler bugs away. Differential Revision: https://reviews.llvm.org/D57097 llvm-svn: 353927
2019-01-21Fix compilation error with gcc 4.8Pavel Labath1-4/+4
This version of gcc seems to be having issues with raw literals inside macro arguments. I change the string to use regular string literals instead. llvm-svn: 351756
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. 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: 351636
2019-01-18[ADT] Add streaming operators for llvm::OptionalPavel Labath1-1/+51
Summary: The operators simply print the underlying value or "None". The trickier part of this patch is making sure the streaming operators work even in unit tests (which was my primary motivation, though I can also see them being useful elsewhere). Since the stream operator was a template, implicit conversions did not kick in, and our gtest glue code was explicitly introducing an implicit conversion to make sure other implicit conversions do not kick in :P. I resolve that by specializing llvm_gtest::StreamSwitch for llvm:Optional<T>. Reviewers: sammccall, dblaikie Reviewed By: sammccall Subscribers: mgorny, dexonsmith, kristina, llvm-commits Differential Revision: https://reviews.llvm.org/D56795 llvm-svn: 351548
2018-11-16Re-apply r346985: [ADT] Drop llvm::Optional clang-specific optimization for ↵Tom Stellard1-8/+0
trivially copyable types Remove a test case that was added with the optimization we are now removing. llvm-svn: 347004
2018-01-25[ADT] Make moving Optional not reset the Optional it moves from.Benjamin Kramer1-6/+6
This brings it in line with std::optional. My recent changes to make Optional of trivial types trivially copyable introduced diverging behavior depending on the type, which is bad. Now all types have the same moving behavior. llvm-svn: 323445
generated by cgit v1.1 at 2025-10-19 03:27:52 +0000