Unnamed repository; edit this file 'description' to name the repository.
Rollup merge of #153847 - traviscross:TC/fix-typeoutlives-missing-param-check, r=lcnr
Fix marker trait winnowing depending on impl order Story: I was looking through this code for an unrelated reason and happened to notice the duplicate condition. That seemed obviously wrong, especially in light of the comment, so I worked backward to what it affected, wrote a test that failed, and then found that the test matched an existing `known-bug` test, which pointed me to rust-lang/rust#109481. --- The `TypeOutlives` handler in `evaluate_predicate_recursively` means to check whether a type in a `T: 'a` predicate has free regions, bound regions, non-region inference variables, or non-region generic parameters -- and if so, to return `EvaluatedToOkModuloRegions` rather than `EvaluatedToOk`. Correspondingly, the comment says "no free lifetimes or generic parameters". But the code was mistakenly checking `has_non_region_infer()` twice instead of checking both `has_non_region_infer()` and `has_non_region_param()`. This meant that `TypeOutlives(T, 'static)` where `T` is a type parameter returned `EvaluatedToOk` -- claiming the result holds unconditionally -- when the correct answer is `EvaluatedToOkModuloRegions`. The distinction matters during marker trait winnowing in `prefer_lhs_over_victim`, which uses `must_apply_considering_regions()` (true only for `EvaluatedToOk`) to decide whether one impl beats another when there are multiple candidates. With the bug, a `T: 'static`-bounded impl appeared equally as strong as an unrestricted impl, making the winner depend on source order. This caused spurious E0310 errors when the more-constrained impl happened to appear after the less-constrained one. Fixes rust-lang/rust#109481. This same symptom was originally filed as rust-lang/rust#84917 and fixed in PR rust-lang/rust#88139. Then PR rust-lang/rust#102472 rewrote the `TypeOutlives` handler, introducing the duplicate `has_non_region_infer()` and losing the param check, regressing this. Around this same time, rust-lang/rust#109481 was filed. It noted the connection to rust-lang/rust#102472 -- the bug only appeared after it -- but the duplicate condition was not noticed. r? @lcnr cc @oli-obk @nikomatsakis
Jacob Pratt 5 weeks ago
parent acb1d05 · parent 9d5273a · commit 91baabc
0 files changed, 0 insertions, 0 deletions