This patch adds the working parts of r243503. The difference with this patch
is that it doesn't include the HandleLLVMOptions.cmake file.
llvm-svn: 243698
This change was reverted in r243550 because it broke clang-format builds
(see PR24306).
This patch recommits a fixed version of the original.
llvm-svn: 243574
Summary:
This patch contains the following changes:
1. Require that libc++ can find a LLVM source directory. This is done the same way as `libc++abi` currently does.
2. Cleanup ugly configuration code in CMakeLists.txt by using `add_flags`, `add_flags_if`, and `add_flags_if_supported` macros.
The goals for this patch are:
1. Help libc++ be more consistent with how LLVM handles CMake options (see PR23670 PR23671).
2. Make it easier to use sanitizers using the `LLVM_USE_SANITIZER` option.
3. Make libc++'s CMakeLists.txt file easier to understand and change.
4. Move towards allowing libc++ to create Sphinx documentation (see http://efcs.ca/libcxx-docs).
5. Move towards allowing libc++ to use other LLVM utilities such as `not` and `FileCheck`.
Reviewers: mclow.lists, jroelofs, danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11308
llvm-svn: 243503
This patch fixes LWG issue 2422 by removing the DECAY_COPY from call once.
The review can be found here: http://reviews.llvm.org/D10191
llvm-svn: 239654
Summary:
Clean up all the different possible CMake options for specifying the ABI include paths into one CMake option named `LIBCXX_CXX_ABI_INCLUDE_PATHS`.
The documentation has been updated to reflect this change.
For the next week I have added explicit errors if any of the old flags is used. These errors inform users of the change and the new option to use.
Before committing the change I will announce this change on cfe-dev.
Reviewers: danalbert, mclow.lists
Reviewed By: danalbert, mclow.lists
Subscribers: jroelofs, cbergstrom, cfe-commits
Differential Revision: http://reviews.llvm.org/D5039
llvm-svn: 232762
Summary:
This patch adds the `<experimental/tuple>` header (almost) as specified in the latest draft of the library fundamentals TS.
The main changes in this patch are:
1. Added variable template `tuple_size_v`
2. Added function `apply(Func &&, Tuple &&)`.
3. Changed `__invoke` to be `_LIBCPP_CONSTEXPR_AFTER_CXX11`.
The `apply(...)` implementation uses `__invoke` to invoke the given function. `__invoke` already provides the required functionality. Using `__invoke` also allows `apply` to be used on pointers to member function/objects as an extension. In order to facilitate this `__invoke` has to be marked `constexpr`.
Test Plan:
Each new feature was tested.
The test cases for `tuple_size_v` are as follows:
1. tuple_size_v.pass.cpp
- Check `tuple_size_v` on cv qualified tuples, pairs and arrays.
2. tuple_size_v.fail.cpp
- Test on reference type.
3. tuple_size_v_2.fail.cpp
- Test on non-tuple
4. tuple_size_v_3.fail.cpp
- Test on pointer type.
The test cases for tuple.apply are as follows:
1. arg_type.pass.cpp
- Ensure that ref/pointer/cv qualified types are properly passed.
2. constexpr_types.pass.cpp
- Ensure constexpr evaluation of apply is possible for `tuple` and `pair`.
3. extended_types.pass.cpp
- Test apply on function types permitted by extension.
4. large_arity.pass.cpp
- Test that apply can evaluated on tuples and arrays with large sizes.
5. ref_qualifiers.pass.cpp
- Test that apply respects ref qualified functions.
6. return_type.pass.cpp
- Test that apply returns the proper type.
7. types.pass.cpp
- Test apply on function types as required by LFTS.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4512
llvm-svn: 232515
Summary:
This patch adds a lit option to enable color diagnostics when either `--param=color_diagnostics` is passed to LIT or `LIBCXX_COLOR_DIAGNOSTICS` is present in the environment.
My only concern with this patch is that GCC and Clang take different flags and that only GCC 4.9 and greater support `-fdiagnostics-color=always`
Does anybody have objections to this going in?
Reviewers: jroelofs, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7729
llvm-svn: 229707
Summary:
This patch allows the use of LIT's ShTest format in the libc++ test suite. ShTests have the suffix '.sh.cpp'. It also introduces a series of other changes. These changes are:
- More functionality including parsing test metadata has been moved into LIT.
- LibcxxTestFormat now supports multi-part suffixes.
- the `CXXCompiler` functionality has been used to shrink the size of LibcxxTestFormat.
- The recursive loading of the site config has been turned into `libcxx.test.config.loadSiteConfig` so it can be used with libc++abi.
- Temporary files are now created in the build directory of libc++. This follows how it is down in ShTest.
- `not.py` was added as a utility executable that mirrors the functionality of LLVM's `not` executable.
- The first ShTest test was added under test/libcxx/double_include.sh.cpp
Reviewers: jroelofs, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7073
llvm-svn: 226844
When 'no_default_flags' is true only flags passed using '--param=compile_flags'
and '--param=link_flags' will be used when compiling the tests. This option
can be used to run the test suite against libstdc++ and helps with all
unusual test suite configurations.
NOTE: sanitizer flags are still added when '--param=use_sanitizer' is used even
if '--param=no_default_flags' is given.
llvm-svn: 226322
Summary:
In order to fully replace the testit script we need to update LIT so it provides the same functionality.
This patch adds a number of different configuration options to LIT to do that. It also adds documentation for all of the command line parameters that LIT supports.
Generic options added:
- `libcxx_headers`
- `libcxx_library`
- `compile_flags`
Generic options modified:
- `link_flags`: Changed from overriding the default args to adding extra args instead (to match compile flags)
- `use_sanitizer`: Renamed from `llvm_use_sanitizer`
Please see the added documentation for more information about the switches. As for the actual documentation I'm not sure if it should be kept in libc++ forever since it adds an undue maintenance burden, but I think it should be added for the time being while the changes are new. I'm verify unskilled with HTML so if the documentation needs any changes please let me know.
Hopefully this will kill testit.
Reviewers: jroelofs, mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: alexfh, cfe-commits
Differential Revision: http://reviews.llvm.org/D5877
llvm-svn: 224728
Summary:
Currently to run tests in tree you need to symlink the lit.site.cfg file generated by the cmake build into the source tree, and teach your VCS to ignore it.
This allows the user to specify where to find the lit.site.cfg file two different ways:
* lit_site_config lit parameter
* LIT_SITE_CONFIG enviroment variable.
example usage:
```
lit -sv --param=libcxx_site_config=path/to/libcxx-build/test/lit.site.cfg path/to/tests
```
Or
```
export LIBCXX_SITE_CONFIG=path/to/libcxx-build/test/lit.site.cfg
lit -sv path/to/tests
```
The command line parameter will override the environment variable.
If neither options are present a warning is issued and the `lit.cfg` file is loaded directly.
Reviewers: mclow.lists, jroelofs, danalbert
Reviewed By: danalbert
Subscribers: ddunbar, cfe-commits
Differential Revision: http://reviews.llvm.org/D6255
llvm-svn: 224671
Summary:
This is the second attempt at allowing for the use of libraries that the linker cannot find. The first attempt used `CMAKE_LIBRARY_PATH` and `find_library` to select which ABI library should be used. There were a number of problems with this approach:
- `find_library` didn't work with cmake targets (ie in-tree libcxxabi build)
- It wasn't always possible to determine where `find_library` actually found your library.
- `target_link_libraries` inserted the path of the ABI library into libc++'s RPATH when `find_library` was used.
- Linking libc++ and it's ABI library is a special case. It's a lot easier to keep it simple.
After discussion with @cbergstrum a new approach was decided upon.
This patch achieve the same ends by simply using `LIBCXX_CXX_ABI_LIBRARY_PATH` to specify where to find the library (if the linker won't find it). When this variable is defined it is simply added as a library search path when linking libc++. It is a lot easier to duplicate this behavior in LIT. It also prevents libc++ from being linked with an RPATH.
Reviewers: mclow.lists, cbergstrom, chandlerc, danalbert
Reviewed By: chandlerc, danalbert
Subscribers: chandlerc, cfe-commits
Differential Revision: http://reviews.llvm.org/D5860
llvm-svn: 220157
Summary:
This patch adds support for building/testing libc++ with an ABI library that the linker would not normally find.
- `CMAKE_LIBRARY_PATH` is used to specify the list of search directories.
- The ABI library is now found using `find_library` instead of assuming its along the linker's search path.
- `CMAKE_LIBRARY_PATH` is passed to our LIT config as `library_paths`.
- For each path in `library_paths` the following flags are added `-L<path> -Wl,-rpath -Wl,<path>`
Some changes in existing behavior were also added:
- `target_link_libraries` is now passed the ABI library file instead of the library name. Ex `target_link_libraries(cxx "/usr/lib/libc++abi.so")` vs `target_link_libraries(cxx "c++abi")`.
- `-Wl,-rpath -Wl,<path>` is now used on OSX to link to libc++ instead of env['DYLD_LIBRARY_PATH'] if `use_system_lib=False`.
Reviewers: mclow.lists, danalbert, EricWF
Reviewed By: EricWF
Subscribers: emaste, cfe-commits
Differential Revision: http://reviews.llvm.org/D5038
llvm-svn: 220118
Summary:
Instead of having to update test results for different platforms it would be helpful to just supply links to buildbots that build+test libcxx.
For the FreeBSD bots Pawel Worach gave me the OK to link to them.
Reviewers: mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4947
llvm-svn: 215882
Okay, so this actually does more than just that. I've rearranged most of
the information on the page to try to make it more helpful and flow
better. Essentially, the differences between Mac and Linux, the various
ABI libraries, and in-tree versus out-of-tree builds were cluttering
things. To clean up, I've done the following:
* Only describe the cmake process. buildit doesn't work out of the box
on Linux, and we need to stop having duplicates for every process.
* Use libc++abi for the default instructions. This works on the major
platforms.
* Describe both in-tree and out-of-tree builds. Previously it wasn't
clear that in-tree builds were even possible for libc++.
* Separate the documentation about using libc++ from that about
building and testing libc++.
llvm-svn: 215358
Summary:
This patch adds the `<experimental/utility>` header as specified in the latest draft of the library fundamentals TS.
`<experimental/utility>` only contains `class erased_type`.
This patch also updates the documentation to list the `erased_type` class as "initial implementation complete".
Test Plan:
Three test cases where added:
1. Test that `_LIBCPP_VERSION` is defined.
2. Test that `<utility>` has been included.
3. Test that `erased_type` is in the correct namespace and is constexpr default constructible.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4510
llvm-svn: 213226
to remove redundant wording, which required no changes to libc++. 2075 was a
rewrite of the requirements for forward progress, and again, requires no changes
to the library.
llvm-svn: 204724
Also mark #2104 as complete. Leave the implementation in libc++ as noexcept, since
implementations are allowed to add noexcept to non-virtual calls. If we throw from
unique_lock& operator=(unique_lock&& u), then that means the preconditions were violated,
and calling terminate() (as a result of throwing from a noexcept function) is as
good example of undefined behavior as any other.
llvm-svn: 204653
This is as straightforward as it sounds, a renamed from shared_mutex to
shared_timed_mutex.
Note that libcxx .dylib and .so files built with c++14 support need to
be rebuilt.
llvm-svn: 204078
Linking against libstdc++, rather than libsupc++, is probably better
for people who need to link against clients of libstdc++. Because
libsupc++ is provided only as a static library, its globals are not
shared between the static library and the copy linked into libstdc++.
This has been found to cause at least one test failure.
This also removes a number of symbols which were multiply defined
between libstdc++ and libc++, only when linking with libstdc++.
Differential Revision: http://llvm-reviews.chandlerc.com/D1825
llvm-svn: 192075
1. I had been detecting and trapping iterator == and \!= among iterators
in different containers as an error. But the trapping itself is actually
an error.
Consider:
#include <iostream>
#include <vector>
#include <algorithm>
template <class C>
void
display(const C& c)
{
std::cout << "{";
bool first = true;
for (const auto& x : c)
{
if (\!first)
std::cout << ", ";
first = false;
std::cout << x;
}
std::cout << "}\n";
}
int
main()
{
typedef std::vector<int> V;
V v1 = {1, 3, 5};
V v2 = {2, 4, 6};
display(v1);
display(v2);
V::iterator i = std::find(v1.begin(), v1.end(), 1);
V::iterator j = std::find(v2.begin(), v2.end(), 2);
if (*i == *j)
i = j; // perfectly legal
// ...
if (i \!= j) // the only way to check
v2.push_back(*i);
display(v1);
display(v2);
}
It is legal to assign an iterator from one container to another of the
same type. This is required to work. One might want to test whether or
not such an assignment had been made. The way one performs such a check
is using the iterator's ==, \!= operator. This is a logical and necessary
function and does not constitute an error.
2. I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
This caused a problem in several of the libc++ tests.
Fixed.
3. There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
std::basic_string is inoperable. std::basic_string uses __wrap_iterator
to implement its iterators. __wrap_iterator has been rigged up in debug
mode to support vector. But string hasn't been rigged up yet. This means
that one gets false positives when using std::string in debug mode. I've
upped std::string's priority in www/debug_mode.html.
llvm-svn: 187636
There are actually two debug modes:
1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.
2. -D_LIBCPP_DEBUG2=0
This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity.
llvm-svn: 187369
You can now configure from the command line using:
-DLIBCXX_CXX_ABI=libsupc++
-DLIBCXX_LIBSUPCXX_INCLUDE_PATHS="path;path
Also documents how to build on Linux.
llvm-svn: 171316
localization/locale.categories/category.collate/category.ctype/locale.ctype.byname/is_1.pass.cpp
and scan_is.pass.cpp. The tests fail when the character class being
tested is compound, like ctype_base::alnum or ctype_base::graph,
because the existing series of conditionals in do_is an do_scan_is
will abort too early. For instance, if the character class being
tested is alnum, and the character is numeric, do_is will return false
because iswalpha_l will return false, 'result' becomes false, and the
'true' result from the later call to iswdigit_l ends up being ignored
. A similar problem exists in do_scan_is.
llvm-svn: 161192
test/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/pointer.pass.cpp
to accept '(nil)' as a valid representation for NULL so that the test
passes on Linux. The same thing is already done in some other tests,
like in /test/localization/locale.categories/category.numeric/locale.nm.put/facet.num.put.members/put_pointer.pass.cpp.
llvm-svn: 161188
There are a few tests that are listed as failing here for which I have
a patch in the works. I'll be sending those along soon. There are
others where I know what is going on but don't yet have a solution,
and I've included some notes for those. Several still need to be
investigated, mostly in localization and the regex test suite. I think
that many of these failures are due to locale implementation
variations that make the expected test results not match the actual
results. I'm not sure what the best way to make the tests accomodate
this sort of variation might be.
The failures in the unique_ptr test suite are very new and are caused
by a clang crash which I've not yet looked into.
llvm-svn: 161079
Marshall Clow