| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This reverts commit 75ed08972703798888fceff12b3217408ca6a4b5.
|
|
|
|
Delete debuginfo test suite infra for gdb without Rust support and lldb with Rust support
Implements https://github.com/rust-lang/rust/issues/128953
I also deleted all the `min-lldb-version: 310` comments, because the oldest compatible distro I can find is Ubuntu 16.04 which ships lldb 3.8, though of course the package that the Ubuntu maintainers put together for that is broken.
Rocky Linux 8 amusingly ships lldb 17, even though it has a similar glibc and kernel version.
This PR is multiple highly mechanical changes. Some of the commits were created by just running `sed`. You may find it easier to review each commit separately.
|
|
Move ZST ABI handling to `rustc_target`
Currently, target specific handling of ZST function call ABI (specifically passing them indirectly instead of ignoring them) is handled in `rustc_ty_utils`, whereas all other target specific function call ABI handling is located in `rustc_target`. This PR moves the ZST handling to `rustc_target` so that all the target-specific function call ABI handling is in one place. In the process of doing so, this PR fixes #125850 by ensuring that ZST arguments are always correctly ignored in the x86-64 `"sysv64"` ABI; any code which would be affected by this fix would have ICEd before this PR. Tests are also added using `#[rustc_abi(debug)]` to ensure this behaviour does not regress.
Fixes #125850
|
|
|
|
|
|
compiletest: Don't panic on unknown JSON-like output lines
The `json::extract_rendered` function is called for both compiler output and non-compiler output, so it's inappropriate to panic just because a line starting with `{` didn't contain a compiler output message.
It is called from two places: when checking the output of a `ui` test process, and when printing the output of an arbitrary non-passing `ProcRes`. So unfortunately there's currently no easy way to know for sure whether it is seeing compiler output or not. Fortunately, neither call site appears to be relying on this panic; it's just an overzealous internal check.
Fixes #126373.
|
|
The JSON messages parsed by this file are from the _compiler_, not from
libtest.
|
|
This function is called for both compiler and non-compiler output, so if the
line isn't recognized as JSON from the compiler then just print it as-is.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
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```
|
|
|
|
r=jieyouxu
Migrate run make issue 15460
Part of https://github.com/rust-lang/rust/issues/121876.
r? `@jieyouxu`
try-job: x86_64-msvc
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
|
|
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)
|
|
`msvc_lib` binary
|
|
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.
|
|
|
|
passed to recipes
|
|
|
|
handling
|
|
|
|
and env vars
|
|
|
|
|
|
|
|
|
|
calculations
|
|
|
|
|
