remove reliance on a trait solver inference bug #18840
Merged
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
the parameter `In` of `call_inner` is completely unconstrained by its arguments and return type. We are only able to infer it by assuming that the only associated type equal to `In::Param<'_>` is `In::Param<'_>` itself. It could just as well be some other associated type which only normalizes to `In::Param<'_>`. cc rust-lang/trait-system-refactor-initiative#168
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
alice-i-cecile
approved these changes
Apr 14, 2025
mockersf
approved these changes
Apr 14, 2025
cart
approved these changes
Apr 14, 2025
mockersf
pushed a commit
that referenced
this pull request
Apr 14, 2025
The parameter `In` of `call_inner` is completely unconstrained by its arguments and return type. We are only able to infer it by assuming that the only associated type equal to `In::Param<'_>` is `In::Param<'_>` itself. It could just as well be some other associated type which only normalizes to `In::Param<'_>`. This will change with the next-generation trait solver and was encountered by a crater run rust-lang/rust#133502 cc rust-lang/trait-system-refactor-initiative#168 I couldn't think of a cleaner alternative here. I first tried to just provide `In` as an explicit type parameter. This is also kinda ugly as I need to provide a variable number of them and `${ignore(..)}` is currently still unstable rust-lang/rust#83527. Sorry for the inconvenience. Also fun that this function exists to avoid a separate solver bug in the first place 😅
# for free
to join this conversation on GitHub.
Already have an account?
# 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 parameter
Inofcall_inneris completely unconstrained by its arguments and return type. We are only able to infer it by assuming that the only associated type equal toIn::Param<'_>isIn::Param<'_>itself. It could just as well be some other associated type which only normalizes toIn::Param<'_>. This will change with the next-generation trait solver and was encountered by a crater run rust-lang/rust#133502cc rust-lang/trait-system-refactor-initiative#168
I couldn't think of a cleaner alternative here. I first tried to just provide
Inas an explicit type parameter. This is also kinda ugly as I need to provide a variable number of them and${ignore(..)}is currently still unstable rust-lang/rust#83527.Sorry for the inconvenience. Also fun that this function exists to avoid a separate solver bug in the first place 😅