mirror of
https://github.com/rust-lang/rust.git
synced 2025-04-15 13:36:49 +00:00
7faef5d5ed
instantiate higher ranked goals in candidate selection again This reverts #119820 as that PR has a significant impact and breaks code which *feels like it should work*. The impact ended up being larger than we expected during the FCP and we've ended up with some ideas for how we can work around this issue in the next solver. This has been discussed in the previous high bandwidth t-types meeting: https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2024-07-09.20high.20bandwidth.20meeting. We'll therefore keep this inconsistency between the two solvers for now and will have to deal with it before stabilizating the use of the new solver outside of coherence: https://github.com/rust-lang/trait-system-refactor-initiative/issues/120. fixes #125194 after a beta-backport. The pattern which is more widely used than expected and feels like it should work, especially without deep knowledge of the type system is ```rust trait Trait<'a> {} impl<'a, T> Trait<'a> for T {} fn trait_bound<T: for<'a> Trait<'a>>() {} // A function with a where-bound which is more restrictive than the impl. fn function1<T: Trait<'static>>() { // stable: ok // with #119820: error as we prefer the where-bound over the impl // with this PR: back to ok trait_bound::<T>(); } ``` r? `@rust-lang/types` |
||
|---|---|---|
| .. | ||
| assembly | ||
| auxiliary | ||
| codegen | ||
| codegen-units | ||
| coverage | ||
| coverage-run-rustdoc | ||
| crashes | ||
| debuginfo | ||
| incremental | ||
| mir-opt | ||
| pretty | ||
| run-make | ||
| run-pass-valgrind | ||
| rustdoc | ||
| rustdoc-gui | ||
| rustdoc-js | ||
| rustdoc-js-std | ||
| rustdoc-json | ||
| rustdoc-ui | ||
| ui | ||
| ui-fulldeps | ||
| COMPILER_TESTS.md | ||