Tests that require support for Clang-verify are already marked as such
explicitly by their extension, which is .verify.cpp. Requiring the use
of an explicit Lit feature is, after thought, not really helpful.
This is a change in design: we have been bitten in the past by tests not
being enabled when we thought they were. However, the issue was mostly
with file extensions being ignored. The fix for that is not to blindly
require explicit features all the time, but instead to report all files
that are in the suite but that don't match any known test format. This
can be implemented in a follow-up patch.
This reverts commit 51a60ed14c, since the test still doesn't pass on
Windows. Marking the test as UNSUPORTED on Windows again until I've
figured out the problem.
Instead of completely disabling the tests on Apple, which makes them
disabled on all platforms we test (and hence useless), this commit
disables only the assertions that actually fail. I also created a
bug report to track re-enabling them (https://llvm.org/PR45739).
These two locale tests are disabled because they were said to "pass in
an uncontrolled manner on Apple platforms". This commit re-enables them
to see what that means, and whether that is still relevant on the
platforms we test.
Before this commit, the tests were either XFAILed or UNSUPPORTED on
Apple and Linux, which is pretty much all the systems we support. If
the tests truly don't work anywhere, they should be removed instead.
Since 88af3ddb1e, libc++ will prefer Python 3 when available. It is
available on Apple platforms, so subprocess.check_output will return
bytes instead of str. This lead to comparisons against str to be false,
and the MacOS platform not being detected properly.
This allows defining Lit features that can be enabled or disabled based
on compiler support, and parameters that are passed on the command line.
The main benefits are:
- Feature detection is entirely based on the substitutions provided in
the TestingConfig object, which is simpler and decouples it from the
complicated compiler emulation infrastructure.
- The syntax is declarative, which makes it easy to see what features
and parameters are accepted by the test suite. This is significantly
less entangled than the current config.py logic.
- Since feature detection is based on substitutions, it works really
well on top of the new format, and custom Lit configurations can be
created easily without being based on `config.py`.
This commit is a reapplication of 6d58030c8c, which was reverted in
8f24c4b72f because it broke Python 3 support. This re-application
supports Python 3.
Differential Revision: https://reviews.llvm.org/D78381
This relands this commit as it broke the LLDB bot the first time it landed.
See also the discussion on https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
Since D74892 this code should now also work on macOS.
Original description:
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
Defining the nested types `reference` and `iterator_concept` of `reverse_iterator<I>` necessarily requires `I` to be complete in C++20. These tests that verify that `std::map<int, X>::reverse_iterator` can be instantiated when `X` is incomplete are going to have a bad time.
Differential Revision: https://reviews.llvm.org/D78944
Instead of using the libc++ headers provided alongside the toolchain,
use those in the sibling libcxx directory that we know is checked out.
Before the days of the monorepo, we couldn't assume that the libc++
repository was present when building libcxxabi. Since we can now make
that assumption, it's always better to use the version of libc++ that
is in lockstep with libc++abi, to avoid subtle bugs.
This allows defining Lit features that can be enabled or disabled based
on compiler support, and parameters that are passed on the command line.
The main benefits are:
- Feature detection is entirely based on the substitutions provided in
the TestingConfig object, which is simpler and decouples it from the
complicated compiler emulation infrastructure.
- The syntax is declarative, which makes it easy to see what features
and parameters are accepted by the test suite. This is significantly
less entangled than the current config.py logic.
- Since feature detection is based on substitutions, it works really
well on top of the new format, and custom Lit configurations can be
created easily without being based on `config.py`.
Differential Revision: https://reviews.llvm.org/D78381
The runtime for Blocks may not be available even though the Blocks
language extension _is_ available. Instead of potentially failing,
this commit is much more conservative and assumes the runtime for
Blocks is only provided on Apple platforms.
Differential Revision: https://reviews.llvm.org/D78757
The introduction of LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT changed
the default from =1 (assuming merged typeinfos) to =0 (not assuming
merged typeinfos) on all platforms where at least one other __config_site
macro is defined.
This commit explicitly enables the assumption of merged typeinfo names
on Apple platform to restore the previous behavior, at least until the
underlying issue has been fixed.
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
It turns out that all this time, we've actually been building without
assertions enabled in the dylib. This commit updates the Apple CMake
cache to make it consistent with reality.
When the new libc++ test format was enabled, warnings were accidentally
dropped cause they were not part of the %{compile_flags} substitution.
This commit adds them back, however `-Werror` is only used for non-verify
tests (cause it doesn't make sense for verify tests).
This commit is a re-application of 20fd624380, which was reverted in
5ec6fdb058 because it broke the C++03 bot. This failure should have
been fixed in b4fb705e77.
When the new libc++ test format was enabled, warnings were accidentally
dropped cause they were not part of the %{compile_flags} substitution.
This commit adds them back, however `-Werror` is only used for non-verify
tests (cause it doesn't make sense for verify tests).
Summary:
This patch add the dataflow option to LLVM_USE_SANITIZER and documents
it.
Tested via check-cxx (wip to fix the errors).
Reviewers: morehouse, #libc!
Subscribers: mgorny, cfe-commits, libcxx-commits
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D78390
Summary:
When I read this on the website it looks like the `--` in the used font turns
into an em dash. I updated this with inline literal mark up so the `--` will
remain obvious.
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D78405
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
This was originally committed as f8452ddfcc and reverted in 7cb1aa9d93.
The issue was that shell builtins were being escaped too, and apparently
Bash won't execute a builtin when it is quoted e.g. '!'. Instead, it
thinks it's a command and it can't find it.
Re-committing the change with that issue fixed.
Cherrypick the upstream fix commit a77d5f7 onto llvm/utils/benchmark
and libcxx/utils/google-benchmark.
This fixes LLVM's 32-bit RISC-V compilation, and the issues
mentioned in https://github.com/google/benchmark/pull/955
An additional cherrypick of ecc1685 fixes some minor formatting
issues introduced by the preceding commit.
Differential Revision: https://reviews.llvm.org/D78084
Instead of creating Lit features for all __config_site macros automatically,
only do so for macros that generate features actually used in the test
suite. This makes it easier to know which ones are supported by the test
suite at a glance.
Note that the `libcpp-abi-version-vN` is dropped altogether, but it
wasn't used anywhere.
These substitutions are strongly tied to the operation of the test
format, so it makes sense to have them defined by the test format
instead of the Lit configuration. They should be defined regardless
of which configuration is in use.
Marked unsupported for C++03 and C++11 since this test uses alias
declarations, and at least one C++03 bot was failing with
-Wc++11-extensions.
Change-Id: I8c3a579edd7eb83e0bc74e85d116b68f22400161
The new format requires using an external shell, and as we transition
and we can simplify config.py as we transition to the new format. Also,
frankly, I'd be quite surprised if that setting was still working anyway
because we have several .sh.cpp tests that likely don't work in Lit's
internal shell.
When running the tests through `lit` directly instead of through `check-cxx`,
it is required to manually build the `cxx` (and often `cxx_experimental`)
targets. Instead of having to do that manually, this commit adds a new
target `check-cxx-deps` that does that for you.
When building these tests without modules in the whole test suite,
the __config_site macro definitions are not included anymore in the
%{compile_flags}. This causes the _LIBCPP_HAS_NO_THREADS define not
to be picked up, and the test to XPASS on single-threaded systems.
This is a stop-gap measure to fix the build bots, however the proper
solution would be to always pass the __config_site defines as compiler
macros, whether we build with modules or not.
Avoid using <sys/types.h> in those tests so that we can run them on
non-AIX systems (otherwise this test is basically dead-code on all
the build bots I'm aware of). Also, split up the test to allow using
.compile.pass.cpp tests instead of .sh.cpp tests, since that is the
last test referencing the %{compile} substitution explicitly.
Instead of being ShTests that use clang-verify (and without the proper
REQUIRES annotation), create .verify.cpp tests instead with the right
REQUIRES annotation.
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.
With this patch, .verify.cpp tests explicitly require clang-verify, but
no other test types require clang-verify out of the box. This will allow
making several .fail.cpp tests that don't have any clang-verify markup
to be just .compile.fail.cpp tests, which in turn should allow removing
a long standing workaround that requires parsing tests to detect whether
they have any clang-verify markup in them.
There are no such tests in the libc++ test suite, and I want to move
away from `.fail.cpp` tests (in favour of something else) too, which
require a workaround.
Instead of spamming a bunch of available features that are not actually
used anywhere, only set those that are actually used in the test suite.
In the future, this should probably be based on the target triple only,
with the ability to have wildcards in the triple.
Remove mentions of the ValgrindExecutor, which doesn't exist. That
executor is literally nowhere in the code base, so this is dead code
as far as we're concerned.
Also, inline a one-liner function that was called exactly once.
The libc++ test suite currently defines several features that are not
used anywhere in the tests, or that are redundant with other features.
For the purpose of simplifying config.py and to ease the bring up of a
new configuration, this commit removes some of these features:
- rename dylib-has-no-filesystem to c++filesystem-disabled, which exists
- rename apple-darwin to just darwin, which is already set
- remove useless setting of libstdc++, which is already set correctly
- remove libcpp-abi-unstable, which is not used anywhere
- remove the glibc-XXX features, which are not used anywhere
Summary: We discovered that the compiler may chose not to inline the operator=, which leads to an expensive extra stack frame. This change makes __assign_no_alias always tail called.
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77913
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).
The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.
This is problematic because arrays may be large, and instantiation
depth is limited.
This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.
Patch from Christopher Di Bella (cjdb@google.com)
Reviewed as https://reviews.llvm.org/D74291
Adds `std::same_as` to libc++. Since there aren't clang-format rules for
//requires-expressions//, I'll need to disable the formatter in certain areas.
Our documentation for running LIT is basically wrong, since it doesn't
mention `llvm-lit`, and nothing works without it. Note that this
documentation improvement reflects the current reality outside of
the recent efforts on improving the test suite. My goal is to document
the current way of running the test suite, so that everybody agrees on
how things currently work. As the configuration system for libc++ gets
simplified, we can come back and keep this documentation up to date to
reflect those changes.
Differential Revision: https://reviews.llvm.org/D77673
Summary: 5ade17e broke __is_pointer for Objective-C pointer types. This patch fixes the builtin and re-applies the change to type_traits.
Tags: #clang, #libc
Differential Revision: https://reviews.llvm.org/D77519
std::optional requires C++17. Instead of only running the test above
C++14, this commit removes uses of std::optional from the test (it's
already tested in block.objc.pass.mm).
Broke builders that emit different diagnostics. e.g.:
error: 'warning' diagnostics seen but not expected:
Line 13: alias declarations are a C++11 extension
Line 20: alias declarations are a C++11 extension
This reverts commit ff87813715.
It has never been used, and it actually doesn't really work because it
assumes that the target supports Python. Instead, it's better to just
use `!` since we're running ShTests in system shells anyway.
Instead of creating a temporary directory inside /tmp and running the
tests there, use a directory name based on LIT's %t substitution. This
has the benefit of not hitting /tmp so much (which is slow on some
filesystems). It also has the benefit that `ninja -C build clean` will
automatically remove the artifacts even if a test somehow failed to
remove its temporary directory (I've seen this happen when CTRL-C is
received).
This allows both the old and the new testing formats to handle these
tests with modules enabled.
We also include the modules flags in the %{flags} substitution, which
means that .sh.cpp tests in the old format and all tests in the new
format will use modules flags when enabled.
Otherwise, files don't link when using a GNU linker, which is more
sensitive on the order of the source file relative to the various
linked libraries. See http://c-faq.com/lib/libsearch.html for an
explanation of the problem.
Both test formats are equivalent, so this *should* not be a problem.
We've fixed a couple of failures uncovered by the first time we tried
making the switch, so this new attempt should go even farther.
If failures are noticed, it should be fine to revert this commit, but
please give a heads up afterwards so we know to address the issues!
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
Summary:
This is a patch that Android has been carrying in its tree for several
years. This patch upstreams the existing ABI.
There's some historical cruft here. __regex_word used to be a part of
regex_traits rather than ctype_base. Bionic also used to use its own
ctype implementation because the libc++ builtin one wasn't available
yet. Bionic's ctype masks were 8 bits wide and already saturated, so a
wider type needed to be used for the regex mask, and the existing
value was already used so Android needed to specify its own.
Since then Android has migrated to the builtin ctype implementation
and this patch probably should have been dropped then. Unfortunately
that was not noticed at the time, so now we need to keep this to
maintain the current ABI.
Reviewers: EricWF, #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76171
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
We had a workaround because GCC 5 does not evaluate static assertions
that are dependent on template parameters. This commit removes the
workaround and marks the corresponding tests as unsupported with GCC 5.
This has the benefit of bringing the new and the old test formats closer
without having to carry a workaround for an old compiler in the new
test format.
Otherwise, we're missing some flags like the flags that are used by
sanitizer builds and the 32-bit builds. In the long term, I think it
would be better to have only %{compile_flags} and %{link_flags}, but
for the benefit of adopting the new format by default, I think it's OK
to add %{flags} to it.
On Windows, we must make sure to close the temporary tar file before we
try to scp it.
This is an alternative approach to https://reviews.llvm.org/D77500.
This reverts commit 1580c76c4a.
This causes libcxx/selftest/newformat/sh.cpp/substitutions.sh.cpp to
fail with a linker error on Fedora 31 (x86-64) release (no assert)
builds.
Both test formats are equivalent, so this *should* not be a problem.
However, I'm taking advantage of the week-end to test this and see if
there are any failures. If so, it should be fine to revert this until
the failures have been addressed.
For the time being, it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit.
Summary:
Allow users to simultaneously enable address and undefined behavior
sanitizers, in the same manner that LLVM's 'HandleLLVMOptions.cmake'
allows.
Prior to this patch, `cmake -DLLVM_USE_SANITIZER="Address;Undefined"`
would succeed and the build would build most of the LLVM project with
`-fsanitize=address,undefined`, but a warning would be printed by
libcxx's CMake, and the build would use neither sanitizer. This
patch results in no warning being printed, and both sanitizers are used
in building libcxx.
Reviewers: jroelofs, EricWF, ldionne, #libc!
Subscribers: mgorny, dexonsmith, llvm-commits, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D77466
Always depend on the compiler to have a correct implementation of
max_align_t in stddef.h and don't provide a fallback. For pre-C++11,
require __STDCPP_NEW_ALIGNMENT__ in <new> as provided by clang in all
standard modes. Adjust test cases to avoid testing or using max_align_t
in pre-C++11 mode and also to better deal with alignof(max_align_t)>16.
Document requirements of the alignment tests around natural alignment of
power-of-two-sized types.
Differential revision: https://reviews.llvm.org/D73245
The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
This test regressed with 5ade17e0ca, but we never noticed it because
.pass.mm tests were skipped due to a bug in our Lit config. This commit
fixes is_pointer (by essentially reverting tha part of 5ade17e0ca) and
also adds .pass.mm tests to the list of supported test suffixes.
We can explore how to support __is_pointer with Objective-C++ qualifiers
as a follow-up -- the main goal of this commit is to fix the regression
quickly and make sure all tests of the suite are run.
Instead of hardcoding absolute paths on the build-host in the executables,
use relative paths from the current working directory. Also, use
FILE_DEPENDENCIES to mark the static test env as being required by
the relevant tests.
Given a SSH executor that copies the files to the remote host properly,
the tests can be run on that remote host.
Chromium's build sets LIBCXX_CXX_ABI_SYSTEM explicitly when building
libc++, which was broken by 61e89737c5 (which stopped listening to
that option). As a workaround, this commit uses the system libc++abi
when LIBCXX_CXX_ABI_SYSTEM is used.
However, we will need to work with Chromium to standardize their build
of libc++, because LIBCXX_CXX_ABI_SYSTEM is not a public facing build
configuration for libc++, and has never been AFAICT.
The 'runtimes' build started failing because libc++ stopped using the
in-tree libc++abi when HAVE_CXXABI is set after 61e89737c. This commit
tries to bring back the old behavior when HAVE_CXXABI is set in order
to fix CIs.
However, we really need to sit down and discuss what ways of building
libc++ are supported and formalize them, because having the libc++ build
system branch on basically random variables in some CMake cache somewhere
is not a viable path forward.
... in `msvc_stdlib_force_include.h` to also ignore new MSVC warning C5215 "'%s' a function parameter with volatile qualified type is deprecated in C++20". Since we're touching it, also update from non-standard `__pragma(meow)` to standard `_Pragma("meow")`.
This patch reimplements the dynamic filesystem helper using Posix
functionality instead of relying on Python. The primary reason for
doing this is that it allows running the libc++ test suite on devices
that do not have Python.
Differential Revision: https://reviews.llvm.org/D77140
In standalone builds the cxxabi_shared and cxxabi_static targets don't exist.
We need to link against the library itself.
Differential Revision: https://reviews.llvm.org/D77294
This commit removes support for building against the system libc++abi,
which was supported on Apple platforms. This is basically never what we
want to do, since libc++ and libc++abi are coupled and building a trunk
libc++ against an older libc++abi can lead to incompatibilities (and
good luck debugging them!). It might have made some sense to support
that when the monorepo did not exist, however I don't think this is
anything but a footgun nowadays.
Furthermore, based on the newly-made assumption that we're building
against the monorepo libc++abi, we can simplify the search path logic
for finding libc++abi.
This area of our build system has a lot of technical debt accumulated,
and it's surprisingly difficult to change. We've tried different things
and failed several times in the past. I did test this change on our
Docker image for the build bots and on Apple platforms, however it is
possible that this breaks some unknown configuration, in which case it
should be fine to revert this (so we can try again!).
Instead of executing tests from within the libc++ test suite, we execute
them from the Lit execution directory. However, since some tests have
file dependencies, we must copy those dependencies to the execution
directory where they are executed.
This has the major benefit that if a test modifies a file (whether it
is wanted or not), other tests will not see those modifications. This
is good because current tests assume that input data is never modified,
however this could be an incorrect assumption if some test does not
behave properly.
Based on an issue brought up in https://reviews.llvm.org/D67900, this commit reverts the changes to is_floating_point and is_arithmetic made in D67900.
After D67900 landed, __float128 behaved differently in those two type traits, causing compiler errors in numeric limits (and possibly others).
The benefit of doing this is that we can now handle directories that
contain symlinks and other arbitrary things, such as the static_test_env
required by filesystem tests.
As a fly-by fix, we also accumulate several commands to perform over SSH
and execute them at once instead of SSHing several times. This should be
faster on average.
If a ShTest has for example another command in front of the test
executable it wants to execute, ssh.py needs to properly translate
the path of that test executable to the executable on the remote host.
For example, running '%{exec} ! %t.exe', we can't assume that the
test-executable is the first argument after '%{exec}'.
Using the ADDITIONAL_COMPILE_FLAGS annotation, it is possible to move
these tests from .sh.cpp to .pass.cpp, making them suitable for running
on remote hosts more easily.
Louis Dionne