-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trait selection caching does not handle subtyping properly #30225
Comments
Yeah, I've been waiting for someone to make an example for this. I had a strategy for fixing it but never got around to implementing it. Thanks for making an example @arielb1 ! |
triage: P-medium |
@nikomatsakis can mentor. |
@nikomatsakis I'd be interested in working on this if you're still willing to mentor. |
@cramertj hmm, at this point I think the way I want to solve this is as part of a bigger refactoring to overhaul trait system. I recently wrote the very first post of a series of posts that I hope to write explaining the approach; I need to think about the actual steps for making that transition. Would you maybe be interested in helping with that task? |
@nikomatsakis I would absolutely be interested in helping! |
…ion, r=arielb1 Handle subtyping in inference through obligations We currently store subtyping relations in the `TypeVariables` structure as a kind of special case. This branch uses normal obligations to propagate subtyping, thus converting our inference variables into normal fallback. It also does a few other things: - Removes the (unstable, outdated) support for custom type inference fallback. - It's not clear how we want this to work, but we know that we don't want it to work the way it currently does. - The existing support was also just getting in my way. - Fixes #30225, which was caused by the trait caching code pretending type variables were normal unification variables, when indeed they were not (but now are). There is one fishy part of these changes: when computing the LUB/GLB of a "bivariant" type parameter, I currently return the `a` value. Bivariant type parameters are only allowed in a very particular situation, where the type parameter is only used as an associated type output, like this: ```rust pub struct Foo<A, B> where A: Fn() -> B { data: A } ``` In principle, if one had `T=Foo<A, &'a u32>` and `U=Foo<A, &'b u32>` and (e.g.) `A: for<'a> Fn() -> &'a u32`, then I think that computing the LUB of `T` and `U` might do the wrong thing. Probably the right behavior is just to create a fresh type variable. However, that particular example would not compile (because the where-clause is illegal; `'a` does not appear in any input type). I was not able to make an example that *would* compile and demonstrate this shortcoming, and handling the LUB/GLB was mildly inconvenient, so I left it as is. I am considering whether to revisit this or what. I have started a crater run to test the impact of these changes.
STR
Results
Comments
@nikomatsakis and me were worried that this might be possible since we had multidispatch, but this is the first working example. I found this while poking with the unification machinery.
The text was updated successfully, but these errors were encountered: