| Age | Commit message (Collapse) | Author | Lines |
|---|
|
compiletest: Make `DirectiveLine` responsible for name/value splitting
- Follow-up to rust-lang/rust#147170.
---
Now that all of the directive-parsing functions have access to a `DirectiveLine`, we can move all of the ad-hoc name/value splitting code into `DirectiveLine` itself, making directive parsing simpler and more consistent.
The first commit is just moving code into a submodule, so the actual changes can be seen in the subsequent commits.
r? jieyouxu
|
|
workingjubilee:you-can-put-your-gcc-in-my-llvm-components, r=Kobzol
Return to needs-llvm-components being info-only
Partially revert a535042e80a38196a58c27a8c95552546affe5dc
Even with non-LLVM codegen backends, we want to allow for annotations that express dependencies to LLVM-specific parts of the test suite. This includes `//@ needs-llvm-components`, which just allows checking that LLVM is built with relevant target support before the test is run. It does not assert the test cannot work with another codegen backend.
|
|
|
|
|
|
|
|
Partially revert a535042e80a38196a58c27a8c95552546affe5dc
Even with non-LLVM codegen backends, we want to allow for annotations
that express dependencies to LLVM-specific parts of the test suite.
This includes `//@ needs-llvm-components`, which just allows checking
that LLVM is built with relevant target support before the test is run.
It does not assert the test cannot work with another codegen backend.
|
|
|
|
Tests should not try to manually enable incremental compilation with
`-Cincremental`, because that typically results in stray directories being
created in the repository root.
Instead, use the `//@ incremental` directive, which instructs compiletest to
handle the details of passing `-Cincremental` with a fresh directory.
|
|
|
|
This isn't actually used for anything, and its presence complicates the
migration to `DirectiveLine`.
|
|
|
|
compiletest: Remove old-output-capture and become a stage0 bootstrap tool
The new compiletest output-capture system became the default in rust-lang/rust#146574, and no problems have been reported since.
This PR therefore removes the old output-capture implementation from compiletest, and adjusts bootstrap to always build and test compiletest as a stage0 bootstrap tool.
In other words, compiletest no longer relies on any unstable features (such as `libtest` or `internal_output_capture`), and is now written entirely in stable Rust!
The compiletest self-tests still need access to an in-tree rustc, in order to obtain information via `rustc --print`, so we interpret `--stage` as indicating the stage of that secondary compiler, but always use the stage0 compiler to build compiletest itself.
r? Kobzol
|
|
|
|
|
|
const-eval: better wording for errors involving maybe-null pointers
Fixes https://github.com/rust-lang/rust/issues/146748
r? ``@oli-obk``
|
|
|
|
test: Use SVG for terminal url test
I came across the test for `-Zterminal-urls` and found its output a bit hard to read. So, I decided to switch it to an SVG test, as I found it easier to differentiate the link and link text.
Note: `anstyle-svg` needed to be upgraded to at least `0.1.8` to support links in SVGs, so I went ahead and upgraded it to the latest version (`0.1.11`).
|
|
|
|
|
|
Do not run ui test if options specific to LLVM are used when another codegen backend is used
Based on errors in https://github.com/rust-lang/rust/pull/146414, some tests with LLVM-specific options are run when another codegen is actually the one used.
This PR ignores these tests in such cases now to prevent this situation.
r? `@kobzol`
|
|
backend is used
|
|
compiletest: Make `./x test --test-args ...` work again
It accidentally broke with https://github.com/rust-lang/rust/pull/146501. The intention of that PR was to keep existing behavior if `--exact` is not used, but it had a bug. This PR fixes that bug.
|
|
compiletest: Enable new-output-capture by default
The new output-capture implementation was added in rust-lang/rust#146119, but was disabled by default and required opt-in.
Since then, I haven't encountered any problems in my own testing/usage, and I haven't heard any problem reports from other contributors who might have opted in.
It's unlikely that more opt-in testing will help, so the next step is to enable new-output-capture by default and see if anyone complains. (Hopefully nobody!)
If needed, the new default can be overridden (for now) by setting environment variable `COMPILETEST_NEW_OUTPUT_CAPTURE=off`. Please file an issue (or let me know) if anyone finds a reason to do this.
r? jieyouxu
|
|
It accidentally broke with a48c8e337d1. The intention of that commit was
to keep existing behavior if `--exact` is not used, but it had a bug.
This commit fixes that bug.
|
|
|
|
This fix only changes the behavior when using `--exact` test filtering,
which was quite broken. Before this fix, the following runs 0 tests:
$ ./x test tests/run-make/crate-loading -- --exact
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 431 filtered out; finished in 24.95µs
With the fix the desired test is run:
$ ./x test tests/run-make/crate-loading -- --exact
running 1 tests
test [run-make] tests/run-make/crate-loading ... ok
Without `--exact` the set of run tests is unchanged. This still runs
"too many" tests
$ ./x test tests/run-make/crate-loading
running 3 tests
test [run-make] tests/run-make/crate-loading-crate-depends-on-itself ... ok
test [run-make] tests/run-make/crate-loading-multiple-candidates ... ok
test [run-make] tests/run-make/crate-loading ... ok
This still runs the one and only right test:
$ ./x test tests/ui/lint/unused/unused-allocation.rs
running 1 tests
test [ui] tests/ui/lint/unused/unused-allocation.rs ... ok
|
|
- `run-make` test suite will now no longer receive a `cargo`.
- NOTE: the user could technically still write
`Command::new("cargo")` which might find *a* cargo from the
environment, but that is not a supported case.
- `run-make-cargo` will receive a built in-tree `cargo`.
|
|
compiletest: Implement an experimental `--new-output-capture` mode
Thanks to the efforts on rust-lang/rust#140192, compiletest no longer has an unstable dependency on libtest, but it still has an unstable dependency on `#![feature(internal_output_capture)]`. That makes building compiletest more complicated than for most other bootstrap tools.
This PR therefore adds opt-in support for an experimental compiletest mode that avoids the use of `internal_output_capture` APIs, and instead uses more mundane means to capture the output of individual test runners.
Each `TestCx` now contains `&dyn ConsoleOut` references for stdout and stderr. All print statements in `compiletests::runtest` have been replaced with `write!` or `writeln!` calls that explicitly write to one of those trait objects. The underlying implementation then forwards to `print!` or `eprint!` (for `--no-capture` or old-output-capture mode), or writes to a separate buffer (in new-output-capture mode).
---
Currently, new-output-capture is disabled by default. It can be explicitly enabled in one of two ways:
- When running `x test`, pass `--new-output-capture=on` as a *compiletest* argument (after `--`).
- E.g. `x test ui -- --new-output-capture=on`.
- The short form is `-Non` or `-Ny`.
- Set environment variable `COMPILETEST_NEW_OUTPUT_CAPTURE=on`.
After some amount of opt-in testing, new-output-capture will become the default (with a temporary opt-out). Eventually, old-output-capture and `#![feature(internal_output_capture)]` will be completely removed from compiletest.
r? jieyouxu
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Make target pointer width in target json an integer
r? Noratrieb
cc `@RalfJung` (https://github.com/rust-lang/rust/pull/142352/files#r2230380120)
try-job: x86_64-rust-for-linux
|
|
compiletest: Reduce the number of `println!` calls that don't have access to `TestCx`
In order to stop using `#![feature(internal_output_capture)]` in compiletest, we need to be able to capture the console output of individual tests run by the executor.
The approach I have planned is to have all test runners print “console” output into a trait object that is passed around as part of `TestCx`, since almost all test-runner code has easy access to that context. So `println!("foo")` will become `writeln!(self.stdout, "foo")`, and so on.
In order to make that viable, we need to avoid unnecessary printing in places that don't have easy access to `TestCx`. To do so, we can either get rid of unnecessary print statements, or rearrange the code to make the context available. This PR uses both approaches.
r? jieyouxu
|
|
This appears to have been leftover debugging code.
If the capture information turns out to have still been useful, we can find a
way to emit it in a way that doesn't interfere with overhauling compiletests's
output capture system.
|
|
The code in this module is always called in the context of running an
individual tests, and sometimes prints output that needs to be captured.
Moving this module into `runtest` will make it easier to find and audit all of
the print statements that need to be updated when overhauling output-capture.
|
|
When working on a new output-capture system, this will make it easier to obtain
a capturing stream from the test context.
|
|
Running `./x --verbose` will still print out the command-line arguments, and
setting `RUST_LOG=compiletest` will now log the full config instead of a
subset.
|
|
Add more to the `[workspace.dependencies]` section in the top-level `Cargo.toml`
Following on from rust-lang/rust#145740.
r? `@Kobzol`
|
|
compiletest: Remove several remnants of the old libtest-based executor
I noticed a few bits of low-hanging cleanup that are possible now that the non-libtest executor is well and truly established.
|
|
|
|
|
|
|
|
|
|
|
|
Inherit TCC in debuginfo tests on macOS
macOS has a system for propagating folder permissions, which LLDB disables when spawning processes, which in turn causes debuginfo tests to spam the user with repeated pop-ups asking for permissions. See the code comment for details, as well as the following video for an example of how this looks in practice:
https://github.com/user-attachments/assets/1e54f5b8-9130-4b59-8e92-1db1e58fb361
I stumbled upon the incantation to fix this (`settings set target.inherit-tcc true`) while investigating slowdowns when spawning newly created binaries due to XprotectService, see [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/build.20scripts.20slow.20on.20macOS.3F).
This would allow me to no longer have a `build.build-dir = "/Users/madsmtm/rust-build"` workaround in my `bootstrap.toml`.
|
|
|
