| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++] Clean up pair's constructors and assignment operators This patch makes std::pair's constructors and assignment operators closer to conforming in C++23. The only missing bit I am aware of now is reference_constructs_from_temporary_v checks, which we don't have the tools for yet. This patch also refactors a long-standing non-standard extension where we'd provide constructors for tuple-like types in all standard modes. The criteria for being a tuple-like type are different from pair-like types as introduced recently in the standard, leading to a lot of complexity when trying to implement recent papers that touch the pair constructors. After this patch, the pre-C++23 extension is provided in a self-contained block so that we can easily deprecate and eventually remove the extension in future releases. Differential Revision: https://reviews.llvm.org/D143914 | 3 年前 | |
[runtimes][NFC] Remove old Lit annotations for gcc-12 and clang-14 We don't support these compilers anymore so these Lit annotations were never used. | 2 年前 | |
[libc++][NFC] Fix incorrect main signatures in tests | 3 年前 | |
[libc++][NFC] Fix incorrect main signatures in tests | 3 年前 | |
[libc++][NFC] Fix incorrect main signatures in tests | 3 年前 | |
[libc++][NFC] Fix incorrect main signatures in tests | 3 年前 | |
[libc++] Provide an assignment operator from pair<U, V> in C++03 This adds an extension to std::pair in C++03 mode where we provide an assignment operator from a pair<U, V>. Previously, any code trying to trigger such an assignment operator would have tried using the operator=(pair const&) copy assignment operator, which would then have tried creating a pair const& by using the unconstrained pair<U, V> constructor. After this patch, pair will instead go through operator= directly if its member types are assignable. If they are not assignable, the extension operator= is disabled with SFINAE and the pair(pair<U, V>) constructor will be used. Since that constructor is unconstrained, that will either work or give a hard error. This should be pretty transparent to users, but this is technically a behavior change in C++03. Indeed, if a type has both a valid cross-type assignment operator *and* a valid cross-type constructor, the library will now prefer the cross-type assignment instead of going through the cross-type constructor and then using the copy-constructor. Since this is the mandated behavior in C++11, however, one could argue that any user broken by that needs to change their code. The motivation for this change is to allow simplifying the definition of std::map's value_type, which requires handling assignment to a pair of references properly. This patch will allow removing complexity from https://llvm.org/D121485 instead of adding complexity in that patch. Differential Revision: https://reviews.llvm.org/D150119 | 3 年前 | |
[libc++][nfc] SFINAE on pair/tuple assignment operators: LWG 2729. This patch ensures that SFINAE is used to delete assignment operators in pair and tuple based on issue 2729. Differential Review: https://reviews.llvm.org/D62454 | 5 年前 | |
[libc++] Provide an assignment operator from pair<U, V> in C++03 This adds an extension to std::pair in C++03 mode where we provide an assignment operator from a pair<U, V>. Previously, any code trying to trigger such an assignment operator would have tried using the operator=(pair const&) copy assignment operator, which would then have tried creating a pair const& by using the unconstrained pair<U, V> constructor. After this patch, pair will instead go through operator= directly if its member types are assignable. If they are not assignable, the extension operator= is disabled with SFINAE and the pair(pair<U, V>) constructor will be used. Since that constructor is unconstrained, that will either work or give a hard error. This should be pretty transparent to users, but this is technically a behavior change in C++03. Indeed, if a type has both a valid cross-type assignment operator *and* a valid cross-type constructor, the library will now prefer the cross-type assignment instead of going through the cross-type constructor and then using the copy-constructor. Since this is the mandated behavior in C++11, however, one could argue that any user broken by that needs to change their code. The motivation for this change is to allow simplifying the definition of std::map's value_type, which requires handling assignment to a pair of references properly. This patch will allow removing complexity from https://llvm.org/D121485 instead of adding complexity in that patch. Differential Revision: https://reviews.llvm.org/D150119 | 3 年前 | |
[libc++] Fix incorrect forwarding in tuple's assignment operator Also, add a bunch of tests for tuple and pair's assignment operators involving reference types. Differential Revision: https://reviews.llvm.org/D97419 | 5 年前 | |
[libc++][test] Cleanup typos and unnecessary semicolons (#73435) I've structured this into a series of commits for even easier reviewing, if that helps. I could easily split this up into separate PRs if desired, but as this is low-risk with simple edits, I thought one PR would be easiest. * Drop unnecessary semicolons after function definitions. * Cleanup comment typos. * Cleanup static_assert typos. * Cleanup test code typos. + There should be no functional changes, assuming I've changed all occurrences. * ~~Fix massive test code typos.~~ + This was a real problem, but needed more surgery. I reverted those changes here, and @philnik777 is fixing this properly with #73444. * clang-formatting as requested by the CI. | 2 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++] Do not enable P1951 before C++23, since it's a breaking change In reaction to the issues raised by Richard in https://llvm.org/D109066, this commit does not apply P1951 as a DR in previous standard modes, since it breaks valid code. I do believe it should be applied as a DR, however ideally we'd get some sort of statement from the Committee to this effect (and all implementations would behave consistently). In the meantime, only implement P1951 starting with C++23 -- we can always come back and apply it as a DR if that's what the Committee says. Differential Revision: https://reviews.llvm.org/D110347 | 4 年前 | |
[libc++] Implement P1951, default arguments for pair's forwarding constructor Differential Revision: https://reviews.llvm.org/D109066 | 4 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Move several .fail.cpp tests to .verify.cpp A few tests were also straightforward to translate to SFINAE tests instead, so in a few cases I did that and removed the .fail.cpp test entirely. Differential Revision: https://reviews.llvm.org/D153149 | 2 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libcxx][test][NFC] Fix std::pair convertible tests in light of CWG2137 (#97403) https://cplusplus.github.io/CWG/issues/2137.html This change was previously made as part of 924701311aa79180e86ad8ce43d253f27d25ec7d (#77768) and later reverted in 6e4930c67508a90bdfd756f6e45417b5253cd741 This change is still needed because the comment is still true: A standards-conformant compiler is currently supposed to fail this test. This also means that any future work on CWG2137 with Clang would not need to modify the libc++ test suite | 1 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[libc++] LWG 3821 uses_allocator_construction_args should have overload for pair-like (#66939) This change addresses LWG 3821 and LWG 3677. - make std::pair's constructor no longer takes subrange - uses_allocator_construction_args constraint changes w.r.t to pair-like types - uses_allocator_construction_args constraints checks is-pair-like<remove_cv_t<T>> | 2 年前 | |
[libc++][NFC] Reorganize the std::pair constructor tests to be more consistently named This makes it much easier to figure out what is and what isn't implemented. | 3 年前 | |
[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 | 5 年前 | |
[libc++][CI] Updates GCC to version 12. Reviewed By: ldionne, philnik, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D126667 | 3 年前 | |
[libc++][test] Close LWG3382 and add tests (#93039) | 2 年前 | |
[libc++] LWG3382: NTTP for pair and array (#85811) Mark LWG3382 as "Nothing To Do" and add tests. | 1 年前 | |
[libc++] LWG3382: NTTP for pair and array (#85811) Mark LWG3382 as "Nothing To Do" and add tests. | 1 年前 | |
[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 | 5 年前 | |
Add constexpr to pair Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D80558 | 5 年前 | |
[libc++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
Add include for 'test_macros.h' to all the tests that were missing them. Thanks to Zoe for the (big, but simple) patch. NFC intended. llvm-svn: 362252 | 6 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 6 年前 |