Migrate ui tests from legacy compiletest-style directives `//` to `ui_test`-style directives `//@`
## Preface
There's an on-going effort to rewrite parts of or the entirety of compiletest
(<https://github.com/rust-lang/compiler-team/issues/536>). A step towards this involve migrating
ui tests to use the [`ui_test`](https://github.com/oli-obk/ui_test) framework, which involves
changing compiletest directives in `// <directive-name>` style to `ui_test` `//@ <directive-name>`
style (https://github.com/rust-lang/compiler-team/issues/512).
This PR aims to implement the directive-style change from `//` to `//`@`` for ui tests only and
make compiletest only accept `//`@`` directives in the "ui" test suite (only).
## Key Changes
1. All ui test `//` directives are replaced by `//`@`` directives.
2. Only accept `//`@`` directives for "ui" test suite.
3. Errors if a comment could be interpreted as a legacy-style `//` directive.
## Diff Generation
The diff is generated by:
- Collecting directives from ui tests via hacking on compiletest.
- Using a migration tool to replace `//` directives in ui tests with `//`@`.`
### Reproduction Steps
0. Delete the temporary directory `$RUSTC_REPO_PATH/build/x86_64-apple-darwin/test/ui/__directive_lines` and the temporary file `$RUSTC_REPO_PATH/build/x86_64-apple-darwin/test/ui/__directive_lines.txt` (if you ran the collection script before).
1. Use the <https://github.com/jieyouxu/rust/tree/collect-test-directives> collect-test-directives
script, which outputs temporary files recording headers occuring in each ui test.
- You need to checkout this branch: `git checkout collect-test-directives`.
- You might need to rebase on lastest master and ensure there are no conflicts.
- You likely need to run `./x test tests/ui --stage 1 --force-rerun` to generate the temporary
files consistently.
2. Checkout the `migrate-ui-test-directives` branch.
4. Run the migration tool <https://github.com/jieyouxu/compiletest-ui_test-header-migration>.
- You will need to first generate a `migration_config.toml` via `cargo run -- generate-config` under `$CWD`.
- Then, update `manual_directives = ["// should-fail"]` in `migration_config.toml`. This is required because the collection script doesn't deal with some special meta ui tests and there are no other `// should-fail` occurrences.
5. Check that the migration at least does not cause UI test failures if you change compiletest to
accept `//`@`` directives for ui tests only.
- `RUSTC_TEST_FAIL_FAST=1 ./x test tests/ui --stage 1 --bless`
6. Confirm that there is no difference after running the migration tool when you are on the
`migrate-ui-test-directives` branch.
## Next Steps
- [x] ~~Need to implement some kind of warning or tidy script to help contributors catch old-style
`// <directive-name>` directives, while only accepting `ui_test`-style `//@ <directive-name>`
directives.~~ An error is emitted if a comment that could be interpreted as legacy-style test directive is encountered.
- [ ] Need to properly document this change in e.g. rustc-dev-guide (https://github.com/rust-lang/rustc-dev-guide/pull/1885).
- [x] Add a `README.md` to `tests/ui` describing the directive style change.
Support configuring the set of codegen backends to build per host triple
This allows building the compiler itself with one backend while using another backend at runtime. For example this allows compiling rustc to wasm using LLVM, while using Cranelift at runtime to produce actual code. Cranelift can't compile to wasm, but is perfectly capable of running on wasm. LLVM can compile to wasm, but can't run on wasm. [^1]
[^1]: The prototype of this still requires a couple of other patches.
fix: Fix snippets being placed leftwards of where they should be
Snippet bits were being escaped before placing snippets, shifting snippets leftwards. Snippets were also being shifted leftwards on files with CRLF line endings since they were placed done after the Unix -> DOS line ending conversion.
Hoping this fixes all of the little bugs related to snippet rendering 😅
Rollup of 6 pull requests
Successful merges:
- #119928 (suggest `into_iter()` when `Iterator` method called on `impl IntoIterator`)
- #121020 (Avoid an ICE in diagnostics)
- #121111 (For E0038, suggest associated type if available)
- #121137 (Add clippy into the known `cfg` list)
- #121179 (allow mutable references in const values when they point to no memory)
- #121181 (Fix an ICE in the recursion lint)
r? `@ghost`
`@rustbot` modify labels: rollup
internal: Parse (nightly) `const` and `async` trait bounds
Both of these bound modifiers were added recently:
* `const` trait bounds: https://github.com/rust-lang/rust/pull/119099
* `async` trait bounds: https://github.com/rust-lang/rust/pull/120392
The latter will certainly will not do the right thing; namely, `async Fn` needs to be mapped to the `AsyncFn` trait. IDK how to do that, so advice would be appreciated, though perhaps we could land this first so the parser isn't complaining about these bounds?
Fix an ICE in the recursion lint
fixes#121170
I looked into it, and there is no good path towards tainting mir_build (where the ICE happens), but using `try_normalize` in a lint seems generally better anyway
allow mutable references in const values when they point to no memory
Fixes https://github.com/rust-lang/rust/issues/120450
The second commit is just some drive-by test suite cleanup.
r? `@oli-obk`
Add clippy into the known `cfg` list
In clippy, we are removing the `feature = "cargo-clippy"` cfg to replace it with `clippy` in https://github.com/rust-lang/rust-clippy/pull/12292. But for it to work, we need to declare `clippy` as cfg. It makes it more coherent with other existing tools like rustdoc.
cc `@flip1995`
Avoid an ICE in diagnostics
fixes#121004
just a slice usage in diagnostics code. Sadly we can't yet bubble the `ErrorGuaranteed` from wf check to borrowck for these cases, as that causes cycle errors iirc
ci: Update GitHub Actions and Node version
Use newer versions of actions; Node 16 -> 18
Fix several warnings in the actions tab regarding usage of the EOL Node 16
Rename MaybeUninit::write_slice
A step to push #79995 forward.
https://github.com/rust-lang/libs-team/issues/122 also suggested to make them inherent methods, but they can't be — they'd conflict with slice's regular methods.
fix: Don't show type mismatches for `{unknown}` to non-`{unknown}` mismatches
Fixes https://github.com/rust-lang/rust-analyzer/issues/15704
Basically we zip the two types, inspecting their substitutions if the constructors are the same, if we encounter a zip step with an `{unknown}` on one side and a non-`{unknown}` on the other we error out and discard the diagnostic. Otherwise we keep it.
