add field_of! macro and field representing types#118658
add field_of! macro and field representing types#118658BennoLossin wants to merge 1 commit intorust-lang:masterfrom
field_of! macro and field representing types#118658Conversation
|
r? @b-naber (rustbot has picked a reviewer for you, use r? to override) |
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri This PR changes Stable MIR cc @oli-obk, @celinval, @spastorino, @ouz-a Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #118679) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Can you convert this to a draft PR? Unfortunately I currently don't have enough time to help you with any of the outstanding implementation problems. Have you tried asking for help on zulip? |
|
Thanks for the info, I will go ask there. |
|
@y86-dev any updates on this pr? |
|
currently I am very busy. @nbdd0121 created an improved version some time ago: https://github.com/nbdd0121/rust/tree/field-projection |
|
Closing this in favour of the improved version @nbdd0121 can you submit a draft pr here with those changes (even if wip) and mention this pr in the description, makes it easier for future tracking. |
|
bump @nbdd0121 |
I implemented the core of rust-lang/rfcs#3318 for personal experimentation and found out that you can get experimental features merged easier than a whole RFC. I do not know the correct process to do this, but I thought a PR would be the way to go.
This PR introduces field info types. These types are generated for every field of every struct. They can be named by using the
core::mem::field_of!()macro also introduced by this PR.I have not had any experience modifying the Rust compiler, so there will be mistakes. I could definitely use some help refining this, so any comments are welcomed. The way I implemented was by first looking at
offset_of!then realizing I want something that resolves to a type and not an expression, I then went and took a look at howimpl Traittypes are implemented and copied a lot from that. At some point I also realized that type equality and trait resolution were incorrect, so I went digging and I think I fixed it.Here a list of things to complete before even thinking about merging:
field_of!FieldInfo: should thehirversion be namedFieldOf?field_of!(_, foo)cargoinstead ofrustcExample Code
Output:
Foo { value: 42, next: Some(Foo { value: 84, next: None }) }