remove reliance on a trait solver inference bug#18840
Merged
cart merged 1 commit intobevyengine:mainfrom Apr 14, 2025
Merged
Conversation
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
Contributor
|
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
Member
cart
left a comment
There was a problem hiding this comment.
Ugly, but this does make sense, and this is fully internal so who cares :)
Thanks for keeping us future-aligned!
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 😅
jf908
pushed a commit
to jf908/bevy
that referenced
this pull request
May 12, 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 😅
This was referenced May 25, 2025
mockersf
pushed a commit
that referenced
this pull request
May 25, 2025
A backport of #18840 to version 0.15.3. I was unsure whether I should also update the versions of all crates. Looking at previous backports this was not done. The code which relies on the old solver behavior was introduced in #15184 which is from version 0.15. So this is the only version which needs a backport. cc @mockersf
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
4 participants
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 😅