Previously, it was quite hard to get access to this output because it
was printed to a buffer in memory and then discarded. This output is
already hidden behind libtest's output capturing, we don't need to hide
it twice.
Fixes the run-make test framework to use target-specific library linking
instead of host-based detection. Previously, tests for hexagon targets
failed because the framework used uname() to detect libraries to link,
which returned Linux libraries (-lm -lrt -ldl -lpthread) that don't
exist on all hexagon targets.
- Use target() instead of uname() to detect cross-compilation targets
- Add hexagon-specific library configuration (-lunwind -lclang_rt.builtins-hexagon)
- Maintain backward compatibility for host-native compilation
This enables hexagon tests to compile and link successfully with the
appropriate runtime libraries for the hexagon platform.
This was done in #145740 and #145947. It is causing problems for people
using r-a on anything that uses the rustc-dev rustup package, e.g. Miri,
clippy.
This repository has lots of submodules and subtrees and various
different projects are carved out of pieces of it. It seems like
`[workspace.dependencies]` will just be more trouble than it's worth.
[win][arm64ec] Fix msvc-wholearchive for Arm64EC
`msvc-wholearchive` was failing on Arm64EC Windows as it requires the `/MACHINE:ARM64EC` flag to be passed to the MSVC linker.
This required splitting the `extra_c_flags` function into a new `extra_linker_flags` function as `/MACHINE:ARM64EC` is not a valid argument to be passed to the MSVC Compiler (instead, `/arm64EC` should be used).
This makes it possible to bless the snapshot files used by `diff()` in
newly-created run-make tests, without having to create the files manually
beforehand.
On musl hosts, we already set -Ctarget-feature=-crt-static and
IS_MUSL_HOST=1 in compiletest. However, in order for the run-make tests
to compile fine on musl hosts, we need to propagate this flag in our
rustc invocations to ensure we can generate cdylibs.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
Adjust `run_make_support::symbols` helpers
Massage the `symbols` helpers to fill out {match all, match any} x {substring match, exact match}:
| | Substring match | Exact match |
|-----------|----------------------------------------|-------------------------------|
| Match any | `object_contains_any_symbol_substring` | `object_contains_any_symbol` |
| Match all | `object_contains_all_symbol_substring` | `object_contains_all_symbols` |
As I'd like to use `object_contains_all_symbols` for rust-lang/rust#143669.
As part of this:
- Rename `any_symbol_contains` to `object_contains_any_symbol_substring` for accuracy, as `any_symbol_contains` is actually "contains any matching substring".
- Remove `with_symbol_iter`.
Noticed while working on https://github.com/rust-lang/rust/pull/143669.
r? ``@ChrisDenton`` (or compiler)
Massage the `symbols` helpers to fill out {match all, match any} x
{substring match, exact match}:
| | Substring match | Exact match |
|-----------|----------------------------------------|-------------------------------|
| Match any | `object_contains_any_symbol_substring` | `object_contains_any_symbol` |
| Match all | `object_contains_all_symbol_substring` | `object_contains_all_symbols` |
As part of this, rename `any_symbol_contains` to
`object_contains_any_symbol_substring` for accuracy.
Additionally, `NO_DEBUG_ASSERTIONS` is set by CI that threads through to
the `./configure` script, which is somewhat fragile and "spooky action
at a distance". Instead, use env vars controlled by compiletest, whose
debug assertion info comes from bootstrap.
The main purpose of this is to upgrade `object` and `gimli`, which will
allow us to drop outdated versions once backtrace also updates.
The only semver breakage in `object`'s is in `elf::R_RISCV_GNU_*` and
`pe::IMAGE_WEAK_EXTERN_*` constants, as well as Mach-O dyld, which don't
appear to be used here. `gimli` is similar, there is only minor breakage
related to dyld.
These version upgrades were also done in the library.
`bstr`, `similar`, and `regex` are also upgraded to the latest minor
version here to match what the lockfile already uses. The `regex`
comment about `memchr` version hasn't been relevant to this lockfile
since e95d15a115 ("Pin memchr to 2.5.0 in the library rather than
rustc_ast") and is no longer relevant in the library lockfile either.
Object Changelog: https://github.com/gimli-rs/object/blob/master/CHANGELOG.md#0370
Gimli changelog: https://github.com/gimli-rs/gimli/blob/master/CHANGELOG.md#0320
In rare cases, the test may need access to the underlying
`std::process::Command` (e.g. for non-trivial process spawning).
Co-authored-by: Jesus Checa Hidalgo <jchecahi@redhat.com>
Some run-make tests invoke Cargo via run_make_support::cargo(), but fail to
execute correctly when rustc is built without rpath. In these setups, runtime
loading of rustc’s shared libraries fails unless the appropriate dynamic library
path is set manually.
This commit updates the cargo() wrapper to call set_host_compiler_dylib_path(),
aligning its behavior with the existing rustc() wrapper:
https://github.com/rust-lang/rust/blob/f76c7367c6363d33ddb5a93b5de0d158b2d827f6/src/tools/run-make-support/src/external_deps/rustc.rs#L39
This ensures that Cargo invocations during tests inherit the necessary dylib
paths, avoiding errors related to missing shared libraries in rpath-less builds.
Fixes part of #140738
This was implemented incorrectly during the porting process, where we
relied on std consts. However, `run-make-support` is a host-only
library, which meant that these artifact names were for the *host* and
not the *target*.
The old Makefile-based infrastructure included support for executing
binaries with remote-test-client if configured, but that didn't get
ported to run_make_support as part of the rmake migration.
This PR re-introduces back that support, with the same implementation
(and limitations) of the original Makefile-based support.
Retire the legacy `Makefile`-based `run-make` test infra
The final piece of [porting run-make tests to use Rust #121876](https://github.com/rust-lang/rust/issues/121876).
Closes#121876.
Closes#40713.
Closes#81791 (no longer using `wc`).
Closes#56475 (no longer a problem in current form of that test; we don't ignore the test on `aarch64-unknown-linux-gnu`).
### Summary
This PR removes the legacy `Makefile`-based `run-make` test infra which has served us well over the years. The legacy infra is no longer needed since we ported all of `Makefile`-based `run-make` tests to the new `rmake.rs` infra.
Additionally, this PR:
- Removes `tests/run-make/tools.mk` since no more `Makefile`-based tests remain.
- Updates `tests/run-make/README.md` and rustc-dev-guide docs to remove mention about `Makefile`-based `run-make` tests
- Update test suite requirements in rustc-dev-guide on Windows to no longer need MSYS2 (they should also now run successfully on native Windows MSVC).
- Update `triagebot.toml` to stop backlinking to #121876.
**Thanks to everyone who helped in this effort to modernize the `run-make` test infra and test suite!**
r? bootstrap
Compile run-make-support and run-make tests with the bootstrap compiler
It does not seem necessary to have to recompile run-make-support on changes to the local compiler/stdlib. This PR simplifies the implementation of a few tools, then switches rms to stage0 and also makes the handling of environment variables in run-make tests simpler.
Best reviewed commit-by-commit. I can split it into multiple PRs if you want.
Also tested that `COMPILETEST_FORCE_STAGE0=1 ./x test tests/run-make --stage 0` still works. Incredibly, it looks like it even passes more tests than on `master` 😆
r? ``@jieyouxu``
Jynn Nelson