-
-
Notifications
You must be signed in to change notification settings - Fork 15.4k
Support generic params in Lift_Generic
#156956
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
Merged
rust-bors
merged 5 commits into
rust-lang:main
from
Jamesbarford:feat/extend-lift-generic-capabilities
Jun 4, 2026
Merged
Changes from 2 commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
bb5f1c8
`Lift_Generic` can lift generic parameters
Jamesbarford 2837932
Add comment explaining why we need a `Lift` bound for all fields
Jamesbarford 91a328f
Can lift structs with a field of `PhantomData`
Jamesbarford a55c892
Simplify generic Lift bounds
Jamesbarford 57da2f6
Add documentation comment for `lift_derive`, move `PhantomData` check…
Jamesbarford File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so this adds
field_ty: Lift<J, Lifted = mapped_field_ty>. Can you add a comment for why we need to add bothT: Lift<J>(as in, for each param), and also support lifting for all fields?It would be really cool if we can only add
Liftbounds for the generic parameters, but likely that doesn't quite work?View changes since the review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see a way to do that with the current generated code.
For example:
Adding bounds only for generic parameters gives us
T: Lift<J>, which is enough forvalue.However the generated body also calls
lift_to_interner(...)onid, and the lifted struct expects that field to becomeJ::DefId. So, unless I'm missing something, we still need:Addressed feedback in; 2837932
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one way would be to add
I would expect this should work? 🤔 I never quite know how implied bounds work :>
and this would have a blanket impl that holds exactly if the implied bounds of the trait hold
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, need to write it a bit differently, can't use where-clauses, need to use associated type bounds
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I follow. I tried with the following;
The list, as you can imagine, was long. I did get
rustc_type_irto compile with this idea.However this would fail in
rustc_middle. I believe the problem is thatInternerCanLiftTo<J>is a global bound on the wholeInterner, while the bounds we need are local to each derived type. If the trait includesParamEnv,Symboletc., then every#[derive(Lift_Generic)]requires those associated types to implementLift, even for types that do not contain those fields.It seems a bit off in so much as it either does not include enough associated types, or it includes enough and subsequently over-constrains unrelated derived impls. Though I have perhaps missed your point and tried something a bit off piste 😅.
I have prototyped something that allows us to remove most manual implementations and I think with a bit of tweaking get rid of all manual implementations. So I shall push that up once I've got something working.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
91a328f leaves 3 manual implementations of which there are two code patterns;
LiftforOptionwhich seems distinct enough from the other implementations that leaving it alone seemed reasonable to me.Liftfor a struct where there is amatchonself.kind()for example;A way I saw to be able to handle that would be to add a
#[derive(<new_name>)]to anenumand then possibly create another#[derive(Lift_KindGeneric)]to then generate the implementation offn lift_to_interner(). I experimented with that and had something broadly working locally in a toy example but I'm not sure if that's too much magic for what we are trying to achieve. Moreover this pattern is only implemented in two places and theLift_Genericlives inrustc_type_ir_macros;There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would include all types we'd ever want to lift in there. While this is not necessary for all impls of a given type, it is required for lift to make sense in general
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the option
Liftimpl is just thederive. whether u callmapor match onOptionmanually doesn't really matter :3Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lift for these packed pointers is more interesting and would prolly keep this as a manual impl, seems innocent enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done; a55c892.
This did mean I had to implement
Liftfor a couple other types, as well as expand a macro. I got a pipeline failure So implementedLift<I> for ()