| Age | Commit message (Collapse) | Author | Lines |
|---|
|
There's already `min-llvm-version`, and contributors were using
`ignore-llvm-version: 20 - 99` to emulate `max-llvm-major-version: 19`.
|
|
|
|
|
|
AIX: add run-make support
On AIX, we are required explicit link against `c++` and `c++abi` to support running the run-make test suite.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Add `{ignore,needs}-{rustc,std}-debug-assertions` directive support
Add `{ignore,needs}-{rustc,std}-debug-assertions` compiletest directives and retire the old `{ignore,only}-debug` directives. The old `{ignore,only}-debug` directives were ambiguous because you could have std built with debug assertions but rustc not built with debug assertions or vice versa. If we want to support the use case of controlling test run based on if rustc was built with debug assertions, then having `{ignore,only}-debug` will be very confusing.
cc ````@matthiaskrgr````
Closes #123987.
r? bootstrap (or compiler tbh)
|
|
|
|
This commit is the final step in the journey of renaming the historical
`wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various
steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is
summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of
`wasm32-wasip1` has currently been available for 6 months. Users have
already seen warnings on stable for 2 months about usage of
`wasm32-wasi` and stable users have another 2 months of warnings before
the target is removed from stable.
This commit is intended to be the final step in this transition so the
source tree should no longer mention `wasm32-wasi` except in historical
reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
This changes the naming to the new naming, used by `--print
target-tuple`.
It does not change all locations, but many.
|
|
|
|
when requested via `//@ add-core-stubs` directive
`//@ add-core-stubs` will imply `-Cpanic=abort`.
|
|
|
|
|
|
And retire the old `only-debug` directive which was ambiguous and only
for std debug assertions.
|
|
|
|
|
|
fix various linker warnings
separated out from https://github.com/rust-lang/rust/pull/119286; this doesn't have anything user-facing, i just want to land these changes so i can stop rebasing them.
r? `@bjorn3`
|
|
this avoids warnings from macOS ld
|
|
|
|
compiletest: suppress Windows Error Reporting (WER) for `run-make` tests
WER by default will show a *bunch* of error dialogues for missing DLLs on Windows for `run-make` tests. We address that by:
1. Guarding `run-make` test process spawning with `disable_error_reporting`.
2. Fixing `disable_error_reporting` to also add the [`SEM_FAILCRITICALERRORS` flag to `SetErrorMode`][SetErrorMode]. Just `SEM_NOGPFAULTERRORBOX` was not sufficient to suppress error dialogues for e.g. missing DLLs.
Fixes #132092. In particular, refer to that issue for the necessary conditions to observe these dialogues from popping up in the first place.
I was only able to manually test this locally in my "native" Windows msvc environment and it prevents the WER dialogues from popping up, I don't think it's possible to really test this automatically.
[SetErrorMode]: https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode?redirectedfrom=MSDN#parameters
|
|
Don't allow test revisions that conflict with built in cfgs
Fixes #128964
Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅
|
|
|
|
|
|
Compiletest: Custom differ
This adds support for a custom differ for compiletests. It’s purely visual and helps produce cleaner output when UI tests fail.
I’m using an environment variable for now since it’s experimental and I don’t want to drill the cli arguments all the way down. Also did a bit of general cleanup while I was at it.
This is how it looks [with debug info silenced](https://github.com/rust-lang/rust/pull/131182) (#131182)
`COMPILETEST_DIFF_TOOL="/usr/bin/env difft --color always --background light --display side-by-side" ./x test tests/ui/parser`
|
|
|
|
|
|
|
|
|
|
This reduces the need to juggle raw tuples, and opens up the possibility of
moving more parts of directive parsing into `line_directive`.
|
|
|
|
This also removes unused support for `[rev]` in debugger commands, and makes
breakpoint detection slightly more sensible.
|
|
|
|
compiletest: disambiguate html-tidy from rust tidy tool
when i first saw this error message i was very confused, i thought it was talking about `src/tools/tidy`. now it should be much more clear what tool should be installed.
|
|
|
|
|
|
|
|
|
|
The new name makes it clearer that this is a timestamp, and is collected from
input files considered common to all tests.
|
|
|
|
|
|
|
|
Fix most ui tests on emscripten target
To fix the linker errors, we need to set the output extension to `.js` instead of `.wasm`. Setting the output to a `.wasm` file puts Emscripten into standalone mode which is effectively a distinct target. We need to set the runner to be `node` as well.
This fixes most of the ui tests. I fixed 4 additional tests with simple problems:
- `intrinsics/intrinsic-alignment.rs` -- Two `#[cfg]` macros match for Emscripten so we got duplicate definition
- `structs-enums/rec-align-u64.rs` -- same problem
- `issues/issue-12699.rs` -- hangs so I disabled it
- `process/process-sigpipe.rs` -- Not expected to work on Emscripten so I disabled it
Resolves #131666.
There are 7 more failing tests. I'll try to investigate more and see if I can fix them or at least understand why they happen.
- abi/numbers-arithmetic/return-float.rs (problem with [wasm treatment of noncanonical floats](https://webassembly.github.io/spec/core/exec/numerics.html#nan-propagation)?)
- async-await/issue-60709.rs -- linker error related to memcpy. Possible Emscripten bug?
- backtrace/dylib-dep.rs -- Says "Not supported"
- backtrace/line-tables-only.rs -- Says "Not supported"
- no_std/no-std-unwind-binary.rs -- compiler says `error: lang item required, but not found: eh_catch_typeinfo`
- structs-enums/enum-rec/issue-17431-6.rs -- One of the two compiler errors is missing
- test-attrs/test-passed.rs
r?workingjubilee r?jieyouxu
|
|
To fix the linker errors, we need to set the output extension to `.js` instead
of `.wasm`. Setting the output to a `.wasm` file puts Emscripten into standalone
mode which is effectively a distinct target. We need to set the runner to be
`node` as well.
This fixes most of the ui tests. I fixed a few more tests with simple problems:
- `intrinsics/intrinsic-alignment.rs` and `structs-enums/rec-align-u64.rs` --
Two `#[cfg]` macros match for Emscripten so we got a duplicate definition of
`mod m`.
- `issues/issue-12699.rs` -- Seems to hang so I disabled it
- `process/process-sigpipe.rs` -- Not expected to work on Emscripten so I
disabled it
|
|
Fix up-to-date checking for run-make tests
This special case in `output_base_dir` had the unfortunate side-effect of causing all run-make tests to share the same `stamp` file. So as soon as any one of them succeeded, all of the failed tests would be incorrectly considered up-to-date and would no longer run in subsequent test invocations.
Fixes #129971.
r? jieyouxu
|
|
This special case in `output_base_dir` had the unfortunate side-effect of
causing all run-make tests to share the same `stamp` file. So as soon as any
one of them succeeded, all of the failed tests would be considered up-to-date
and would no longer run in subsequent test invocations.
|
|
|
|
Special case error message for a `build-fail` test that failed check build
A `build-fail` test requires that a check build (roughly `--emit=metadata`, no codegen) succeeds but fails later. Previously, if its check build failed, the user will see the error message
```
error: test compilation failed although it shouldn't!
```
which is confusing. Because the test is `build-fail`, we want the test compilation to fail! This error message doesn't account for the difference between a check build and a complete build, so let's special case the error message for a `build-fail` test whose check build failed to instead say
```
error: `build-fail` test is required to pass check build, but check build failed
```
Fixes #130894.
|
|
compiletest: Move debugger setup code out of `lib.rs`
These functions contain a few hundred lines of code for dealing with debuggers (for `debuginfo` tests), and don't really belong in the crate root.
Moving them out to their own module makes `lib.rs` easier to follow.
|
|
Error on trying to use revisions in `run-make` tests
Currently, `run-make` tests do not support revisions.
|
|
|
