| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
blessed new test
|
|
Add `ConstParamTy` trait
This is a bit sketch, but idk.
r? `@BoxyUwU`
Yet to be done:
- [x] ~~Figure out if it's okay to implement `StructuralEq` for primitives / possibly remove their special casing~~ (it should be okay, but maybe not in this PR...)
- [ ] Maybe refactor the code a little bit
- [x] Use a macro to make impls a bit nicer
Future work:
- [ ] Actually™ use the trait when checking if a `const` generic type is allowed
- [ ] _Really_ refactor the surrounding code
- [ ] Refactor `marker.rs` into multiple modules for each "theme" of markers
|
|
r=Mark-Simulacrum
Update tests for libtest `--format json`
This PR makes the test work on beta and stable, and adds a test ensuring the option is not available on beta and stable. Backported these commits from https://github.com/rust-lang/rust/pull/110414.
|
|
|
|
compiletest: add bpf-linker assembly support
|
|
|
|
|
|
|
|
|
|
|
|
Add compare-output-lines-by-subset flag to compiletest
For [ferrocene](github.com/ferrocene/) we have some compiletests that check the output of the cli arguments to the compiler, including printing things like the target list (`--print target-list`). Unfortunately those tend to change quite often so when we sync we end up with some outputs we have to re-bless constantly, even though the exact output doesn't really matter.
We added a new compiletest flag to aid writing these kinds of tests: `compare-output-lines-by-subset`. It checks whether the lines of the expected output are a subset (or equal) to the lines of the actual output. If the expected output is empty it will fail unless the actual output is also empty. We opened this PR hoping the flag might be helpful for other tests in the future (especially if CLI-related tests are added in the future in the rust-lang/rust repo itself).
|
|
|
|
|
|
|
|
Support `x test --stage 1 ui-fulldeps`
`@Nilstrieb` had an excellent idea the other day: the same way that rustdoc is able to load `rustc_driver` from the sysroot, ui-fulldeps tests should also be able to load it from the sysroot. That allows us to run fulldeps tests with stage1, without having to fully rebuild the compiler twice. It does unfortunately have the downside that we're building the tests with the *bootstrap* compiler, not the in-tree sources, but since most of the fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of the running compile to match the ABI of the compiler linked with `rustc_driver`. As a result they can't be supported in stage 1 and have to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage 2 build to load rustc_driver, it's primarily testing the error message that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That allows running `hash-stable-is-unstable` in stage1, since it now suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the correct version of std.
- Move a few lint tests from ui-fulldeps to ui
These had an `aux-build:lint-group-plugin-test.rs` that they never actually loaded with `feature(plugin)` nor tested. I removed the unused aux-build and they pass fine with stage 1.
Fixes https://github.com/rust-lang/rust/issues/75905.
|
|
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
|
|
This header can be used for tests which check the output of `--version --verbose` commands.
|
|
[compiletest] Add more test ignore reasons, `needs-` validation, and improved error messages
This PR makes more improvements to the way compiletest ignoring headers are handled, following up on #108905:
* Human-readable ignore reasons have been added for the remaining ignore causes (`needs-*` directives, `*llvm*` directives, and debugger version directives). All ignored tests should now have a human-readable reason.
* The code handling `needs-*` directives has been refactored, and now invalid `needs-*` directive emit errors like `ignore-*` and `only-*`.
* All errors are now displayed at startup (with line numbers) rather than just the first error of the first file.
This PR is best reviewed commit-by-commit.
r? `@ehuss`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pass host linker to compiletest.
Tests marked `// force-host` were using the default linker, even if a custom linker was configured in config.toml.
This change adds a new flag, --host-linker, to compiletest, and renames --linker to --target-linker.
|
|
compiletest: Use remap-path-prefix only in CI
This makes jump-to-definition work in most IDEs, as well as being easier to understand for contributors.
Fixes https://github.com/rust-lang/rust/issues/109725. cc `@TimNN`
|
|
compiletest: Give a better error message if `node` isn't installed
|
|
AIX uses gmake for GNU style Makefile
AIX's `make` is SystemV style, should use `gmake` for GNU style Makefile.
|
|
This makes jump-to-definition work in most IDEs, as well as being easier
to understand for contributors.
|
|
|
|
Tests marked `// force-host` were using the default linker, even if a
custom linker was configured in config.toml.
This change adds a new flag, --host-linker, to compiletest, and renames
--linker to --target-linker.
|
|
add `dont_check_failure_status` option in the compiler test
Sometimes the compiler triggers one ice while processing another ice. This will cause a recursive panic and go to [`sys::abort_internal()`](https://github.com/rust-lang/rust/blob/master/library/std/src/panicking.rs#L675), which generates an unfixed exit code. So I think we need an option to allow these use cases to generate different exit codes
Updates #75760
cc #95134
For example, when set `parallel_compiler = true`, issue-95134 will ice in `report_ice` since it try to print the query stack. Below is the brief error message:
```
failures:
---- [ui] tests\ui\recursion\issue-95134.rs stdout ----
error: Error: expected failure status (Some(101)) but received status Some(-1073740791).
status: exit code: 0xc0000409
command: PATH="D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage1\bin;C:\Program Files (x86)\Windows Kits\10\bin\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX64\x64;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0-bootstrap-tools\x86_64-pc-windows-msvc\release\deps;D:\rust-backup\parallel_rust\rust-para\build\x86_64-pc-windows-msvc\stage0\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\bin;C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.4\libnvvp;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\TortoiseGit\bin;C:\Program Files\CMake\bin;C:\Program Files (x86)\GnuWin32\bin;C:\Program Files\Git\cmd;C:\Program Files\NVIDIA Corporation\Nsight Compute 2021.2.1\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\HuaweiOpensource\anaconda3;C:\Users\HuaweiOpensource\anaconda3\Scripts;C:\Users\HuaweiOpensource\anaconda3\Library\bin;C:\Users\HuaweiOpensource\anaconda3\Library\mingw-w64;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\GnuWin32\bin;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\Scripts\;C:\Users\HuaweiOpensource\AppData\Local\Programs\Python\Python38\;C:\Users\HuaweiOpensource\.cargo\bin;C:\Users\HuaweiOpensource\.cargo\bin;D:\Program Files\JetBrains\CLion 2022.1.3\bin;;D:\Program Files\JetBrains\PyCharm Community Edition 2020.3\bin;;D:\Program Files\OpenSSL-Win64\bin;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit;C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64;" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\stage1\\bin\\rustc.exe" "D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui\\recursion\\issue-95134.rs" "-Zthreads=1" "--target=x86_64-pc-windows-msvc" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Zdeduplicate-diagnostics=no" "-Cstrip=debuginfo" "--remap-path-prefix=D:\\rust-backup\\parallel_rust\\rust-para\\tests\\ui=fake-test-src-base" "-C" "prefer-dynamic" "--out-dir" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134" "-A" "unused" "-Crpath" "-Cdebuginfo=0" "-Lnative=D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\native\\rust-test-helpers" "-L" "D:\\rust-backup\\parallel_rust\\rust-para\\build\\x86_64-pc-windows-msvc\\test\\ui\\recursion\\issue-95134\\auxiliary" "-Copt-level=0"
stdout: none
--- stderr -------------------------------
thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0', C:\Users\HuaweiOpensource\.cargo\registry\src\github.com-1ecc6299db9ec823\ena-0.14.2\src\snapshot_vec.rs:199:10
stack backtrace:
0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54
1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0
2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b
3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26
4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143
......
178: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>>
179: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629
180: 0x7ffcb0b37614 - BaseThreadInitThunk
181: 0x7ffcb18c26a1 - RtlUserThreadStart
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc
note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0
query stack during panic:
thread 'rustc' panicked at 'type variables should not be hashed: _#0t', D:\rust-backup\parallel_rust\rust-para\compiler\rustc_type_ir\src\lib.rs:718:17
stack backtrace:
0: 0x7ffc3e90bc05 - std::backtrace_rs::backtrace::trace_unsynchronized::hfabb14c555fa1e54
1: 0x7ffc3e900799 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h88786f2c1c37cad0
2: 0x7ffc3e95143b - core::fmt::write::hef4555c5285e005b
3: 0x7ffc3e8ef2aa - std::io::Write::write_fmt::h9ea304efc4781c26
4: 0x7ffc3e90059b - std::sys_common::backtrace::print::h7b33cd350eefb143
5: 0x7ffc3e91c109 - std::panicking::default_hook::h12f01c5f2b8959c6
......
197: 0x7ffc27d6a3f2 - <&mut serde_json[7222a1897944c7c8]::ser::Serializer<&mut alloc[6a6f6c0f0cd9fa15]::vec::Vec<u8>, serde_json[7222a1897944c7c8]::ser::PrettyFormatter> as serde[d3e6684f4f38fcf7]::ser::Serializer>::collect_seq::<&alloc[6a6f6c0f0cd9fa15]::vec::Vec<serde_json[7222a1897944c7c8]::value::Value>>
198: 0x7ffc3e8ed9ec - std::sys::windows::thread::Thread::new::thread_start::h5be4f069fac1a629
199: 0x7ffcb0b37614 - BaseThreadInitThunk
200: 0x7ffcb18c26a1 - RtlUserThreadStart
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
note: rustc 1.70.0-dev running on x86_64-pc-windows-msvc
note: compiler flags: -Z threads=1 -C codegen-units=1 -Z ui-testing -Z simulate-remapped-rust-src-base=/rustc/FAKE_PREFIX -Z translate-remapped-path-to-local-path=no -Z deduplicate-diagnostics=no -C strip=debuginfo -C prefer-dynamic -C rpath -C debuginfo=0 -C opt-level=0
query stack during panic:
thread panicked while processing panic. aborting.
------------------------------------------
```
|
|
|
|
Validate `ignore` and `only` compiletest directive, and add human-readable ignore reasons
This PR adds strict validation for the `ignore` and `only` compiletest directives, failing if an unknown value is provided to them. Doing so uncovered 79 tests in `tests/ui` that had invalid directives, so this PR also fixes them.
Finally, this PR adds human-readable ignore reasons when tests are ignored due to `ignore` or `only` directives, like *"only executed when the architecture is aarch64"* or *"ignored when the operative system is windows"*. This was the original reason why I started working on this PR and #108659, as we need both of them for Ferrocene.
The PR is a draft because the code is extremely inefficient: it calls `rustc --print=cfg --target $target` for every rustc target (to gather the list of allowed ignore values), which on my system takes between 4s and 5s, and performs a lot of allocations of constant values. I'll fix both of them in the coming days.
r? `@ehuss`
|
|
This is better than the old impl of target.ends_with("windows-gnu"),
because it also catches things like windows-gnullvm
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
