Print name of env var in `--print=deployment-target`
The deployment target environment variable is OS-specific, and if you're in a place where you're asking `rustc` for the deployment target, you're likely to also wanna know the name of the environment variable. I myself wanted this for some code I'm working on in bootstrap, for example.
Behaviour before this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
deployment_target=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
deployment_target=1.0
```
Behaviour after this PR:
```console
$ rustc --print=deployment-target --target=aarch64-apple-darwin
MACOSX_DEPLOYMENT_TARGET=11.0
$ rustc --print=deployment-target --target=aarch64-apple-visionos
XROS_DEPLOYMENT_TARGET=1.0
```
My _belief_ is that this option is extremely rarely used in general, and a GitHub search for "rustc print deployment-target" seems to confirm this, it revealed only the following actual pieces of code using this:
- https://github.com/PyO3/maturin/blob/b292ef69349f2a56cb8ab1b59fda0be3d3b9f138/src/build_context.rs#L1199-L1220
- https://github.com/rust-lang/cc-rs/blob/daab9244b03e244c4f2511944870d719c443f61f/src/lib.rs#L3422-L3426
`maturin` does `.split('=').last()`, so it will continue to work after this change, but `cc v1.0.84` did `.strip_prefix("deployment_target=")` since [this PR](https://github.com/rust-lang/cc-rs/pull/848), so it would break. That's _probably_ fine though, it was broken in a lot of scenarios anyway, and [got](https://github.com/rust-lang/cc-rs/pull/901) [reverted](https://github.com/rust-lang/cc-rs/pull/943) in `v1.0.85`.
So while this is _technically_ a breaking change, I really doubt that anyone is going to observe it, so it's probably fine.
``@BlackHoleFox`` wdyt?
``@rustbot`` label O-apple
r? compiler
The run-make test suite contains tests which are the most flexible out of all
the rust-lang/rust test suites. run-make
tests can basically contain arbitrary code, and are supported by the
run_make_support library.
Infrastructure
There are two kinds of run-make tests:
The new rmake.rs version: this allows run-make tests to be written in Rust
(with rmake.rs as the main test file).
The legacy Makefile version: this is what run-make tests were written with
before support for rmake.rs was introduced.
The implementation for collecting and building the rmake.rs recipes (or
Makefiles) are in
src/tools/compiletest/src/runtest.rs,
in run_rmake_v2_test and run_rmake_legacy_test.
Rust-based run-make tests: rmake.rs
The setup for the rmake.rs version is a 3-stage process:
First, we build the run_make_support library in bootstrap as a tool lib.
Then, we compile the rmake.rs "recipe" linking the support library and its
dependencies in, and provide a bunch of env vars. We setup a directory
structure within build/<target>/test/run-make/
<test-name>/
rmake.exe # recipe binary
rmake_out/ # sources from test sources copied over
and copy non-rmake.rs input support files over to rmake_out/. The
support library is made available as an extern prelude.
Finally, we run the recipe binary and set rmake_out/ as the working
directory.
Formatting
Note that files under tests/ are not formatted by ./x fmt,
use rustfmt tests/path/to/file.rs to format a specific file if desired.
Matthias Krüger
3ec21070e2