Tracking issue for future-incompatibility lint coherence_leak_check
#56105
Description
This is the tracking issue for the "universe transition". The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around bug fixes that affect existing code, see our breaking change policy guidelines.
What was the change and what code is affected?
This change (introduced in #55517) fixed a number of bugs (e.g., #32330) in how the Rust compiler handled higher-ranked types (e.g., fn(&u8)
or -- more explicitly -- for<'a> fn(&'a u8)
) and trait bounds (e.g., for<'a> T: Trait<'a>
). One of these changes could however affect existing code. In particular, the compiler in the past would accept trait implementations for identical functions that differed only in where the lifetime binder appeared:
trait SomeTrait { }
impl SomeTrait for for<'a> fn(&'a u8) { }
impl<'a> SomeTrait for fn(&'a u8) { }
We no longer accept both of these impls. Code relying on this pattern would now have to introduce "newtypes", like struct Foo(for<'a> fn(&'a u8))
.
History of this change
This change was first made in #55517 without a "warning period". This was done because (a) it would be challenging to issue precise warnings for affected code and (b) a crater run found zero regressions.
However, the change was subsequently backed out in #58592, owing to concerns about unintended side-effects.
The change was re-added in #65232, but this time with a warning period. We are currently completing the implementation and trying to figure out how to draw the line in terms of what should become a hard error.
Affected crates and patterns
This section is for collecting patterns and examples to look into or other related issues.
- wasm-bindgen was reported to get warnings in replace the leak check with universes, take 2 #65232
- @quark-zju commented that their crate was affected here
- coercion becomes order dependent for higher-ranked functions #73154 -- order dependent coercion
Metadata
Assignees
Labels
Type
Projects
Status
Idea
Activity