| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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`.
|
|
|
|
|
|
compiletest: if a compiler fails, show its output
Before, when working on something like a `rustdoc-js` test, if you made a syntax error in a rust file, you would not get that error output unless you ran with `--verbose`, which would also cause an enormous amount of other output to be printed as well. This can also lead to frustration in new contributors who don't think to run with `--verbose`.
Now, if rustc or rustdoc is run by compiletest and produces an non-zero exit code, its output will be printed.
|
|
|
|
Add more tests for the parallel rustc
At the moment, the parallel frontend test cases are severely lacking. Althought some reported issues have been resolved, they haven't been added into the tests.
This PR arranges the resolved ICE issues and adds tests for them.
Whether it is worthwhile to add a separate test suite for the paralel frontend still requires futher discussion. But we are trying coveraging issues being resolved through capability of the existing UI test suite.
Discussion: [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/233931-t-compiler.2Fmajor-changes/topic/Proposal.20for.20a.20dedicated.20test.20suite.20for.20t.E2.80.A6.20compiler-team.23906)
Related issues:
- rust-lang/rust#120760
- rust-lang/rust#124423 fixed by rust-lang/rust#140358
- rust-lang/rust#127971 fxied by rust-lang/rust#140358
- rust-lang/rust#120601 fixed by rust-lang/rust#127311
cc `@jieyouxu`
|
|
folkertdev:c-variadic-same-program-multiple-abis-arm, r=RalfJung,davidtwco
c-variadic: multiple ABIs in the same program for arm
similar to https://github.com/rust-lang/rust/pull/144379, but for arm, requested in https://github.com/rust-lang/rust/pull/144066.
Quoting https://github.com/rust-lang/reference/issues/1946#issuecomment-3124555690
> `"aapcs"` specifically refers to the soft-float ABI where floating-point values are passed in integer registers.
However for c-variadic functions, `aapcs` behaves the same as `C`:
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#65parameter-passing
> A variadic function is always marshaled as for the base standard.
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#7the-standard-variants
> This section applies only to non-variadic functions. For a variadic function the base standard is always used both for argument passing and result return.
---
I also noticed that rustc currently emit more instructions than clang for c-variadic functions on arm, see https://godbolt.org/z/hMce9rnTh. I'll fix that separately. (edit: https://github.com/rust-lang/rust/pull/144549)
try-job: armhf-gnu
r? `@RalfJung`
|
|
`--default-codegen-backend` and `--override-codegen-backend`
|
