-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
Tracking Issue for #![feature(offset_of)]
#106655
Comments
This comment was marked as resolved.
This comment was marked as resolved.
Add offset_of! macro (RFC 3308) Implements rust-lang/rfcs#3308 (tracking issue rust-lang#106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented: * Nested field accesses (without array indexing) * DST support (for `Sized` fields) I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it. cc `@thomcc` (RFC author)
Add offset_of! macro (RFC 3308) Implements rust-lang/rfcs#3308 (tracking issue rust-lang#106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented: * Nested field accesses (without array indexing) * DST support (for `Sized` fields) I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it. cc `@thomcc` (RFC author)
This macro is used to compute the offset of a field in a struct. This commit enables two unstable features that are necessary for using the macro in a constant. However, this is not a problem as the macro will become available from the Rust standard library soon [1]. The unstable features can be disabled again once that happens. The macro in this patch does not support sub-fields. That is, you cannot write `offset_of!(MyStruct, field.sub_field)` to get the offset of `sub_field` with `field`'s type being a struct with a field called `sub_field`. This is because `field` might be a `Box<SubStruct>`, which means that you would be trying to compute the offset to something in an entirely different allocation. There's no easy way to fix the current macro to support subfields, but the version being added to the standard library should support it, so the limitation is temporary and not a big deal. Link: rust-lang/rust#106655 [1] Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Alice Ryhl <[email protected]> Signed-off-by: Alice Ryhl <[email protected]>
Some things that could get tests:
Edit: #111665 |
Add offset_of! macro (RFC 3308) Implements rust-lang/rfcs#3308 (tracking issue rust-lang#106655) by adding the built in macro `core::mem::offset_of`. Two of the future possibilities are also implemented: * Nested field accesses (without array indexing) * DST support (for `Sized` fields) I wrote this a few months ago, before the RFC merged. Now that it's merged, I decided to rebase and finish it. cc `@thomcc` (RFC author)
Implement builtin # syntax and use it for offset_of!(...) Add `builtin #` syntax to the parser, as well as a generic infrastructure to support both item and expression position builtin syntaxes. The PR also uses this infrastructure for the implementation of the `offset_of!` macro, added by rust-lang#106934. cc `@petrochenkov` `@DrMeepster` cc rust-lang#110680 `builtin #` tracking issue cc rust-lang#106655 `offset_of!` tracking issue
This macro is used to compute the offset of a field in a struct. This commit enables two unstable features that are necessary for using the macro in a constant. However, this is not a problem as the macro will become available from the Rust standard library soon [1]. The unstable features can be disabled again once that happens. The macro in this patch does not support sub-fields. That is, you cannot write `offset_of!(MyStruct, field.sub_field)` to get the offset of `sub_field` with `field`'s type being a struct with a field called `sub_field`. This is because `field` might be a `Box<SubStruct>`, which means that you would be trying to compute the offset to something in an entirely different allocation. There's no easy way to fix the current macro to support subfields, but the version being added to the standard library should support it, so the limitation is temporary and not a big deal. Link: rust-lang/rust#106655 [1] Signed-off-by: Wedson Almeida Filho <[email protected]> Co-developed-by: Alice Ryhl <[email protected]> Signed-off-by: Alice Ryhl <[email protected]>
This macro is used to compute the offset of a field in a struct. This commit enables two unstable features that are necessary for using the macro in a constant. However, this is not a problem as the macro will become available from the Rust standard library soon [1]. The unstable features can be disabled again once that happens. The macro in this patch does not support sub-fields. That is, you cannot write `offset_of!(MyStruct, field.sub_field)` to get the offset of `sub_field` with `field`'s type being a struct with a field called `sub_field`. This is because `field` might be a `Box<SubStruct>`, which means that you would be trying to compute the offset to something in an entirely different allocation. There's no easy way to fix the current macro to support subfields, but the version being added to the standard library should support it, so the limitation is temporary and not a big deal. Link: rust-lang/rust#106655 [1] Signed-off-by: Alice Ryhl <[email protected]> Co-Developed-by: Wedson Almeida Filho <[email protected]> Signed-off-by: Wedson Almeida Filho <[email protected]>
Small nit on the docs: I don't think "stable" is the right word to use for describing the output on non- @rfcbot fcp merge |
Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members: Concerns:
Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
Looks like it has an issue: |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@Amanieu do you suggest to stabilize |
This FCP is to confirm that libs-api is happy with committing to this macro existing forever with this interface. That seems refreshingly uncontroversial in this case. Whether the implementation is robust/bug free enough is a bit of a separate question, and it might be worth delaying stabilization for that. If you think there is value in having more time for the interface/api itself, please share your thoughts on that! |
Oh I see! I don't think we are committing to the interface until stabilization, but yes, the interface seems uncontroversial 👍🏻 |
One nice project before stabilization would be to make a PR to memoffset to use |
I wanted to double check that the lang team was okay with us making the call on an API like this, and indeed, they did respond on the RFC saying they were comfortable with it being in libs-api's hands: rust-lang/rfcs#3308 (comment) |
I'm sorry if I've missed it, but at least a CTRL+F "pattern" didn't turn up anything, but I'm really surprised by this issue why we are not just using the basic pattern matching syntax? That resolves all cases including deeply nested stuff, enums and co., while also not needing to make up any new way of expressing these things. Also in my opinion, if we were to go with pattern matching syntax, then it wouldn't be super compatible with the |
The current-on-nightly syntax has precedent in c's offsetof (standard link), including the way dots work for nesting, so it has some familiarity I would presume. But this doesn't mean that we can't do Regarding pattern syntax, I wonder how arrays would be represented, so what would be the pattern analog of c's |
IDK maybe I made the wrong estimate and it's too early still for a stabilization of |
I am thinking that To summarise, the main options that I'm aware of and my views on them are:
|
You're forgetting enums |
@CryZe btw, patterns have come up in the syntax discussion on zulip. Maybe it would be best to move this discussion there? Or a dedicated thread elswhere. This is a tracking issue after all :). |
I don't think I understand what the pattern syntax would look like, could someone give some examples? |
Yeah the zulip thread proposes usage of @ for that.
Yes, sorry I forgot. replace that .10 with .ten :). |
Make offset_of field parsing use metavariable which handles any spacing As discussed at and around comments rust-lang#106655 (comment) and rust-lang#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`. They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca) ```rust macro_rules! off { ($a:expr) => { offset_of!(m::S, 0. $a) } } ``` This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above. This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC. Tracking issue for offset_of: rust-lang#106655 `@rustbot` label F-offset_of `@est31`
Make offset_of field parsing use metavariable which handles any spacing As discussed at and around comments rust-lang#106655 (comment) and rust-lang#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`. They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca) ```rust macro_rules! off { ($a:expr) => { offset_of!(m::S, 0. $a) } } ``` This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above. This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC. Tracking issue for offset_of: rust-lang#106655 ``@rustbot`` label F-offset_of ``@est31``
Rollup merge of rust-lang#119532 - GKFX:offset-of-parse-expr, r=est31 Make offset_of field parsing use metavariable which handles any spacing As discussed at and around comments rust-lang#106655 (comment) and rust-lang#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`. They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca) ```rust macro_rules! off { ($a:expr) => { offset_of!(m::S, 0. $a) } } ``` This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above. This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC. Tracking issue for offset_of: rust-lang#106655 ``@rustbot`` label F-offset_of ``@est31``
Make offset_of field parsing use metavariable which handles any spacing As discussed at and around comments rust-lang/rust#106655 (comment) and rust-lang/rust#106655 (comment), the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`. They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca) ```rust macro_rules! off { ($a:expr) => { offset_of!(m::S, 0. $a) } } ``` This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above. This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC. Tracking issue for offset_of: #106655 ``@rustbot`` label F-offset_of ``@est31``
…wesleywiser Stabilize single-field offset_of This PR stabilizes offset_of for a single field. There has been some further discussion at rust-lang#106655 about whether this is advisable; I'm opening the PR anyway so that the code is available.
Rollup merge of rust-lang#118799 - GKFX:stabilize-simple-offsetof, r=wesleywiser Stabilize single-field offset_of This PR stabilizes offset_of for a single field. There has been some further discussion at rust-lang#106655 about whether this is advisable; I'm opening the PR anyway so that the code is available.
As #118799 has been merged, non-nested I'm closing this tracking issue as the still unstable aspects of the Thanks everyone involved in getting |
Stabilize single-field offset_of This PR stabilizes offset_of for a single field. There has been some further discussion at rust-lang/rust#106655 about whether this is advisable; I'm opening the PR anyway so that the code is available.
Feature gate enums in offset_of As requested at rust-lang/rust#106655 (comment), put enums in offset_of behind their own feature gate. `@rustbot` label F-offset_of
Remove option_payload_ptr; redundant to offset_of The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at rust-lang/rust#106655 (comment)). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
Feature gate enums in offset_of As requested at rust-lang/rust#106655 (comment), put enums in offset_of behind their own feature gate. `@rustbot` label F-offset_of
Remove option_payload_ptr; redundant to offset_of The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at rust-lang/rust#106655 (comment)). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
Feature gates tracked by this issue:
#![feature(offset_of)]
-> moved to Tracking Issue for enum access in offset_of #120141#![feature(offset_of_enum)]
This is a tracking issue for the
offset_of!
macro which evaluates to a constantcontaining the offset in bytes of a field inside some type (rust-lang/rfcs#3308).
Public API
Steps / History
offset_of_enum
: Feature gate enums in offset_of #117537Possible future extensions / work
struct Example(u32, [u8])
)enum
s: Support enum variants in offset_of! #114208Unresolved Questions
Footnotes
https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩
The text was updated successfully, but these errors were encountered: