Add tests to ensure MTE tags are preserved across FFI boundaries
Added run-make tests to verify that, between a Rust-C FFI boundary in both directions, any MTE tags included in a pointer are preserved for the following pointer types, as well as any information stored using TBI:
- int
- float
- string
- function
try-job: aarch64-gnu
nested aux-build in tests/rustdoc/ tests
* Fixes bug that prevented using nested aux-build in `tests/rustdoc/` tests. Before, `fn document` and the auxiliary builder disagreed about where to find the nested aux-build source file (`auxiliary/auxiliary/aux.rs` vs `auxiliary/aux.rs`), preventing them from building. Picked the latter in line with other builders in compiletest.
* Adds `//@ doc-flags` header, which forwards flags to rustdoc and not rustc.
* Adds `//@ unique-doc-out-dir` header, which sets the --out-dir for the rustdoc invocation to a unique directory: `<root out dir>/docs/<test name>/doc`
* Changes working directory of the rustdoc invocation to the root out directory (common among all aux-builds). Prior art: exec_compiled_test in runtest.rs
* Adds tests that use nested aux builds and new headers
These changes provide useful capabilities for writing rustdoc tests on their own. They are also needed to test the implementation for the [mergable-rustdoc-cross-crate-info](https://github.com/rust-lang/rfcs/pull/3662) RFC.
try-job: x86_64-msvc
Migrate `symbol-visibility` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Pretty scary!
- The expected number of symbols on each check has been changed slightly to reflect the differences between `llvm_readobj` and `nm`, as I think the former will print hidden symbols once and visible symbols twice, while the latter will only print visible symbols.
- The original test ran the same exact checks on `cdylib` twice, for seemingly no reason. I have removed it.
- This may be possible to optimize some more? `llvm_readobj` could get called only once for each library type, and the regex could avoid being created repeatedly. I am not sure if these kinds of considerations are important for a `run-make` test.
Demands a Windows try-job.
try-job: x86_64-mingw
allow overwriting the output of `rustc --version`
Our wonderful bisection folk [have to work around](https://github.com/rust-lang/rust/issues/123276#issuecomment-2075001510) crates that do incomplete nightly/feature detection, as otherwise the bisection just points to where the feature detection breaks, and not to the actual breakage they are looking for.
This is also annoying behaviour to nightly users who did not opt-in to those nightly features. Most nightly users want to be in control of the nightly breakage they get, by
* choosing when to update rustc
* choosing when to update dependencies
* choosing which nightly features they are willing to take the breakage for
The reason this breakage occurs is that the build script of some crates run `rustc --version`, and if the version looks like nightly or dev, it will enable nightly features. These nightly features may break in random ways whenever we change something in nightly, so every release of such a crate will only work with a small range of nightly releases. This causes bisection to fail whenever it tries an unsupported nightly, even though that crate is not related to the bisection at all, but is just an unrelated dependency.
This PR (and the policy I want to establish with this FCP) is only for situations like the `version_check`'s `supports_feature` function. It is explicitly not for `autocfg` or similar feature-detection-by-building-rust-code, irrespective of my opinions on it and the similarity of nightly breakage that can occur with such schemes. These cause much less breakage, but should the breakage become an issue, they should get covered by this policy, too.
This PR allows changing the version and release strings reported by `rustc --version` via the `RUSTC_OVERRIDE_VERSION_STRING` env var. The bisection issue is then fixed by https://github.com/rust-lang/cargo-bisect-rustc/pull/335.
I mainly want to establish a compiler team policy:
> We do not consider feature detection on nightly (on stable via compiler version numbering is fine) a valid use case that we need to support, and if it causes problems, we are at liberty to do what we deem best - either actively working to prevent it or to actively ignore it. We may try to work with responsive and cooperative authors, but are not obligated to.
Should they subvert the workarounds that nightly users or cargo-bisect-rustc can use, we should be able to land rustc PRs that target the specific crates that cause issues for us and outright replace their build script's logic to disable nightly detection.
I am not including links to crates, PRs or issues here, as I don't actually care about the specific use cases and don't want to make it trivial to go there and leave comments. This discussion is going to be interesting enough on its own, without branching out.
Allow to pass a full path for `run-make` tests
It's common (at least for me) to pass a full path to a `run-make` test (including the `rmake.rs` file) and to see that it isn't found, which is a bit frustrating.
With these changes, we can now optionally pass the `rmake.rs` (or even `Makefile`) at the end of the path.
cc ```@jieyouxu```
r? ```@Kobzol```
Cleanup compiletest dylib name calculation
Use `std::env::consts::{DLL_PREFIX, DLL_EXTENSION}` for dylib name calculation which is more accurate for the various different platforms, and is more likely to be looked at by target maintainers.
cc ``@bzEq`` (as this impacts how compiletest handles AIX dll extensions)
Cleanup rmake.rs setup in compiletest
While debugging rmake.rs tests I realized that the rmake.rs setup itself in compiletest is very messy and confused. Now that I know some of the bootstrap steps and the rmake.rs tests themselves better, I realized there are cleanups that are possible:
- Rework how `source_root` and `build_root` are calculated. They should now be less fragile then before.
- Shuffle around path calculations to make them more logically grouped and closer to eventual use site(s).
- Cleanup executable extension calculation with `std::env::consts::EXE_EXTENSION`.
- Cleanup various dylib search path handling: renamed variables to better reflect their purpose, minimized mutability scope of said variables.
- Prune useless env vars passed to both `rustc` and recipe binary commands.
- Vastly improve the documentation for the setup of rmake.rs tests, including assumed bootstrap-provided build layouts, rmake.rs test layout, dylib search paths, intended purpose of passed env vars and the `COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0` stage0 sysroot special handling.
This PR is best reviewed commit-by-commit.
Fixes https://github.com/rust-lang/rust/issues/127920.
r? bootstrap (or Kobzol, or Mark, or T-compiler)
try-job: aarch64-apple
try-job: armhf-gnu
try-job: dist-x86_64-linux
try-job: test-various
try-job: x86_64-mingw
try-job: x86_64-msvc
try-job: x86_64-gnu-llvm-18
This is important for other tests that have various things like modes,
revisions and the like. These features are not supported in run-make
tests, so we don't need the double layering.
