Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack
Consolidates the implied bounds computation mode into a single function, which deeply normalizes, and if it's in **compat** mode (for bevy), it extracts outlives bounds from the infcx.
Previously, we were using the implied bounds compat mode in two cases:
1. During WF, if it detects `ParamSet`
2. EVERYWHERE ELSE (lol) -- e.g. borrowck, predicate entailment, etc.
While I think this is fine, and the net effect was just that we emitted fewer diagnostics, it makes me uncomfortable that all crates were using the supposed "compat" code.
Fixes#137767
Simplify `<Postorder as Iterator>::size_hint`
The current version is sometimes malformed (cc #137919); let's see if we can get away with a loose but trivially-correct one.
mgca: Lower all const paths as `ConstArgKind::Path`
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
r? `@BoxyUwU`
When `#![feature(min_generic_const_args)]` is enabled, we now lower all
const paths in generic arg position to `hir::ConstArgKind::Path`. We
then lower assoc const paths to `ty::ConstKind::Unevaluated` since we
can no longer use the anon const expression lowering machinery. In the
process of implementing this, I factored out `hir_ty_lowering` code that
is now shared between lowering assoc types and assoc consts.
This PR also introduces a `#[type_const]` attribute for trait assoc
consts that are allowed as const args. However, we still need to
implement code to check that assoc const definitions satisfy
`#[type_const]` if present (basically is it a const path or a
monomorphic anon const).
This is error-prone. Explicitly write down which cases don't need
anything substituted. Turn the `OpaqueType` case, which currently
seems to be unreachable, into a `bug!`.
A few cleanups after the removal of `cfg(not(parallel))`
I noticed a few small things that are no longer needed after the removal of `cfg(not(parallel))` in #132282.
One of the later changes adjusts several imports, so viewing the changes individually is recommended.
r? SparrowLii (or reroll)
Fix pretty printing of unsafe binders
We used to render `unsafe<> i32` as `i32`, and `unsafe<'a> &'a i32` as `for<'a> &'a i32`.
r? oli-obk
Review with whitespace b/c adding a new argument changes some the wrapping of some function calls.
Optimize empty provenance range checks.
Currently it gets the pointers in the range and checks if the result is empty, but it can be done faster if you combine those two steps.
r? `@oli-obk`
Update `const_conditions` and `explicit_implied_const_bounds` docs
Move documentation to query definitions, and add docs to `explicit_implied_const_bounds`.
r? project-const-traits
Remove `ParamEnv::without_caller_bounds`
This doesn't really do anything that `ParamEnv::empty` doesn't do nowadays as `ParamEnv` *only* stores caller bounds since other information has been moved out into `TypingMode`
r? ```@compiler-errors``` ```@lcnr```
Use `mk_ty_from_kind` a bit less, clean up lifetime handling in borrowck
r? ``@BoxyUwU``
Pulled out of my attempt to turn that `*const dyn Tr + '_` casting into a lint (which failed lmao)
Introduce `feature(generic_const_parameter_types)`
Allows to define const generic parameters whose type depends on other generic parameters, e.g. `Foo<const N: usize, const ARR: [u8; N]>;`
Wasn't going to implement for this for a while until we could implement it with `bad_inference.rs` resolved but apparently the project simd folks would like to be able to use this for some intrinsics and the inference issue isn't really a huge problem there aiui. (cc ``@workingjubilee`` )
Use `Binder<Vec<Ty>>` instead of `Vec<Binder<Ty>>` in both solvers for sized/auto traits/etc.
It's more conceptually justified IMO, especially when binders get implications.
r? lcnr
Clean up TypeckResults::extract_binding_mode
- Remove the `Option` from the result type, as `None` is never returned.
- Document the difference from the `BindingMode` in `PatKind::Binding`.
A cycle was previously coinductive if all steps were coinductive.
Change this to instead considerm cycles to be coinductive if they
step through at least one where-bound of an impl of a coinductive
trait goal.
Rollup of 8 pull requests
Successful merges:
- #136542 ([`compiletest`-related cleanups 4/7] Make the distinction between root build directory vs test suite specific build directory in compiletest less confusing)
- #136579 (Fix UB in ThinVec::flat_map_in_place)
- #136688 (require trait impls to have matching const stabilities as the traits)
- #136846 (Make `AssocOp` more like `ExprKind`)
- #137304 (add `IntoBounds::intersect` and `RangeBounds::is_empty`)
- #137455 (Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`)
- #137480 (Return unexpected termination error instead of panicing in `Thread::join`)
- #137694 (Spruce up `AttributeKind` docs)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't infer attributes of virtual calls based on the function body
Fixes (after backport) #137646.
Since we don't know the exact implementation of the virtual call, it might write to parameters, we can't infer the readonly attribute.
Reuse machinery from `tail_expr_drop_order` for `if_let_rescope`
Namely, it defines its own `extract_component_with_significant_dtor` which is a bit more accurate than `Ty::has_significant_drop`, since it has a hard-coded list of types from the ecosystem which are opted out of the lint.[^a]
Also, since we extract the dtors themselves, adopt the same *label* we use in `tail_expr_drop_order` to point out the destructor impl. This makes it much clear what's actually being dropped, so it should be clearer to know when it's a false positive.
This conflicts with #137444, but I will rebase whichever lands first.
[^a]: Side-note, it's kinda a shame that now there are two functions that presumably do the same thing. But this isn't my circus, nor are these my monkeys.
It mirrors `ExprKind::Binary`, and contains a `BinOpKind`. This makes
`AssocOp` more like `ExprKind`. Note that the variants removed from
`AssocOp` are all named differently to `BinOpToken`, e.g. `Multiply`
instead of `Mul`, so that's an inconsistency removed.
The commit adds `precedence` and `fixity` methods to `BinOpKind`, and
calls them from the corresponding methods in `AssocOp`. This avoids the
need to create an `AssocOp` from a `BinOpKind` in a bunch of places, and
`AssocOp::from_ast_binop` is removed.
`AssocOp::to_ast_binop` is also no longer needed.
Overall things are shorter and nicer.
