Constify `TypeId` ordering impls
Tracking issue: #101871
Adding const ordering to `TypeId` allows rtti crates to optimize some casting scenarios (without transmuting to `u64`). This would also prevent these crates from breaking if the underlying type is changed from `u64` to something different.
Feature gate: `#![feature(const_cmp_type_id)]`
Document wf constraints on control flow in cleanup blocks
Was recently made aware of [this code](a377893da2/compiler/rustc_codegen_ssa/src/mir/analyze.rs (L247-L368)), which has this potential ICE: a377893da2/compiler/rustc_codegen_ssa/src/mir/analyze.rs (L308-L314)
Roughly speaking, the code there is attempting to partition the cleanup blocks into funclets that satisfy a "unique successor" property, and the ICE is set off if that's not possible. This PR documents the well-formedness constraints that MIR must satisfy to avoid setting off that ICE.
The constraints documented are slightly stronger than the cases in which the ICE would have been set off in that code. This is necessary though, since whether or not that ICE gets set off can depend on iteration order in some graphs.
This sort of constraint is kind of ugly, but I don't know a better alternative at the moment. It's worth knowing that two important optimizations are still correct:
- Removing edges in the cfg: Fewer edges => fewer paths => stronger dominance relations => more contractions, and more contractions can't turn a forest into not-a-forest.
- Contracting an edge u -> v when u only has one successor and v only has one predecessor: u already dominated v, so this contraction was going to happen anyway.
There is definitely a MIR opt somewhere that can run afoul of this, but I don't know where it is. `@saethlin` was able to set it off though, so maybe he'll be able to shed some light on it.
r? `@RalfJung` I suppose, and cc `@tmiasko` who might have insight/opinions on this
fix: don't emit `E0711` if `staged_api` not enabled
Fixes#106589
Simple fix, added UI test.
As an aside, it seems a lot of features are susceptible to this, `E0711` stands out to me because it's perma-unstable and we are effectively exposing an implementation detail.
Previously, it was only put on scalars with range validity invariants
like bool, was uninit was obviously invalid for those.
Since then, we have normatively declared all uninit primitives to be
undefined behavior and can therefore put `noundef` on them.
The remaining concern was the `mem::uninitialized` function, which cause
quite a lot of UB in the older parts of the ecosystem. This function now
doesn't return uninit values anymore, making users of it safe from this
change.
The only real sources of UB where people could encounter uninit
primitives are `MaybeUninit::uninit().assume_init()`, which has always
be clear in the docs about being UB and from heap allocations (like
reading from the spare capacity of a vec. This is hopefully rare enough
to not break anything.
Document `EarlyBinder::subst_identity` and `skip_binder`
Finishing implementing #105779 will change several commonly used queries to return `EarlyBinder` by default. This PR adds documentation for two of the methods used to access data inside the `EarlyBinder`. I tried to summarize some of the [discussion from the issue](https://github.com/rust-lang/rust/issues/105779#issuecomment-1375512647) in writing this.
r? `@lcnr`
rustdoc: remove redundant item kind class from `.item-decl > pre`
This class originated in the very first commit of `rustdoc_ng`, and was used to add a color border around the item decl based on its kind.
4fd061c426/src/rustdoc_ng/html/static/main.css (L102-L106)
The item decl no longer has a border, and there aren't any kind-specific styles in modern rustdoc's rendering of this UI item.
Most of this PR is updating test cases so that they use `item-decl` to find the `<pre>` tag instead of relying on the fact that the class name had `rust {kind}` in it while other `<pre>` tags only had class `rust`.
Unify `Opaque`/`Projection` handling in region outlives code
They share basically identical paths in most places which are even easier to unify now that they're both `ty::Alias`
r? types
make error emitted on `impl &Trait` nicer
Fixes#106694
Turned out to be simpler than I thought, also added UI test.
Before: ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9bda53271ef3a8886793cf427b8cea91))
```text
error: expected one of `:`, ``@`,` or `|`, found `)`
--> src/main.rs:2:22
|
2 | fn foo(_: impl &Trait) {}
| ^ expected one of `:`, ``@`,` or `|`
|
= note: anonymous parameters are removed in the 2018 edition (see RFC 1685)
help: if this is a parameter name, give it a type
|
2 | fn foo(_: impl Trait: &TypeName) {}
| ~~~~~~~~~~~~~~~~
help: if this is a type, explicitly ignore the parameter name
|
2 | fn foo(_: impl _: &Trait) {}
| ++
error: expected one of `!`, `(`, `)`, `,`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^ expected one of 9 possible tokens
| |
| help: missing `,`
error: expected one of `!`, `(`, `,`, `=`, `>`, `?`, `for`, `~`, lifetime, or path, found `&`
--> src/main.rs:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| ^ expected one of 10 possible tokens
```
After:
```text
error: expected a trait, found type
--> <anon>:2:16
|
2 | fn foo(_: impl &Trait) {}
| -^^^^^
| |
| help: consider removing the indirection
error: expected a trait, found type
--> <anon>:3:11
|
3 | fn bar<T: &Trait>(_: T) {}
| -^^^^^
| |
| help: consider removing the indirection
```
suggestion for attempted integer identifier in patterns
Fixes#106552
Implemented a suggestion on `E0005` that occurs when no bindings are present and the pattern is a literal integer.
gdb et al. expect to find the dwp file at <binary>.dwp, even if <binary> already
has an extension (e.g. libfoo.so's dwp is expected to be at libfoo.so.dwp).
