This allows seeing the names of tests as they are executed, making
the intermediate log output on github actions more useful. It
also makes it easier to correlate test issues between tests as
they are executed (e.g. if one test causes another one to run out
of memory).
Also run with --time-tests, allowing identifying slow tests.
This was already applied in the separate libcxx test job added in
7483eae1821766a0f84dbd96f5619058f7065008; this backports the change
into the test job in the main build file.
This version fixes the following issues for mingw/windows targets:
- Fix linking the lli tool if built with asan enabled
- Fix compiling for the aarch64 target if specifying -mtune=cortex-a53
- Fix initialization order among constructors within one translation unit
This contains a few bugfixes for mingw use cases:
- LLD in 17.0.1 and the earlier 17.x release candidates looked up
libraries (including libraries named as a relative path) preferring
to search in toolchain relative paths over first testing from the
current directory. In some cases, this could cause cryptic build
failures; see https://github.com/llvm/llvm-project/issues/67779.
- Options that only are relevant for linking, like -mwindows, used
to be accepted (but produce a warning) if used in a compilation-only
job. In the earlier 17.x releases/RCs, such warnings caused an
error instead; see https://github.com/llvm/llvm-project/issues/64464
and https://github.com/mstorsjo/llvm-mingw/issues/371.
This only provides the main binary llvm-cxxfilt; it doesn't
provide the binutils-style frontends named [<triple>-]c++filt.
If we were to provide such frontends, we'd need to make them
default to --strip-underscore for i686 triple prefixes, and
for the prefixless case when the default architecture is i686.
This allows simplification, this functionality was added long
ago to CMake.
Further motivation is to be able to re-direct the installation,
make/ninja install allow this by setting DESTDIR but this
generally doesnt work well with window paths (see [1]).
[1] - https://cmake.org/cmake/help/latest/envvar/DESTDIR.html#envvar:DESTDIR
Ninja isn't documented as one of the tools provided by the CI runner
images, but it used to be available implicitly installed before
in the windows-2022 images. Since the 20230918.1.0 image update,
it no longer is available out of the box; see
https://github.com/actions/runner-images/issues/8343.
There was a minor issue with the version information in what
was tagged as 17.0.0, so 17.0.1 is the first proper stable
release on the 17.x release branch.
This brings in a rather large update of the D3D12 header
(d3d12.idl/d3d12.h), which should now be mostly complete and up
to date with the current versions from Microsoft.
Disable Python, to make the LLDB executables more portable,
so they don't rely on whatever version might have been installed on
the GitHub Actions runner.
Relevant changes since 16.0.6 are:
- Improve Address Sanitizer on i686 mingw
- Improve handling of X86 Intel assembly syntax
- Fix using std::wcout/wcin/wcerr with streams configured in wide mode
- Improve handling of the .arch and .arch_extension assembly directives
on aarch64
- Support the --temp-prefix (ignored) and --no-leading-underscore
options in llvm-dlltool
- Make lld warn about too narrow pseudo relocations, simplifying finding
issues that otherwise only show up at runtime
- Improved the tests, making compiler-rt, libcxxabi and libunwind tests
pass in mingw configurations
Versions 4.3 and above only come packaged as .tar.gz and .tar.lz,
and the lzip decompressor is less commonly readily available, thus
switch back to the .tar.gz format.
Ubuntu 20.04 comes with CMake 3.16, so there's no need to install
a custom version of CMake for now (for LLVM 16.x; LLVM 17 will have
the requirement raised to CMake 3.20 though).
Also drop the workaround for git issues in the old version in
Ubuntu 18.04.
The latest releases that are built on GitHub Actions without
docker are based on Ubuntu 20.04 anyway, so there's less demand
for building this with an older version for the sake of
compatibility of the built binaries. For users using the built
docker image as such, having it based on a newer base distribution
is beneficial.
Martin Storsjö