This doesn't affect our ABI because `std::string::substr()` isn't in the dylib and the mangling of `substr() const` and `substr() const&` are different.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, #libc
Spies: arphaman, huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D131668
This patch switches the build compiler for AIX from ibm-clang to clang. ibm-clang++_r has `-pthread` by default, but clang for AIX doesn't, so `-pthread` had to be added to the test config. A bunch of tests now pass, so the `XFAIL` was removed. This patch also switch the build to use the visibility support available in clang-15 to control symbols exported by the shared library (AIX traditionally uses explicit export lists for this purpose).
Reviewed By: #libc, #libc_abi, daltenty, #libunwind, ldionne
Differential Revision: https://reviews.llvm.org/D127470
Instead of using `.fail.cpp` tests, use `.verify.cpp` to check for the
exact reason of the failure. In the case of deduction guides, use SFINAE
based tests instead since that is our preferred way of testing those.
Finally, ensure that we actually run the test in `iter_alloc_deduction.pass.cpp`,
since we were not running anything before.
Differential Revision: https://reviews.llvm.org/D123055
These are the last™ changes to the tests for constexpr preparation.
Reviewed By: Quuxplusone, #libc, Mordante
Spies: Mordante, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D120951
Make test_allocator etc. constexpr-friendly so they can be used to test constexpr string and possibly constexpr vector
Reviewed By: Quuxplusone, #libc, ldionne
Differential Revision: https://reviews.llvm.org/D110994
Add deduction guides to `valarray` and `scoped_allocator_adaptor`. This largely
finishes implementation of the paper:
* deduction guides for other classes mentioned in the paper were
implemented previously (see the list below);
* deduction guides for several classes contained in the proposal
(`reference_wrapper`, `lock_guard`, `scoped_lock`, `unique_lock`,
`shared_lock`) were removed by [LWG2981](https://wg21.link/LWG2981).
Also add deduction guides to the synopsis for the few classes (e.g. `pair`)
where they were missing.
The only part of the paper that isn't fully implemented after this patch is
making sure certain deduction guides don't participate in overload resolution
when given incorrect template parameters.
List of significant commits implementing the other parts of P0433 (omitting some
minor fixes):
* [pair](af65856eec)
* [basic_string](6d9f750dec)
* [array](0ca8c0895c)
* [deque](dbb6f8a817)
* [forward_list](e076700b77)
* [list](4a227e582b)
* [vector](df8f754792)
* [queue/stack/priority_queue](5b8b8b5dce)
* [basic_regex](edd5e29cfe)
* [optional](f35b4bc395)
* [map/multimap](edfe8525de)
* [set/multiset](e20865c387)
* [unordered_set/unordered_multiset](296a80102a)
* [unordered_map/unordered_multimap](dfcd4384cb)
* [function](e1eabcdfad)
* [tuple](1308011e1b)
* [shared_ptr/weak_ptr](83564056d4)
Additional notes:
* It was revision 2 of the paper that was voted into the Standard.
P0433R3 is a separate paper that is not part of the Standard.
* The paper also mandates removing several `make_*_searcher` functions
(e.g. `make_boyer_moore_searcher`) which are currently not implemented
(except in `experimental/`).
* The `__cpp_lib_deduction_guides` feature test macro from the paper was
accidentally omitted from the Standard.
Differential Revision: https://reviews.llvm.org/D112510
Some embedded platforms do not wish to support the C library functionality
for handling wchar_t because they have no use for it. It makes sense for
libc++ to work properly on those platforms, so this commit adds a carve-out
of functionality for wchar_t.
Unfortunately, unlike some other carve-outs (e.g. random device), this
patch touches several parts of the library. However, despite the wide
impact of this patch, I still think it is important to support this
configuration since it makes it much simpler to port libc++ to some
embedded platforms.
Differential Revision: https://reviews.llvm.org/D111265
All supported compilers have supported deduction guides in C++17 for a
while, so this isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D108213
Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.
This is the first patch of a series that will remove annotations for
compilers that are now unsupported.
Differential Revision: https://reviews.llvm.org/D107787
C++20 revised the definition of what it means to be an iterator. While
all _Cpp17InputIterators_ satisfy `std::input_iterator`, the reverse
isn't true. D100271 introduces a new test adaptor to accommodate this
new definition (`cpp20_input_iterator`).
In order to help readers immediately distinguish which input iterator
adaptor is _Cpp17InputIterator_, the current `input_iterator` adaptor
has been prefixed with `cpp17_`.
Differential Revision: https://reviews.llvm.org/D101242
This should make the builder http://lab.llvm.org:8011/#/builders/101/ happy.
It uses gcc-9 and not Tip-Of-Trunk as its name indicates BTW.
GCC-10 passes all these tests.
Fix gcc warnings: -Wsign-compare, -Wparentheses, -Wpragmas.
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D92099
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
By renaming .fail.cpp tests that don't need clang-verify to .compile.fail.cpp,
the new test format will not try to compile these tests with clang-verify,
and the old test format will work just the same. However, this allows
removing a workaround that requires parsing each test looking for
clang-verify markup.
After this change, a .fail.cpp test should always have clang-verify markup.
When clang-verify is not supported by the compiler, we will just check that
these tests fail to compile. When clang-verify is supported, these tests
will be compiled with clang-verify whether they have markup or not (so
they should have markup, or they will fail).
This simplifies the test suite and also ensures that all of our .fail.cpp
tests provide clang-verify markup. If it's impossible for a test to have
clang-verify markup, it can be moved to a .compile.fail.cpp test, which
are unconditionally just checked for compilation failure.
The libc++ test suite has a lot of old Lit features used to XFAIL tests
and mark them as UNSUPPORTED. Many of them are to workaround problems on
old compilers or old platforms. As time goes by, it is good to go and
clean those up to simplify the configuration of the test suite, and also
to reflect the testing reality. It's not useful to have markup that gives
the impression that e.g. clang-3.3 is supported, when we don't really
test on it anymore (and hence several new tests probably don't have the
necessary markup on them).
Fixed the inability to properly rebind the testing allocator, by making the
inner alloc_impl type a plain struct and making the operations templates. Before
rebind failed to compile complaining that a alloc_impl<T>* was not convertible
to an alloc_impl<U>*.
This enables the test to pass for MSVC++ once we provide the strong guarantee
for the copy assignment operator.
Reviewed as https://reviews.llvm.org/D60023
llvm-svn: 357545
Those tests fail when linking against a new dylib but running against
macosx10.7. I believe this is caused by a duplicate definition of the
RTTI for exception classes in libc++.dylib and libc++abi.dylib, but
this matter still needs some investigation.
This issue was not caught previously because all the tests always linked
against the same dylib used for running (because LIT made it impossible
to do otherwise before r349171).
rdar://problem/46809586
llvm-svn: 354940
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
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
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: 351648
After two failed attempts last week to make this work I am
going back to a known good method of making this test pass on
macOS...adding the current apple-clang version to the
UNSUPPORTED list.
During a previous patch review (https://reviews.llvm.org/D44103)
it was suggested to just XFAIL libcpp-no-deduction-guides
as was done to iter_alloc_deduction.pass.cpp. However
this caused a an unexpected pass on:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std/builds/214
I then attempted to just mark libcpp-no-deduction-guides
as UNSUPPORTED, however this caused an additional bot
failure. So I reverted everything (https://reviews.llvm.org/rCXX327191).
To solve this and get work unblocked I am adding
apple-clang-9 to the original UNSUPPORTED list.
llvm-svn: 327304
Summary: Refactor the previous version method of marking each apple-clang version as UNSUPPORTED and just XFAIL'ing the libcpp-no-deduction-guides instead. This brings this test inline with the same style as iter_alloc_deduction.pass.cpp
Reviewers: EricWF, dexonsmith
Reviewed By: EricWF
Subscribers: EricWF, vsapsai, vsk, cfe-commits
Differential Revision: https://reviews.llvm.org/D44103
llvm-svn: 327178
In T_size_size.pass, there is an explicit template argument to std::min to ask
for unsigned, to avoid type deduction errors. However, C1XX' warnings still
hate this use, because a 64 bit value (a size_t) is being passed to a function
accepting an unsigned (a 32 bit value).
Instead, change the tests to pass around std::size_t instances, and explicitly
narrow when constructing the string type under test. This also allows
removal of explicit template arguments to std::min.
llvm-svn: 302473
Louis Dionne