Rollup of 7 pull requests
Successful merges:
- #75036 (Prefer pattern matching over indexing)
- #75378 (Introduce `rustc_lexer::is_ident` and use it in couple of places)
- #75393 (Fully handle "?" shortcut)
- #75403 (Update comment for function)
- #75407 (Requested changes to [*mut T|*const T]::set_ptr_value)
- #75408 (Update MinGW comments in ci.yml)
- #75409 (Fix range term in alloc vec doc)
Failed merges:
r? @ghost
Requested changes to [*mut T|*const T]::set_ptr_value
This is a follow-up to PR #74774 (tracking issue #75091), acting on some change requests made after approval:
- adds `#[must_use]` attribute
- changes type of `val` pointer argument from `()` to `u8`
- adjusts documentation mentioning pointer provenance
This reverts commit 25670749b4.
This commit does not actually fix the problem. It merely removes the name of
the argument from the LLVM output. Even without the name, Rust codegen still
spills the (nameless) variable onto the stack which is the root cause. The root
cause is solved in the next commit.
move Deaggregate pass to post_borrowck_cleanup
Reopen of #71946
Only the second commit is from this PR, the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done
In #70073 MIR pass handling got reorganized, but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass, while conceptually more of a "cleanup" pass (and one that should be run before optimizations), was run in the middle of the optimization chain. Likely this is an accident of history, so I suggest we try and clean that up by making it a proper cleanup pass.
This does change mir-opt output, because deaggregation now runs before const-prop instead of after.
r? @wesleywiser @rust-lang/wg-mir-opt
cc @RalfJung
Add sample fix for E0749
Even though the description is clear but the solution may not be as straightforward.
Adding a suggested fix from documentation side.
r? @GuillaumeGomez
However, this suggestion should be shown in rustc itself for easy fix, the documentation should also reflect on the changes in rustc. Currently,
```
error[E0749]: negative impls cannot have any items
--> test.rs:6:5
|
6 | type Foo = i32; // error!
| ^^^^^^^^^^^^^^^
error: aborting due to previous error
For more information about this error, try `rustc --explain E0749`.
```
rustc should tell the user to remove it.
Tweak conditions for E0026 and E0769
When we have a tuple struct used with struct we don't want to suggest using the (valid) struct syntax with numeric field names. Instead we want to suggest the expected syntax.
Given
```rust
fn main() {
match MyOption::MySome(42) {
MyOption::MySome { x: 42 } => (),
_ => (),
}
}
```
We now emit E0769 "tuple variant `MyOption::MySome` written as struct variant" instead of E0026 "variant `MyOption::MySome` does not have a field named `x`".
move stack size check to const_eval machine
This is consistent with how we enforce the step limit. In particular, we do not want this limit checked for Miri-the-tool.
polymorphize: constrain unevaluated const handling
This PR constrains the support added for handling unevaluated consts in polymorphization (introduced in #75260) by:
- Skipping associated constants as this causes cycle errors.
- Skipping promoted constants when they contain `Self` as this ensures `T` is used in constants of the form `<Self as Foo<T>>`.
Due to an oversight on my part, when landing #75260 and #75255, some tests started failing when polymorphization was enabled that I didn't notice until after landing - this PR fixes the regressions from #75260.
r? @lcnr
Miri: Renamed "undef" to "uninit"
Renamed remaining references to "undef" to "uninit" when referring to Miri.
Impacted directories are:
- `src/librustc_codegen_llvm/consts.rs`
- `src/librustc_middle/mir/interpret/`
- `src/librustc_middle/ty/print/pretty.rs`
- `src/librustc_mir/`
- `src/tools/clippy/clippy_lints/src/consts.rs`
Upon building Miri based on the new changes it was verified that no changes needed to be made with the Miri project.
Related issue #71193
Improve `f32` and `f64` primitive documentation
I noticed that the docs for the primitive floats were fairly short. I first only wanted to add the IEEE specification information (compare [the reference](https://doc.rust-lang.org/reference/types/numeric.html)), but then also added some more beginner-friendly docs. Let me know what you think!
Random doc team assign:
r? @rylev
