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
Rollup of 15 pull requests
Successful merges:
- #129329 (Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`)
- #131377 (Add LowerExp and UpperExp implementations to NonZero)
- #132393 (Docs: added brief colon explanation)
- #132437 (coverage: Regression test for inlining into an uninstrumented crate)
- #132499 (unicode_data.rs: show command for generating file)
- #132503 (better test for const HashMap; remove const_hash leftovers)
- #132511 (stabilize const_arguments_as_str)
- #132520 (NFC add known bug nr to test)
- #132522 (make codegen help output more consistent)
- #132523 (Added regression test for generics index out of bounds)
- #132528 (Use `*_opt` typeck results fns to not ICE in fallback suggestion)
- #132537 (PassWrapper: adapt for llvm/llvm-project@5445edb5d)
- #132540 (Do not format generic consts)
- #132543 (add and update some crashtests)
- #132550 (compiler: Continue introducing rustc_abi to the compiler)
r? `@ghost`
`@rustbot` modify labels: rollup
Port most of `--print=target-cpus` to Rust
The logic and formatting needed by `--print=target-cpus` has historically been carried out in C++ code. Originally it used `printf` to write directly to the console, but later it switched over to writing to a `std::ostringstream` and then passing its buffer to a callback function pointer.
This PR replaces that C++ code with a very simple function that writes a list of CPU names to a `&RustString`, with the rest of the logic and formatting being handled by ordinary safe Rust code.
Added regression test for generics index out of bounds
Added a regression test for #117446
This ICE was fixed in Rust 1.75 but a regression test was never added.
This PR adds a UI test with a reduced version of the original bug report that does not rely on external crates.
coverage: Regression test for inlining into an uninstrumented crate
Regression test for #132395, after I was able to figure out a simple way to reproduce it. See also #132436.
In addition to confirming that there is no ICE, this test also demonstrates that the affected code is undercounted, because executing the inlined copy doesn't increment coverage counters.
Add `--print host-tuple` to print host target tuple
People often parse `-vV` output to get to the host tuple, which is annoying to do. It's easier to just get it directly.
I called it "host-tuple" instead of "host" because it's clearer that it's just the target name. I'm open to different names, but I think this one is fine.
a quick GitHub search for `'^host` reveals many instances of people doing the parsing, for example:
68e0ca57cd/README.md (L369)0e38473b0c/main.sh (L96)8a3553b865/README.md (L625)43f3ec3970/do.sh (L35)
needs a compiler FCP. I could also do an MCP but I think just an FCP here makes the most sense.
Tweak E0277 output when a candidate is available
*Follow up to #132086.*
Go from
```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
--> src/main.rs:7:50
|
7 | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
| ^^^^^^^^^^^^^^^^^^^^^^ the trait `chumsky::private::ParserSealed<'_, &str, (), chumsky::extra::Full<EmptyErr, (), ()>>` is not implemented for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>`, which is required by `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>`
|
= help: the trait `chumsky::private::ParserSealed<'_, &'a str, ((), ()), chumsky::extra::Full<EmptyErr, (), ()>>` is implemented for `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>`
= help: for that trait implementation, expected `((), ())`, found `()`
= note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<Filter<Any<&str, ...>, ...>, ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
--> src/main.rs:5:16
|
5 | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
| ^^^^^^^^^^^^^^^^ ^ ---------------------- unsatisfied trait bound introduced here
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
= note: consider using `--verbose` to print the full type name to the console
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-0008f9a4f2023b08.long-type-13239977239800463552.txt'
= note: consider using `--verbose` to print the full type name to the console
```
to
```
error[E0277]: the trait bound `Then<Ignored<chumsky::combinator::Filter<chumsky::primitive::Any<&str, chumsky::extra::Full<EmptyErr, (), ()>>, {closure@src/main.rs:9:17: 9:27}>, char>, chumsky::combinator::Map<impl CSTParser<'a, O>, O, {closure@src/main.rs:11:24: 11:27}>, (), (), chumsky::extra::Full<EmptyErr, (), ()>>: CSTParser<'a>` is not satisfied
--> src/main.rs:7:50
|
7 | fn leaf<'a, O>(parser: impl CSTParser<'a, O>) -> impl CSTParser<'a, ()> {
| ^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
...
11 | ws.then(parser.map(|_| ()))
| --------------------------- return type was inferred to be `Then<Ignored<..., ...>, ..., ..., ..., ...>` here
|
= help: the trait `ParserSealed<'_, &_, (), Full<_, _, _>>` is not implemented for `Then<Ignored<..., ...>, ..., ..., ..., ...>`
but trait `ParserSealed<'_, &'a _, ((), ()), Full<_, _, _>>` is implemented for it
= help: for that trait implementation, expected `((), ())`, found `()`
= note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `Parser<'_, &str, ()>`
note: required for `Then<Ignored<..., ...>, ..., ..., ..., ...>` to implement `CSTParser<'a>`
--> src/main.rs:5:16
|
5 | impl<'a, O, T> CSTParser<'a, O> for T where T: Parser<'a, &'a str, O> {}
| ^^^^^^^^^^^^^^^^ ^ ---------------------- unsatisfied trait bound introduced here
= note: the full name for the type has been written to '/home/gh-estebank/longlong/target/debug/deps/longlong-df9d52be87eada65.long-type-1337037744507305372.txt'
= note: consider using `--verbose` to print the full type name to the console
```
* Remove redundant wording
* Introduce trait diff highlighting logic and use it
* Fix incorrect "long type written to path" logic (can be split off)
* Point at tail expression in more cases in E0277
* Avoid long primary span labels in E0277 by moving them to a `help`
Fix#132013.
There are individual commits that can be their own PR. If the review load is too big, happy to split them off.
rustdoc: skip stability inheritance for some item kinds
For some item kinds it's incorrect to inherit their parent's stability, because they might be accessible without referring to the parent directly -- This PR removes the stability inheritance for these items and reverts their displayed stability to that before https://github.com/rust-lang/rust/pull/130798.
Impl items, both inherent and trait impls, have a stability, but it is ignored when checking for enabled features. However, impl items are automatically unstable if they're nested inside an unstable module -- this caused the children of impl to inherit the instability and lead to https://github.com/rust-lang/rust/issues/132440.
Furthermore, for associated items only the stability of the associated item itself is checked and not that of its parent impl. This is true even for trait impls and we have [relied on this behavior in the standard library in the past](https://doc.rust-lang.org/1.37.0/std/slice/trait.SliceConcatExt.html#tymethod.concat), so these also shouldn't inherit the impl's stability.
I've also removed the stability inheritance for primitives and keywords so that viewing e.g. [the `i32` docs on `core`](https://doc.rust-lang.org/nightly/core/primitive.i32.html) will no longer show "since 1.6.0". Note that we currently don't annotate stability for the keyword docs, but if we start doing so in the future then this is probably more correct.
fixes (after backport) https://github.com/rust-lang/rust/issues/132440
Also treat `impl` definition parent as transparent regarding modules
This PR changes the `non_local_definitions` lint logic to also consider `impl` definition parent as transparent regarding modules.
See tests and explanation in the changes.
``````@rustbot`````` label +L-non_local_definitions
Fixes *(after beta-backport)* #132427
cc ``````@leighmcculloch``````
r? ``````@jieyouxu``````
Add a Few Codegen Tests
Closes#86109Closes#64219
Those issues somehow got fixed over time.
So, this PR adds a couple of codegen tests to ensure we don't regress in the future.
Do not suggest `#[derive(Copy)]` when we wanted a `!Copy` type.
Do not say "`Copy` is not implemented for `T` but `Copy` is".
Do not talk about `Trait` having no implementations when `!Trait` was desired.
```
error[E0277]: the trait bound `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}: Coroutine` is not satisfied
--> $DIR/gen_block_is_coro.rs:6:13
|
LL | fn foo() -> impl Coroutine<Yield = u32, Return = ()> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Coroutine` is not implemented for `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}`
LL | gen { yield 42 }
| ---------------- return type was inferred to be `{gen block@$DIR/gen_block_is_coro.rs:7:5: 7:8}` here
```
The secondary span label is new.
When a trait is not implemented for a type, but there *is* an `impl`
for another type or different trait params, we format the output to
use highlighting in the same way that E0308 does for types.
The logic accounts for 3 cases:
- When both the type and trait in the expected predicate and the candidate are different
- When only the types are different
- When only the trait generic params are different
For each case, we use slightly different formatting and wording.
Rollup of 14 pull requests
Successful merges:
- #131829 (Remove support for `-Zprofile` (gcov-style coverage instrumentation))
- #132369 (style-guide: Only use the new binop heuristic for assignments)
- #132383 (Implement suggestion for never type fallback lints)
- #132413 (update offset_of! docs to reflect the stabilization of nesting)
- #132438 (Remove unncessary option for default rust-analyzer setting)
- #132439 (Add `f16` and `f128` to `invalid_nan_comparison`)
- #132444 (rustdoc: Directly use rustc_abi instead of reexports)
- #132445 (Cleanup attributes around unchecked shifts and unchecked negation in const)
- #132448 (Add missing backtick)
- #132450 (Show actual MIR when MIR building forgot to terminate block)
- #132451 (remove some unnecessary rustc_allow_const_fn_unstable)
- #132455 (make const_alloc_layout feature gate only about functions that are already stable)
- #132456 (Move remaining inline assembly test files into asm directory)
- #132459 (feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr)
r? `@ghost`
`@rustbot` modify labels: rollup
On some architectures, vector types may have a different ABI depending
on whether the relevant target features are enabled. (The ABI when the
feature is disabled is often not specified, but LLVM implements some
de-facto ABI.)
As discussed in rust-lang/lang-team#235, this turns out to very easily
lead to unsound code.
This commit makes it a post-monomorphization future-incompat warning to
declare or call functions using those vector types in a context in which
the corresponding target features are disabled, if using an ABI for
which the difference is relevant. This ensures that these functions are
always called with a consistent ABI.
See the [nomination comment](https://github.com/rust-lang/rust/pull/127731#issuecomment-2288558187)
for more discussion.
Part of #116558
Move remaining inline assembly test files into asm directory
Before:
```
tests/assembly/asm/*
tests/assembly/asm-comments.rs
tests/codegen/asm-target-clobbers.rs
tests/codegen/asm-goto.rs
tests/codegen/asm-maybe-uninit.rs
tests/codegen/asm-msp430-clobbers.rs
tests/codegen/asm-options.rs
tests/codegen/asm-clobbers.rs
tests/codegen/asm-may_unwind.rs
tests/codegen/asm-arm64ec-clobbers.rs
tests/codegen/asm-powerpc-clobbers.rs
tests/codegen/asm-sanitize-llvm.rs
tests/codegen/asm-s390x-clobbers.rs
tests/codegen/asm-clobber_abi.rs
tests/codegen/asm-multiple-options.rs
tests/codegen/global_asm.rs
tests/codegen/global_asm_include.rs
tests/codegen/global_asm_x2.rs
tests/ui/asm/*
```
After:
```
tests/assembly/asm/*
tests/codegen/asm/*
tests/ui/asm/*
```
I moved the remaining standalone test files into the asm directory, and then either removed the "asm-" suffix or for x86-specific registers tests replaced the "asm-" suffix with the "x86-" suffix.
(Then I noticed that there is no test for clobber_abi for already stabilized aarch64, arm, riscv, and loongarch64 asm... I don't believe there is a problem like https://github.com/rust-lang/rust/pull/131332, but I plan to add tests for them later.)
r? ``@Amanieu``
``@rustbot`` label +A-inline-assembly
Add `f16` and `f128` to `invalid_nan_comparison`
Currently `f32_nan` and `f64_nan` are used to provide the `invalid_nan_comparison` lint. Since we have `f16_nan` and `f128_nan`, hook these up so the new float types get the same lints.
Implement suggestion for never type fallback lints
r? ```@WaffleLapkin```
Just opening this up for vibes; it's not done yet. I'd still like to make this suggestable in a few more cases before merge:
- [x] Try to annotate `_` -> `()`
- [x] Try to annotate local variables if they're un-annotated: `let x = ...` -> `let x: () = ...`
- [x] Try to annotate the self type of a `Trait::method()` -> `<() as Trait>::method()`.
The only other case we may want to suggest is a missing turbofish, like `f()` -> `f::<()>()`. That may be possible, but seems overly annoying.
This partly addresses https://github.com/rust-lang/rust/issues/132358; the other half of fixing that would be to make the error message a bit better, perhaps just special casing the `?` operator 🤔 I don't think I'll do that part.
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
