| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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. | 4 年前 | |
[libc++] Granularize <type_traits> includes in <iterator> Reviewed By: Mordante, #libc Spies: libcxx-commits Differential Revision: https://reviews.llvm.org/D140621 | 3 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] Upgrade to GCC 14 (#97205) | 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 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[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++][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++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 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++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
[libc++][test] Replace _LIBCPP_STD_VER with TEST_STD_VER Differential Revision: https://reviews.llvm.org/D130979 | 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++][test] Replace _LIBCPP_STD_VER with TEST_STD_VER Differential Revision: https://reviews.llvm.org/D130979 | 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++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[libc++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
[libc++] Fix QoI bug with construction of std::tuple involving std::any In std::tuple, we should try to avoid calling std::is_copy_constructible whenever we can to avoid surprising interactions with (I believe) compiler builtins. This bug was reported in https://reviews.llvm.org/D96523#2730953. The issue was that when tuple<_Up...> was the same as tuple<_Tp...>, we would short-circuit the _Or (because sizeof...(_Tp) != 1) and go evaluate the following is_constructible<_Tp, const _Up&>.... That shouldn't actually be a problem, but see the analysis in https://reviews.llvm.org/D101770#2736470 for why it is with Clang and GCC. Instead, after this patch, we check whether the constructed-from tuple is the same as the current tuple regardless of the number of elements, since we should always prefer the normal copy constructor in that case anyway. Differential Revision: https://reviews.llvm.org/D101770 | 5 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[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++] 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++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 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++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 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++][test] Add '-Wdeprecated-copy', '-Wdeprecated-copy-dtor' warnings to the test suite This is a follow up to https://reviews.llvm.org/D144694. Fixes https://github.com/llvm/llvm-project/issues/60977. Differential Revision: https://reviews.llvm.org/D144775 | 2 年前 | |
[libc++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 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++] 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++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 | |
[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++][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++][test] Add tuple trivial destructor test There is only compile-time tests in dtor.pass.cpp, so it could be made a dtor.compile.pass.cpp. Instead, add a runtime test for testing the trivial destructor behavior for tuple. Differential Revision: https://reviews.llvm.org/D109298 | 3 年前 | |
[libc++] Mark LWG3211 as complete: default constructor of tuple<> should be trivial libc++ has had the guarantee of the default constructor of tuple<> being trivial since 405570dc7a95cdf43cdee14b8a9f9c1657a6ad13. Now, the standard mandates it as of LWG3211. So, move the file out of libcxx/test/libcxx and into libcxx/test/std since it's no longer libc++-specific. Rename it to be .compile.pass.cpp instead of .pass.cpp while we're at it. Reviewed By: ldionne, Quuxplusone, Mordante, #libc Differential Revision: https://reviews.llvm.org/D112743 | 4 年前 | |
[libc++] Granularize the rest of memory Reviewed By: ldionne, #libc Spies: vitalybuka, paulkirth, libcxx-commits, mgorny Differential Revision: https://reviews.llvm.org/D132790 | 3 年前 | |
[libc++] Fix constexpr-ness of std::tuple's constructor Mentioned in https://reviews.llvm.org/D96523. | 5 年前 | |
[libc++] implement "pair" section of P2321R2 zip Differential Revision: https://reviews.llvm.org/D131495 | 3 年前 | |
[libc++] Use _Lazy in tuple constructors This reduces the number of instantiations and also avoid blowing up past the fold-expression limit of Clang. This is NOT a general statement that we should strive to stay within Clang's (sometimes way too small) limits, however in this case the change will reduce the number of template instantiations while at the same time doing that, which is good. Differential Revision: https://reviews.llvm.org/D132509 | 2 年前 | |
[libc++] Rewrite the tuple constructors to be strictly Standards conforming This nasty patch rewrites the tuple constructors to match those defined by the Standard. We were previously providing several extensions in those constructors - those extensions are removed by this patch. The issue with those extensions is that we've had numerous bugs filed against us over the years for problems essentially caused by them. As a result, people are unable to use tuple in ways that are blessed by the Standard, all that for the perceived benefit of providing them extensions that they never asked for. Since this is an API break, I communicated it in the release notes. I do not foresee major issues with this break because I don't think the extensions are too widely relied upon, but we can ship it and see if we get complaints before the next LLVM release - that will give us some amount of information regarding how much use these extensions have. Differential Revision: https://reviews.llvm.org/D96523 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 5 年前 |