Box::default(): do not omit the type of the removed trait object
Within a larger expression, when the type of `Box::new(T::default())` is `Box<dyn Trait>`, the concrete type `T` cannot be omitted in the proposed replacement `Box::<T>::default()`.
Fixes#10381
changelog: [`box_default`]: in case of a trait object do not omit the concrete type name
Within a larger expression, when the type of `Box::new(T::default())` is
`Box<dyn Trait>`, the concrete type `T` cannot be omitted in the
proposed replacement `Box::<T>::default()`.
Only include stable lints in `rustdoc::all` group
Fixes#106289.
Including unstable lints in the lint group produces unintuitive behavior
on stable (see #106289). Meanwhile, if we only included unstable lints
on nightly and not on stable, we could end up with confusing bugs that
were hard to compare across versions of Rust that lacked code changes.
I think that only including stable lints in `rustdoc::all`, no matter
the release channel, is the most intuitive option. Users can then
control unstable lints individually, which is reasonable since they have
to enable the feature gates individually anyway.
r? `@GuillaumeGomez`
Including unstable lints in the lint group produces unintuitive behavior
on stable (see #106289). Meanwhile, if we only included unstable lints
on nightly and not on stable, we could end up with confusing bugs that
were hard to compare across versions of Rust that lacked code changes.
I think that only including stable lints in `rustdoc::all`, no matter
the release channel, is the most intuitive option. Users can then
control unstable lints individually, which is reasonable since they have
to enable the feature gates individually anyway.
Type-directed probing for inherent associated types
When probing for inherent associated types (IATs), equate the Self-type found in the projection with the Self-type of the relevant inherent impl blocks and check if all predicates are satisfied.
Previously, we didn't look at the Self-type or at the bounds and just picked the first inherent impl block containing an associated type with the name we were searching for which is obviously incorrect.
Regarding the implementation, I basically copied what we do during method probing (`assemble_inherent_impl_probe`, `consider_probe`). Unfortunately, I had to duplicate a lot of the diagnostic code found in `rustc_hir_typeck::method::suggest` which we don't have access to in `rustc_hir_analysis`. Not sure if there is a simple way to unify the error handling. Note that in the future, `rustc_hir_analysis::astconv` might not actually be the place where we resolve inherent associated types (see https://github.com/rust-lang/rust/pull/103621#issuecomment-1304309565) but `rustc_hir_typeck` (?) in which case the duplication may naturally just disappear. While inherent associated *constants* are currently resolved during "method" probing, I did not find a straightforward way to incorporate IAT lookup into it as types and values (functions & constants) are two separate entities for which distinct code paths are taken.
Fixes#104251 (incl. https://github.com/rust-lang/rust/issues/104251#issuecomment-1338501171).
Fixes#105305.
Fixes#107468.
`@rustbot` label T-types F-inherent_associated_types
r? types
Make codegen choose whether to emit overflow checks
ConstProp and DataflowConstProp currently have a specific code path not to propagate constants when they overflow. This is meant to have the correct behaviour when inlining from a crate with overflow checks (like `core`) into a crate compiled without.
This PR shifts the behaviour change to the `Assert(Overflow*)` MIR terminators: if the crate is compiled without overflow checks, just skip emitting the assertions. This is already what happens with `OverflowNeg`.
This allows ConstProp and DataflowConstProp to transform `CheckedBinaryOp(Add, u8::MAX, 1)` into `const (0, true)`, and let codegen ignore the `true`.
The interpreter is modified to conform to this behaviour.
Fixes#35310
