Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.
Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
The target name can be anything with custom target specs. Matching on
fields inside the target spec is much more robust than matching on the
target name.
Operations like is_aligned would return actively wrong results at compile-time,
i.e. calling it on the same pointer at compiletime and runtime could yield
different results. That's no good.
Instead of having hacks to make align_offset kind-of work in const-eval, just
use const_eval_select in the few places where it makes sense, which also ensures
those places are all aware they need to make sure the fallback behavior is
consistent.
This change updates the documentation for `NonZero` integer types to
explicitly reference the underlying integer type each `NonZero` variant
wraps, instead of using a general "integer" term.
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.
compiler: Continue introducing rustc_abi to the compiler
Some crates have not heard of rustc_abi before, so arrange introductions.
Encourage some crates to go further and leave rustc_target behind: it was no good for them.
Do not format generic consts
We introduced **nightly support** for generic const items in #113522, but formatting of consts was not modified. Making them format *correctly* is hard, so let's just bail formatting them so we don't accidentally strip their generics and where clauses. This is essentially no-op formatting for generic const items.
r? `````@calebcartwright````` or `````@ytmimi`````
PassWrapper: adapt for llvm/llvm-project@5445edb5d
As with ab5583ed1e, we had been explicitly passing defaults whose type have changed. Rather than do an ifdef, we simply rely on the defaults.
````@rustbot```` label: +llvm-main
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.
make codegen help output more consistent
The output of `rustc -C help` generally has one option per line. There was one exception because of a (presumably) forgotten line continuation escape.
better test for const HashMap; remove const_hash leftovers
The existing `const_with_hasher` test is kind of silly since the HashMap it constructs can never contain any elements. So this adjusts the test to construct a usable HashMap, which is a bit non-trivial since the default hash builder cannot be built in `const`. `BuildHasherDefault::new()` helps but is unstable (https://github.com/rust-lang/rust/issues/123197), so we also have a test that does not involve that type.
The second commit removes the last remnants of https://github.com/rust-lang/rust/issues/104061, since they aren't actually useful -- without const traits, you can't do any hashing in `const`.
Cc ``@rust-lang/libs-api`` ``@rust-lang/wg-const-eval``
Closes#104061
Related to https://github.com/rust-lang/rust/issues/102575
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 LowerExp and UpperExp implementations to NonZero
Adds `LowerExp` and `UpperExp` trait implementations to `NonZero`, as discussed in rust-lang/libs-team#458.
I had to modify the macro to mark the new impls with a different rust version. Let me know if this is the right way to do it (first timer here!)
Implement `From<&mut {slice}>` for `Box/Rc/Arc<{slice}>`
ACP: https://github.com/rust-lang/libs-team/issues/424
New API:
```rust
impl<T: Clone> From<&mut [T]> for Box<[T]>
impl From<&mut str> for Box<str>
impl From<&mut CStr> for Box<CStr>
impl From<&mut OsStr> for Box<OsStr>
impl From<&mut Path> for Box<Path>
impl<T: Clone> From<&mut [T]> for Rc<[T]>
impl From<&mut str> for Rc<str>
impl From<&mut CStr> for Rc<CStr>
impl From<&mut OsStr> for Rc<OsStr>
impl From<&mut Path> for Rc<Path>
impl<T: Clone> From<&mut [T]> for Arc<[T]>
impl From<&mut str> for Arc<str>
impl From<&mut CStr> for Arc<CStr>
impl From<&mut OsStr> for Arc<OsStr>
impl From<&mut Path> for Arc<Path>
```
Since they are trait implementations, I think these are insta-stable.
As mentioned in https://github.com/rust-lang/libs-team/issues/424#issuecomment-2299415749, a crater run might be needed.
PassWrapper: adapt for llvm/llvm-project@b01e2a8b56
A boolean turned into an enum. None matches the old behavior of false, so we pass that.
`@rustbot` label: +llvm-main
Subtree sync for rustc_codegen_cranelift
The highlight this time is an update to Cranelift 0.113,
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
get rid of a whole bunch of unnecessary rustc_const_unstable attributes
In general, when a `const fn` is still unstable, it doesn't need a `#[rustc_const_unstable]` attribute. The only exception is functions that internally use things that can't be used in stable const fn yet.
So this gets rid of a whole bunch of `#[rustc_const_unstable]` in libcore.
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.
