-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
handle_opaque_type likely mis-uses eq
relation
#101186
Comments
Yeah, I've considered this too.
Do we even need to pass down the relation? We just re-invoke |
while we could fix that site, the reason we are generalizing at all is the other |
Ah yeah, totally overlooked the success case and was focusing too much on the error case 😅 |
…r=compiler-errors Clean up hidden type registration work on rust-lang#101186 Actually passing down the relation and using it instead of `eq` for the hidden type comparison has *no* effect whatsoever and allows for no further improvements at the call sites. I decided the increased complexity was not worth it and thus did not include that change in this PR. r? `@compiler-errors`
I believe we've cleaned up all we can here |
I was unable to reproduce the issue in the defining scope (that doesn't mean it's not possible, just that I gave up for now ^^). I found this absolutely useless diagnostic though: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b80473c86172959763c139535154c3f9
Did some more thinking and I'm wondering now if the
did.is_local()
check should actually beinfcx.opaque_type_origin(did).is_some()
so we only generate those generalized inference vars if we're actually able to handle the opaque type. I was kinda hoping to keep that isolated inhandle_opaque_type
, but that appears to have been a misplaced hope.One more thing is that we're using
eq
insidehandle_opaque_types
when it should probably be using the relation that is callinghandle_opaque_types
. So maybe we could scrap the entire generalization logic and just always invokehandle_opaque_types
by passing the relation as an argument and forwarding to that instead of usingeq
.so many possibilities to try out. Let's merge this PR for now and I'm moving this comment to an issue so we can continue there.
Originally posted by @oli-obk in #99928 (comment)
The text was updated successfully, but these errors were encountered: