Tweak fast path trait handling
(1.) Make it more sound by considering polarity (lol)
(2.) Make it more general, by considering higher-ranked size/copy/clone
(2.) Make it less observable, by only doing copy/clone fast path if there are no regions involved
r? lcnr
add additional `TypeFlags` fast paths
Some crates, e.g. `diesel`, have items with a lot of where-clauses (more than 150). In these cases checking the `TypeFlags` of the whole `param_env` can be very beneficial.
This adds `fn fold_clauses` to mirror the existing `fn visit_clauses` and then uses this in folders which fold `ParamEnv`s.
Split out from rust-lang/rust#141451, depends on rust-lang/rust#141442.
r? `@compiler-errors`
Don't rerun goals if none of their vars have changed
r? `@ghost`
Alternative to rust-lang/rust#141488. I'm pretty sure that we don't need to re-run the goal at all if the inputs don't change... 🤔
Rollup of 7 pull requests
Successful merges:
- #135562 (Add ignore value suggestion in closure body)
- #139635 (Finalize repeat expr inference behaviour with inferred repeat counts)
- #139668 (Handle regions equivalent to 'static in non_local_bounds)
- #140218 (HIR ty lowering: Clean up & refactor the lowering of type-relative paths)
- #140435 (use uX::from instead of _ as uX in non - const contexts)
- #141130 (rustc_on_unimplemented cleanups)
- #141286 (Querify `coroutine_hidden_types`)
Failed merges:
- #140247 (Don't build `ParamEnv` and do trait solving in `ItemCtxt`s when lowering IATs)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix `FnOnce` impl for `AsyncFn`/`AsyncFnMut` self-borrowing closures in new solver
This only affects closures that are "`AsyncFn`/`AsyncFnMut`" in their calling capability that are being called with the `FnOnce` trait.
fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/217
r? lcnr
Querify `coroutine_hidden_types`
This is necessary if we ever want to add implied bounds that would be used for higher-ranked coroutine auto trait goals (e.g. future implements `Send`).
Modest perf regression in `hyper` full build which (afaict?) is the only async stress test, so definitely worth it IMO.
r? oli-obk
Fast path for processing some obligations in the new solver
Fast path applies to:
- Dyn compatibility predicates
- Region and type outlives predicates
- Trivially sized predicates
detect additional uses of opaques after writeback
Based on #140607. It's a lot harder to encounter in practice than I though 😅😁 I've still added it with the expectation that somebody will encounter it at some point.
Also modifies the `EvalCtxt` to use the same impl to detect newly added opaque types.
r? ``@compiler-errors``
only return nested goals for `Certainty::Yes`
Ambiguous `NormalizesTo` goals can otherwise repeatedly add the same nested goals to the parent.
r? ```@compiler-errors```
Do not compute type_of for impl item if impl where clauses are unsatisfied
Consider the following code:
```rust
trait Foo {
fn call(self) -> impl Send;
}
trait Nested {}
impl<T> Foo for T
where
T: Nested,
{
fn call(self) -> impl Sized {
NotSatisfied.call()
}
}
struct NotSatisfied;
impl Foo for NotSatisfied {
fn call(self) -> impl Sized {
todo!()
}
}
```
In `impl Foo for NotSatisfied`, we need to prove that the RPITIT is well formed. This requires proving the item bound `<NotSatisfied as Foo>::RPITIT: Send`. Normalizing `<NotSatisfied as Foo>::RPITIT: Send` assembles two impl candidates, via the `NotSatisfied` impl and the blanket `T` impl. We end up computing the `type_of` for the blanket impl even if `NotSatisfied: Nested` where clause does not hold.
This type_of query ends up needing to prove that its own `impl Sized` RPIT satisfies `Send`, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type of `NotSatisfied.call()`. That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again!
In the old solver, we don't end up computing the `type_of` an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate:
d7ea436a02/compiler/rustc_trait_selection/src/traits/project.rs (L882)
This PR makes the new solver more consistent with the old solver by adding a call to `try_evaluate_added_goals` after regstering the impl predicates, which causes us to bail before computing the `type_of` for impls if the impl definitely doesn't apply.
r? lcnr
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/185
Rollup of 7 pull requests
Successful merges:
- #140056 (Fix a wrong error message in 2024 edition)
- #140220 (Fix detection of main function if there are expressions around it)
- #140249 (Remove `weak` alias terminology)
- #140316 (Introduce `BoxMarker` to improve pretty-printing correctness)
- #140347 (ci: clean more disk space in codebuild)
- #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job)
- #140379 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove `weak` alias terminology
I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.
It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*.
I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)
r? `@oli-obk`
maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
