Make tidy warn on unrecognized directives
This PR makes it so tidy warns on unrecognized directives, as recommended on [the discussion of #130984](https://github.com/rust-lang/rust/issues/130984#issuecomment-2589284620). This is edited from the previous version of this PR, which only warned on "tidy-ignore" and no other tidy directive typos.
Fixes#130984.
``@rustbot`` label A-tidy C-enhancement
This makes tidy warn on the presence of any directives it does not recognize.
There are changes in compiletest because that file used "tidy-alphabet" instead of "tidy-alphabetical".
Rollup of 6 pull requests
Successful merges:
- #129259 (Add inherent versions of MaybeUninit methods for slices)
- #135374 (Suggest typo fix when trait path expression is typo'ed)
- #135377 (Make MIR cleanup for functions with impossible predicates into a real MIR pass)
- #135378 (Remove a bunch of diagnostic stashing that doesn't do anything)
- #135397 (compiletest: add erroneous variant to `string_enum`s conversions error)
- #135398 (add more crash tests)
r? `@ghost`
`@rustbot` modify labels: rollup
This renames variables named `str` to other names, to make sure `str`
always refers to a type.
It's confusing to read code where `str` (or another standard type name)
is used as an identifier. It also produces misleading syntax
highlighting.
deny usage of special FileCheck prefixes as revision names
Adds a check that ensures special FileCheck prefixes are not used as revision names.
Fix#130982
The old FIXME implies that we don't support escaped newlines, but in fact it
was added in the same patch that added support for escaped newlines.
The new FIXME makes it clear that we do currently support this, and that the
FIXME is for doing so in a less ad-hoc way.
Add `--no-capture`/`--nocapture` as bootstrap arguments
I often try `x test ... --nocapture` => 'unknown argument' => `x test ... -- --nocapture`. As we forward several other compiletest flags, let's recognise this one in bootstrap as well.
compiletest: Remove empty 'expected' files when blessing
Fixes#134793Fixes#134196
This also refactors `compare_output` to return an enum; returning a usize was done for convenience but is misleading
compiletest: Support `forbid-output` in UI tests
The `forbid-output` directive is currently only run in incremental tests (although no incremental tests use it). There are some UI tests 'using' it, but it's doing nothing 😄 Let's fix this
Will also PR the dev guide to note this.
dev-guide PR: https://github.com/rust-lang/rustc-dev-guide/pull/2171
test-infra: improve compiletest and run-make-support symlink handling
I was trying to implement #134656 to port `tests/run-make/incr-add-rust-src-component.rs`, but found some blockers related to symlink handling, so in this PR I tried to resolve them by improving symlink handling in compiletest and run-make-support (particularly for native windows msvc environment).
Key changes:
- I needed to copy symlinks (duplicate a symlink pointing to the same file), so I pulled out the copy symlink logic and re-exposed it as `run_make_support::rfs::copy_symlink`. This helper correctly accounts for the Windows symlink-to-file vs symlink-to-dir distinction (hereafter "Windows symlinks") when copying symlinks.
- `recursive_remove`:
- I needed a way to remove symlinks themselves (no symlink traversal). `std::fs::remove_dir_all` handles them, but only if the root path is a directory. So I wrapped `std::fs::remove_dir_all` to also handle when the root path is a non-directory entity (e.g. file or symlink). Again, this properly accounts for Windows symlinks.
- I wanted to use this for both compiletest and run-make-support, so I put the implementation and accompanying tests in `build_helper`.
- In this sense, it's a reland of #129302 with proper test coverage.
- It's a thin wrapper around `std::fs::remove_dir_all` (`remove_dir_all` correctly handles read-only entries on Windows). The helper has additional permission-setting logic for when the root path is a non-dir entry on Windows to handle read-only non-dir entry.
Fixes#126334.
This was fragile as it was based on host target passed to compiletest,
but the user could cross-compile and run test for a different target
(e.g. cross from linux to msvc, but msvc won't be set on the target).
Furthermore, it was also very surprising as normally revision names
(other than `CHECK`) was accepted as FileCheck prefixes.
Use field init shorthand where possible
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
EDIT: this PR also updates `rustfmt.toml` to set
`use_field_init_shorthand = true`.
Field init shorthand allows writing initializers like `tcx: tcx` as
`tcx`. The compiler already uses it extensively. Fix the last few places
where it isn't yet used.
This was confusing because there are three layers of output hiding.
1. libtest shoves all output into a buffer and does not print it unless the test fails or `--nocapture` is passed.
2. compiletest chooses whether to print the output from any given process.
3. run-make-support chooses what output to print.
This modifies 2 and 3.
- compiletest: Don't require both `--verbose` and `--nocapture` to show the output of run-make tests.
- compiletest: Distinguish rustc and rmake stderr by printing the command name (e.g. "--stderr--" to "--rustc stderr--").
- run-make-support: Unconditionally print the needle/haystack being searched. Previously this was only printed on failure.
Before:
```
$ x t tests/run-make/linker-warning --force-rerun -- --nocapture
running 1 tests
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 377 filtered out; finished in 281.64ms
$ x t tests/run-make/linker-warning --force-rerun -v -- --nocapture 2>&1 | wc -l
1004
$ x t tests/run-make/linker-warning --force-rerun -v -- --nocapture | tail -n40
running 1 tests
------stdout------------------------------
------stderr------------------------------
warning: unused import: `std::path::Path`
--> /home/jyn/src/rust2/tests/run-make/linker-warning/rmake.rs:1:5
|
1 | use std::path::Path;
| ^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
warning: unused import: `run_make_support::rfs::remove_file`
--> /home/jyn/src/rust2/tests/run-make/linker-warning/rmake.rs:3:5
|
3 | use run_make_support::rfs::remove_file;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
warning: 2 warnings emitted
------------------------------------------
test [run-make] tests/run-make/linker-warning ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 377 filtered out; finished in 285.89ms
```
After:
```
Testing stage1 compiletest suite=run-make mode=run-make (x86_64-unknown-linux-gnu)
running 1 tests
------rmake stdout------------------------------
------rmake stderr------------------------------
assert_contains_regex:
=== HAYSTACK ===
error: linking with `./fake-linker` failed: exit status: 1
|
= note: LC_ALL="C" PATH="/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin:...:/bin" VSLANG="1033" "./fake-linker" "-m64" "/tmp/rustcYqdAZT/symbols.o" "main.main.d17f5fbe6225cf88-cgu.0.rcgu.o" "main.2uoctswmurc6ir5rvoay0p9ke.rcgu.o" "-Wl,--as-needed" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-B/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld" "-fuse-ld=lld" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/test/run-make/linker-warning/rmake_out" "-L" "/home/jyn/src/rust2/build/x86_64-unknown-linux-gnu/stage1/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "main" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "run_make_error"
= note: error: baz
error: aborting due to 1 previous error
=== NEEDLE ===
fake-linker.*run_make_error
assert_not_contains_regex:
=== HAYSTACK ===
=== NEEDLE ===
fake-linker.*run_make_error
------------------------------------------
.
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 377 filtered out; finished in 314.81ms
```
This reverts commit 0585134e70, reversing
changes made to 5530869e0f.
The PR unfortunately only converted the `ln!` instances, meaning that
test output was messed up because stdout/stderr output interleaved when
some `println!` instances were converted to `eprintln!` instances, while
some `println!` instances remain unchanged.
Use `eprintln` instead of `println` in bootstrap/compiletest/tidy
A big unconditional CTRL-F replace to start with to check if there's anything that CI expects to be on stdout
r? `@jieyouxu`
Reducing `target_feature` check-cfg merge conflicts
It was rightfully pointed in https://github.com/rust-lang/rust/pull/133099#discussion_r1862490542 that the expected values for the `target_feature` cfg are regularly updated and unfortunately the check-cfg tests for it are very merge-conflict prone.
This PR aims at drastically reducing the likely-hood of those, by normalizing the "and X more" diagnostic, as well as making the full expected list multi-line instead of being on a single one.
cc `@RalfJung`
r? `@jieyouxu`
Add `needs-target-has-atomic` directive
Before this PR, the test writer has to specify platforms and architectures by hand for targets that have differing atomic width support. `#[cfg(target_has_atomic="...")]` is not quite the same because (1) you may have to specify additional matchers manually which has to be maintained individually, and (2) the `#[cfg]` blocks does not communicate to compiletest that a test would be ignored for a given target.
This PR implements a `//@ needs-target-has-atomic` directive which admits a comma-separated list of required atomic widths that the target must satisfy in order for the test to run.
```
//@ needs-target-has-atomic: 8, 16, ptr
```
See <https://github.com/rust-lang/rust/issues/87377>.
This PR supersedes #133095 and is co-authored by `@kei519,` because it was somewhat subtle, and it turned out easier to implement than to review.
rustc-dev-guide docs PR: https://github.com/rust-lang/rustc-dev-guide/pull/2154
Before this commit, the test writer has to specify platforms and
architectures by hand for targets that have differing atomic width
support. `#[cfg(target_has_atomic)]` is not quite the same because (1)
you may have to specify additional matchers manually which has to be
maintained individually, and (2) the `#[cfg]` blocks does not
communicate to compiletest that a test would be ignored for a given
target.
This commit implements a `//@ needs-target-has-atomic` directive which
admits a comma-separated list of required atomic widths that the target
must satisfy in order for the test to run.
```
//@ needs-target-has-atomic: 8, 16, ptr
```
See <https://github.com/rust-lang/rust/issues/87377>.
Co-authored-by: kei519 <masaki.keigo.q00@kyoto-u.jp>
There was only ever one test which used this flag, and it was removed in https://github.com/rust-lang/rust/pull/132244. I think this is a bad flag that should never have been added; comparing by subset makes the test failures extremely hard to debug. Any test that needs complicated output filtering like this should just use run-make instead.
Note that this does not remove the underlying comparison code, because it's still used if `runner` is set. I don't quite understand what's going on there, but since we still test on other platforms and in CI that the full output is accurate, I think it will be easier to debug than a test that uses compare-by-subset unconditionally.
