fixed Implement opaques_with_sub_unified_hidden_type for the next-sol… - #23061
Open
solodevstack wants to merge 1 commit into
Open
fixed Implement opaques_with_sub_unified_hidden_type for the next-sol…#23061solodevstack wants to merge 1 commit into
solodevstack wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The following previously produced by a type mismatch "unknown" or E0599 diagnostic:
async fn test() -> ! {
Box::pin(test()).await;
}
This is a self-recursive async function returning !, while type checking its own body, .await need <Box<Pin<...>> as IntoFuture>::Output to normalize !, but that ! comes from this very function's own opaque return type.
which isn't resolved yet since we're still in the middle of checking it.
The inference variable created for the .await result ends up subunified with the unknown hidden type of the in-flight opaque, and the solver had no way to look through that relationship to the opaque's bounds.
This was fixed by implementing InferCtxt::opaques_with_sub_unified_hidden_type, which was previously stubbed to always return vec![].
That method lets the solver ask "is there an in-flight opaque type whose (still-unresolved) hidden type is sub-unified with this stuck inference variable?" and if so, fall back to that opaque's item bounds/blanket impls to keep making progress instead of giving up.
AI was used for assist but i fixed and diagnosed solution myself.
Fixes: rust-lang/rust-analyzer #22853