| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[libc++][test] Fix assumptions that std::array iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where std::array iterators are never pointers. Most of these changes are reasonably self-explanatory (the std::arrays are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In libcxx/test/std/containers/from_range_helpers.h, wrap_input() is called with Iter types that are constructible from raw pointers. It's also sometimes called with an array as the input, so the first overload was implicitly assuming that array iterators are pointers. We can fix this assumption by providing a dedicated overload for array, just like the one for vector immediately below. Finally, from_range_helpers.h should explicitly include both <array> and <vector>, even though they were apparently being dragged in already. In libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp, fix throw_operator_minus. The error was pretty complicated, caused by the concepts machinery noticing that value_type and element_type were inconsistent. In the template instantiation context, you can see the critical detail that throw_operator_minus<std::_Array_iterator> is being formed. Fortunately, the fix is extremely simple. To produce element_type (which retains any cv-qualification, unlike value_type), we shouldn't attempt to remove_pointer with the iterator type It. Instead, we've already obtained the reference type, so we can remove_reference_t. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.) | 2 年前 | |
[libc++][test] Fix assumptions that std::array iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where std::array iterators are never pointers. Most of these changes are reasonably self-explanatory (the std::arrays are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In libcxx/test/std/containers/from_range_helpers.h, wrap_input() is called with Iter types that are constructible from raw pointers. It's also sometimes called with an array as the input, so the first overload was implicitly assuming that array iterators are pointers. We can fix this assumption by providing a dedicated overload for array, just like the one for vector immediately below. Finally, from_range_helpers.h should explicitly include both <array> and <vector>, even though they were apparently being dragged in already. In libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp, fix throw_operator_minus. The error was pretty complicated, caused by the concepts machinery noticing that value_type and element_type were inconsistent. In the template instantiation context, you can see the critical detail that throw_operator_minus<std::_Array_iterator> is being formed. Fortunately, the fix is extremely simple. To produce element_type (which retains any cv-qualification, unlike value_type), we shouldn't attempt to remove_pointer with the iterator type It. Instead, we've already obtained the reference type, so we can remove_reference_t. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.) | 2 年前 | |
[libc++][test] Fix assumptions that std::array iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where std::array iterators are never pointers. Most of these changes are reasonably self-explanatory (the std::arrays are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In libcxx/test/std/containers/from_range_helpers.h, wrap_input() is called with Iter types that are constructible from raw pointers. It's also sometimes called with an array as the input, so the first overload was implicitly assuming that array iterators are pointers. We can fix this assumption by providing a dedicated overload for array, just like the one for vector immediately below. Finally, from_range_helpers.h should explicitly include both <array> and <vector>, even though they were apparently being dragged in already. In libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp, fix throw_operator_minus. The error was pretty complicated, caused by the concepts machinery noticing that value_type and element_type were inconsistent. In the template instantiation context, you can see the critical detail that throw_operator_minus<std::_Array_iterator> is being formed. Fortunately, the fix is extremely simple. To produce element_type (which retains any cv-qualification, unlike value_type), we shouldn't attempt to remove_pointer with the iterator type It. Instead, we've already obtained the reference type, so we can remove_reference_t. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.) | 2 年前 | |
[libc++][test] Fix assumptions that std::array iterators are pointers (#74430) Found while running libc++'s tests with MSVC's STL, where std::array iterators are never pointers. Most of these changes are reasonably self-explanatory (the std::arrays are right there, and the sometimes-slightly-wrapped raw pointer types are a short distance away). A couple of changes are less obvious: In libcxx/test/std/containers/from_range_helpers.h, wrap_input() is called with Iter types that are constructible from raw pointers. It's also sometimes called with an array as the input, so the first overload was implicitly assuming that array iterators are pointers. We can fix this assumption by providing a dedicated overload for array, just like the one for vector immediately below. Finally, from_range_helpers.h should explicitly include both <array> and <vector>, even though they were apparently being dragged in already. In libcxx/test/std/containers/views/views.span/span.cons/iterator_sentinel.pass.cpp, fix throw_operator_minus. The error was pretty complicated, caused by the concepts machinery noticing that value_type and element_type were inconsistent. In the template instantiation context, you can see the critical detail that throw_operator_minus<std::_Array_iterator> is being formed. Fortunately, the fix is extremely simple. To produce element_type (which retains any cv-qualification, unlike value_type), we shouldn't attempt to remove_pointer with the iterator type It. Instead, we've already obtained the reference type, so we can remove_reference_t. (This is modern code, where we have access to the alias templates, so I saw no reason to use the older verbose form.) | 2 年前 | |
[libc++][test] Enhance ADDITIONAL_COMPILE_FLAGS, use TEST_MEOW_DIAGNOSTIC_IGNORED sparingly (#75317) This is the last PR that's needed (for now) to get libc++'s tests working with MSVC's STL. The ADDITIONAL_COMPILE_FLAGS machinery is very useful, but also very problematic for MSVC, as it doesn't understand most of Clang's compiler options. We've been dealing with this by simply marking anything that uses ADDITIONAL_COMPILE_FLAGS as FAIL or SKIPPED, but that creates significant gaps in test coverage. Fortunately, ADDITIONAL_COMPILE_FLAGS also supports "features", which can be slightly enhanced to send Clang-compatible and MSVC-compatible options to the right compilers. This patch adds the gcc-style-warnings and cl-style-warnings Lit features, and uses that to pass the appropriate warning flags to tests. It also uses TEST_MEOW_DIAGNOSTIC_IGNORED for a few local suppressions of MSVC warnings. | 2 年前 | |
[libc++] Make sure ranges algorithms and views handle boolean-testable correctly (#69378) Before this patch, we would fail to implicitly convert the result of predicates to bool, which means we'd potentially perform a copy or move construction of the boolean-testable, which isn't allowed. The same holds true for comparing iterators against sentinels, which is allowed to return a boolean-testable type. We already had tests aiming to ensure correct handling of these types, but they failed to provide appropriate coverage in several cases due to guaranteed RVO. This patch fixes the tests, adds tests for missing algorithms and views, and fixes the actual problems in the code. Fixes #69074 | 2 年前 | |
[libc++] Make <ranges> non-experimental When we ship LLVM 16, <ranges> won't be considered experimental anymore. We might as well do this sooner rather than later. Differential Revision: https://reviews.llvm.org/D132151 | 3 年前 | |
[libc++] Make <ranges> non-experimental When we ship LLVM 16, <ranges> won't be considered experimental anymore. We might as well do this sooner rather than later. Differential Revision: https://reviews.llvm.org/D132151 | 3 年前 | |
Support tests in freestanding Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding main isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its return statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the return we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare main as int main(int, char** so it mangles consistently (enabling us to declare another extern "C" main for freestanding which calls the mangled one), and adds return 0; to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with -x c, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086 | 7 年前 | |
[libc++][NFC] Use cpp17_output_iterator in tests. The renames the output_iterator to cpp17_output_iterator. These iterators are still used in C++20 so it's not possible to change the current type to the new C++20 requirements. This is done in a similar fashion as the cpp17_input_iterator. Reviewed By: #libc, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D117950 | 4 年前 | |
[libc++][NFC] Use cpp17_output_iterator in tests. The renames the output_iterator to cpp17_output_iterator. These iterators are still used in C++20 so it's not possible to change the current type to the new C++20 requirements. This is done in a similar fashion as the cpp17_input_iterator. Reviewed By: #libc, Quuxplusone, ldionne Differential Revision: https://reviews.llvm.org/D117950 | 4 年前 | |
Support tests in freestanding Summary: Freestanding is *weird*. The standard allows it to differ in a bunch of odd manners from regular C++, and the committee would like to improve that situation. I'd like to make libc++ behave better with what freestanding should be, so that it can be a tool we use in improving the standard. To do that we need to try stuff out, both with "freestanding the language mode" and "freestanding the library subset". Let's start with the super basic: run the libc++ tests in freestanding, using clang as the compiler, and see what works. The easiest hack to do this: In utils/libcxx/test/config.py add: self.cxx.compile_flags += ['-ffreestanding'] Run the tests and they all fail. Why? Because in freestanding main isn't special. This "not special" property has two effects: main doesn't get mangled, and main isn't allowed to omit its return statement. The first means main gets mangled and the linker can't create a valid executable for us to test. The second means we spew out warnings (ew) and the compiler doesn't insert the return we omitted, and main just falls of the end and does whatever undefined behavior (if you're luck, ud2 leading to non-zero return code). Let's start my work with the basics. This patch changes all libc++ tests to declare main as int main(int, char** so it mangles consistently (enabling us to declare another extern "C" main for freestanding which calls the mangled one), and adds return 0; to all places where it was missing. This touches 6124 files, and I apologize. The former was done with The Magic Of Sed. The later was done with a (not quite correct but decent) clang tool: https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed This works for most tests, though I did have to adjust a few places when e.g. the test runs with -x c, macros are used for main (such as for the filesystem tests), etc. Once this is in we can create a freestanding bot which will prevent further regressions. After that, we can start the real work of supporting C++ freestanding fairly well in libc++. <rdar://problem/47754795> Reviewers: ldionne, mclow.lists, EricWF Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits Differential Revision: https://reviews.llvm.org/D57624 llvm-svn: 353086 | 7 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 年前 |