Otherwise, even specifying a runtime root different from the library
we're linking against won't work -- the library we're linking against
is always used. This is undesirable if we try testing something like
linking against a recent libc++.dylib but running the tests against an
older version (the back-deployment use case).
llvm-svn: 349171
Other standard libraries don't implement availability markup, so it doesn't
make sense to e.g. XFAIL tests based on availability markup outside of
libc++.
llvm-svn: 348871
This is part of an ongoing cleanup of the LIT test suite, where I'm
trying to reduce the number of configuration options. In this case,
the original intent seemed to be running the test suite with libstdc++,
but this is now supported by specifying cxx_stdlib_under_test=libstdc++.
llvm-svn: 348868
It is unreachable because we test that the cxx_stdlib_under_test is
in the supported set of libraries elsewhere. Furthermore, this code
relied on the `use_stdlib_type`, which is never defined.
llvm-svn: 348867
Otherwise, some tests would fail when a relative path was passed,
because they'd use the relative path from a different directory
than the current working directory.
llvm-svn: 348525
Summary:
Running the tests without availability enabled doesn't really make sense:
availability annotations allow catching errors at compile-time instead
of link-time. Running the tests without availability enabled allows
confirming that a test breaks at link-time under some configuration,
but it is more useful to instead check that it should fail at compile-time.
Always enabling availability in the lit test suite will greatly simplify
XFAILs and troubleshooting of failing tests, which is currently a giant
pain because we have these two levels of possible failure: link-time and
compile-time.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55079
llvm-svn: 348296
We used to print a Python list corresponding to the command. It is more
useful to print the joined string so it can be copy/pasted directly when
a test fails.
llvm-svn: 347471
This patch renames the cxx-benchmark-unittests to check-cxx-benchmarks
and converts the target to use LIT in order to make the tests run faster
and provide better output.
In particular this runs each benchmark in a suite one by one, allowing
more parallelism while ensuring output isn't garbage with multiple threads.
Additionally, it adds the CMake flag '-DLIBCXX_BENCHMARK_TEST_ARGS=<list>'
to specify what options are passed when running the benchmarks.
llvm-svn: 346888
Summary:
The result of subprocess.check_output() is bytes in python3 which we need
to convert to str(). Simplify this by using the executeCommand() helper.
Reviewers: ldionne, EricWF
Reviewed By: ldionne
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54522
llvm-svn: 346878
Summary:
Running the test suite with -a will now properly show all the executed
commands. The reports also include the environment under which the test
is being executed, which is helpful for reproducing issues.
Reviewers: EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53215
llvm-svn: 344700
Summary:
The `[[nodiscard]]` attribute is intended to help users find bugs where
function return values are ignored when they shouldn't be. After C++17 the
C++ standard has started to declared such library functions as `[[nodiscard]]`.
However, this application is limited and applies only to dialects after C++17.
Users who want help diagnosing misuses of STL functions may desire a more
liberal application of `[[nodiscard]]`.
For this reason libc++ provides an extension that does just that! The
extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended
applications of `[[nodiscard]]` takes two forms:
1. Backporting `[[nodiscard]]` to entities declared as such by the
standard in newer dialects, but not in the present one.
2. Extended applications of `[[nodiscard]]`, at the libraries discretion,
applied to entities never declared as such by the standard.
Users may also opt-out of additional applications `[[nodiscard]]` using
additional macros.
Applications of the first form, which backport `[[nodiscard]]` from a newer
dialect may be disabled using macros specific to the dialect it was added. For
example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`.
Applications of the second form, which are pure extensions, may be disabled
by defining `_LIBCPP_DISABLE_NODISCARD_EXT`.
This patch was originally written by me (Roman Lebedev),
then but then reworked by Eric Fiselier.
Reviewers: mclow.lists, thakis, EricWF
Reviewed By: thakis, EricWF
Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D45179
llvm-svn: 342808
On some platforms clock_gettime is in librt, which we don't
link by default when building the tests. However it is required
by the filesystem tests.
This patch introduces a workaround which links librt whenever
the filesystem tests are enabled. The workaround should later
be replaced with a patch that selectively links both libc++fs
and librt only when building filesystem specific tests. However,
the way the test configuration is set up right now, this is
non-trivial.
llvm-svn: 340406
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
This fixes a couple of tests which produced a warning that a 'throw'
occurred in a noexcept function (by way of _LIBCPP_ASSERT). It does
so by hiding the 'throw' across an opaque function boundary.
This fix isn't ideal, since we still have _LIBCPP_ASSERT's in functions
marked noexcept -- and this problem should be addressed in the future.
However, throwing _LIBCPP_ASSERT is really only meant to allow testing
of the assertions, and is not yet ready for general use.
llvm-svn: 328265
Summary:
These flags can be specified using the CMake variables
LIBCXX_TEST_LINKER_FLAGS and LIBCXX_TEST_COMPILER_FLAGS.
When building the tests for CHERI I need to pass additional
flags (such as -mabi=n64 or -mabi=purecap) to the compiler
for our test configurations
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D42139
llvm-svn: 325914
Previously .fail.cpp tests for nodiscard were run with -Wunused-result
being a warning, not an error, when the compiler didn't support -verify.
When -verify isn't enabled this change judiciously adds -Werror=unused-result
when to only the failure tests containing the // expected-error string for nodiscard.
As a drive-by change, this patch also adds a missing // UNSUPPORTED: c++2a to
a test which was only supposed to run in C++ <= 11.
llvm-svn: 322776
This patch teaches the test suite configuration about the -std=c++2a
flag. And, since it's the newest dialect, change the test suite to
choose it, if possible, by default.
llvm-svn: 317611
This patch changes the test suite to attempt and prefer -std=c++17 over
-std=c++1z. It also fixes the REQUIRES and UNSUPPORTED lit markers
to refer to c++17 over c++1z.
llvm-svn: 317610
The vcruntime headers are hairy and clash with both libc++ headers
themselves and other libraries. libc++ normally deals with the clashes
by deferring to the vcruntime headers and silencing its own definitions,
but for clients which don't want to depend on vcruntime headers, it's
desirable to support the opposite, i.e. have libc++ provide its own
definitions.
Certain operator new/delete replacement scenarios are not currently
supported in this mode, which requires some tests to be marked XFAIL.
The added documentation has more details.
Differential Revision: https://reviews.llvm.org/D38522
llvm-svn: 315234
Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.
The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.
Differential Revision: https://reviews.llvm.org/D36719
llvm-svn: 314946
Previously LIT would often fail while attempting to set up/configure
the test compiler; normally when attempting to dump the builtin macros.
This sort of failure provided no useful information about what went
wrong with the compiler, making the actual issues hard --- if not
impossible --- to debug easily.
This patch changes the LIT configuration to report the failure explicitly,
including the failed compile command and the stdout/stderr output.
llvm-svn: 314735
Using the system default 'ar' might not be the right choice when
cross compiling.
Don't prepend the ar options by a dash, not all ar implementations
support that (llvm-ar doesn't).
Also pass the 's' option when creating the merged library, to create
an index.
Differential Revision: https://reviews.llvm.org/D37134
llvm-svn: 313122
On Apple the test feature 'sanitizer-new-delete' was incorrectly
getting added to the LIT feature set, which mistakenly caused tests
to be disabled when using UBSAN (the feature is only needed with ASAN/MSAN/TSAN).
llvm-svn: 307518
32-bit powerpc provides a 64 bit time_t type and older ppc64 systems
provide time_t as a floating point type. This caused problems when building
operations.cpp since operations.cpp contained compile time tests for conversions
between time_t and filesystem time type.
When these tests failed they caused the libc++ build to fail as well. This is unfortunate.
This patch moves the tests out of the source file and into the test suite. It also
expands the tests to allow testing of the weird time_t configurations on all platforms.
llvm-svn: 307461
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
Summary:
This reference to lit.util.capture is functionally identical to
subprocess.check_output, so this change switches to call the library routine
directly.
Reviewers: mzolotukhin, EricWF
Reviewed By: mzolotukhin
Subscribers: sanjoy, llvm-commits
Differential Revision: https://reviews.llvm.org/D34841
llvm-svn: 306755
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
Now with proper newlines.
llvm-svn: 302497
Previously, the force includes would complain about a missing _DEBUG symbol.
Now we dump macros before adding the force includes to the command line.
llvm-svn: 302421
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
This patch XFAIL's a number of tests under test/libcxx when on Windows.
These failures need more investigation or patches to either Clang or libc++
but for now we don't want them to prevent the bot from going green.
llvm-svn: 300941
Previously both the static version of libc++ and the
import library for the DLL had the same name, 'c++.lib'.
This patch renames the static library on Windows to be `libc++.lib`
so it no longer conflicts. This naming convention is consistent with
other windows libraries.
llvm-svn: 300817
Can be used as such:
$ python /path/to/lit.py -sv /path/to/llvm/build/projects/libcxx/test/ \
--param=use_system_cxx_lib=true \
--param=executor='SSHExecutor("remote.domain", "username")'
llvm-svn: 299607
As we're trying to setup testing / bots for all shipping version of libc++
on macOS/iOS, we'll need to be able to pass a path to where to find the
dylib for each previous version of the OS.
Differential Revision: https://reviews.llvm.org/D31486
llvm-svn: 299053
The tests for libc++ specify -target on the command-line to the
compiler, but this is problematic for a few reasons.
Firstly, the -target option isn't supported on Apple platforms. Parts
of the triple get dropped and ignored. Instead, software should be
compiled with a combination of the -arch and -m<name>-version-min
options.
Secondly, the generic "darwin" target references a kernel version
instead of a platform version. Each platform has its own independent
versions (with different versions of libc++.1.dylib), independent of the
version of the Darwin kernel.
This commit adds support to the LIT infrastructure for testing against
Apple platforms using -arch and -platform options.
If the host is not on OS X, or the compiler type is not clang or apple-clang, then this commit has NFC.
If the host is on OS X and --param=target_triple=... is specified, then a warning is emitted to use arch and platform instead. Besides the warning, there's NFC.
If the host is on OS X and *no* target-triple is specified, then use the new deployment target logic. This uses two new lit parameters, --param=arch=<arch> and --param=platform=<platform>. <platform> has the form <name>[<version>].
By default, arch is auto-detected from clang -dumpmachine, and platform is "macosx".
If the platform doesn't have a version:
For "macosx", the version is auto-detected from the host system using sw_vers. This may give a different version than the SDK, since new SDKs can be installed on older hosts.
Otherwise, the version is auto-detected from the SDK version using xcrun --show-sdk-path.
-arch <arch> -m<name>-version-min=<version> is added to the compiler flags.
The target triple is computed as <arch>-apple-<platform>. It is *not* passed to clang, but it is available for XFAIL and UNSUPPORTED (as is with_system_cxx_lib=<target>).
For convenience, apple-darwin and <arch>-apple-darwin are added to the set of available features.
There were a number of tests marked to XFAIL on x86_64-apple-darwin11
and x86_64-apple-darwin12. I updated these to
x86_64-apple-macosx10.7 and x86_64-apple-macosx10.8.
llvm-svn: 297798
The path would previously get an extra leading space as the arguments
would be parsed when generating the final command to run. Pretokenise
the arguments to permit proper quoting of the paths. This avoids a
number of ignoring non-existent path warnings from clang.
llvm-svn: 295511
Summary:
This patch fixes http://llvm.org/PR31938. The description below is copy/pasted from the bug:
The standard says:
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT>>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like fixing this will not result in an ABI break.
@rsmith How does this look? I did more than just the constructors mentioned in the PR, but IDK how far to take it.
Reviewers: mclow.lists, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29863
llvm-svn: 295393
When running the tests on Windows with a debug build, _DEBUG must be
added to the flags prior to the -target as the forced inclusion of a
header will prevent the compile test for the flag to fail.
llvm-svn: 294716
Libc++ frequently creates and uses utilities written in python.
Currently there are python modules under both libcxx/test and
libcxx/util. My goal with these changes is to consolidate them
into a single package under libcxx/utils/libcxx.
llvm-svn: 294644
Currently sym_check almost all names found in the binary, including those
which are defined in other libraries. This makes our ABI lists harder to maintain.
This patch adds a --only-stdlib-symbols option to sym_check which removes
all symbols which aren't possibly provided by libc++. It also re-generates
the linux ABI list after making this change.
llvm-svn: 287294
Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
holds 'public' interface libraries -- that is, libraries that both
libc++ links to and programs linked against it need to link to.
Currently this includes the ABI library and optionally -lunwind (when
LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
linker script, in order to make it possible to link C++ programs using
clang with compiler-rt runtime out-of-the-box.
Differential Revision: https://reviews.llvm.org/D25008
llvm-svn: 283659
I've put some work into the Google Benchmark library in order to make it easier
to benchmark libc++. These changes have already been upstreamed into
Google Benchmark and this patch applies the changes to the in-tree version.
The main improvement in the addition of a 'compare_bench.py' script which
makes it very easy to compare benchmarks. For example to compare the native
STL to libc++ you would run:
`$ compare_bench.py ./util_smartptr.native.out ./util_smartptr.libcxx.out`
And the output would look like:
RUNNING: ./util_smartptr.native.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 62 ns 62 ns 10937500
BM_SharedPtrIncDecRef 31 ns 31 ns 23972603
BM_WeakPtrIncDecRef 28 ns 28 ns 23648649
RUNNING: ./util_smartptr.libcxx.out
Benchmark Time CPU Iterations
----------------------------------------------------------------
BM_SharedPtrCreateDestroy 46 ns 46 ns 14957265
BM_SharedPtrIncDecRef 31 ns 31 ns 22435897
BM_WeakPtrIncDecRef 34 ns 34 ns 21084337
Comparing ./util_smartptr.native.out to ./util_smartptr.libcxx.out
Benchmark Time CPU
-----------------------------------------------------
BM_SharedPtrCreateDestroy -0.26 -0.26
BM_SharedPtrIncDecRef +0.00 +0.00
BM_WeakPtrIncDecRef +0.21 +0.21
llvm-svn: 278147
Summary:
This patch does the following:
1. Checks in a copy of the Google Benchmark library into the libc++ repo under `utils/google-benchmark`.
2. Teaches libc++ how to build Google Benchmark against both (A) in-tree libc++ and (B) the platforms native STL.
3. Allows performance benchmarks to be built as part of the libc++ build.
Building the benchmarks (and Google Benchmark) is off by default. It must be enabled using the CMake option `-DLIBCXX_INCLUDE_BENCHMARKS=ON`. When this option is enabled the tests under `libcxx/benchmarks` can be built using the `libcxx-benchmarks` target.
On Linux platforms where libstdc++ is the default STL the CMake option `-DLIBCXX_BUILD_BENCHMARKS_NATIVE_STDLIB=ON` can be used to build each benchmark test against libstdc++ as well. This is useful for comparing performance between standard libraries.
Support for benchmarks is currently very minimal. They must be manually run by the user and there is no mechanism for detecting performance regressions.
Known Issues:
* `-DLIBCXX_INCLUDE_BENCHMARKS=ON` is only supported for Clang, and not GCC, since the `-stdlib=libc++` option is needed to build Google Benchmark.
Reviewers: danalbert, dberlin, chandlerc, mclow.lists, jroelofs
Subscribers: chandlerc, dberlin, tberghammer, danalbert, srhines, hfinkel
Differential Revision: https://reviews.llvm.org/D22240
llvm-svn: 276049
Summary:
Currently on most platforms you have to manually link the c++ abi library used with libc++ whenever you use libc++. So your typical libc++ command like invocation might look like:
```
clang++ -stdlib=libc++ foo.cpp -lc++abi
```
Having to manually link `libc++abi.so` makes it harder for libc++ to be used generically. This patch fixes that by generating a linker script for `libc++.so` that correctly links the ABI library. On linux the linker script for libc++abi would look like:
```
# libc++.so
INPUT(libc++.so.1 -lc++abi)
```
With the linker script you can now use libc++ using only `-stdlib=libc++`. This is the technique that is used on FreeBSD in ordered to link cxxrt and I think it's the best approach to make our users lives simpler.
The CMake option used to enable this is `LIBCXX_ENABLE_ABI_LINKER_SCRIPT`. In future I would like to enable this by default on all platforms except for Darwin.
Reviewers: mclow.lists, danalbert, rsmith, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12508
llvm-svn: 250319
Summary:
Add symbol checking scripts for extracting a list of symbols from shared libraries and for comparing symbol lists for differences.
Reviewers: mclow.lists, danalbert, EricWF
Reviewed By: EricWF
Subscribers: majnemer, emaste, cfe-commits
Differential Revision: http://reviews.llvm.org/D4946
llvm-svn: 232855
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
Eric Fiselier