-
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 RFC 2102, "Unnamed fields of struct and union type" #49804
Comments
@Centril Regarding unresolved questions: the first three paragraphs in that section are just talking about the future possibility of full unnamed types that can appear everywhere, which would be the subject of a future RFC. The last paragraph talks about other future possibilities that also need their own RFCs. |
@joshtriplett Yeah; that was also my interpretation, so ==> no unresolved questions? |
Looks like this still needs an implementation |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Is there any movement on this, or is it just waiting for someone to implement it? |
This is still waiting on an implementation. |
@varkor maybe mentoring instructions would help someone get started? |
I don't have time to write up full mentoring instructions at the moment, but if someone is interested in implementing this feature, I am happy to provide pointers for how to get started on Zulip.
|
I'm interested on implementing this, but I need some mentoring to answer some questions I have. |
…enkov Parse unnamed fields of struct and union type Added the `unnamed_fields` feature gate. This is a prototype of [RFC 2102](rust-lang#49804), so any suggestions are greatly appreciated. r? `@petrochenkov`
Ok, the parsing step has been completed. The next step is to lower the new types from the AST to the HIR. Could someone give me some recommendations on how to approach this? |
Is there still someone able to provide mentorship for implementing this? Is there still someone available to try implementing this? |
I would be interested to try implementing this, but would defer to the previous implementer if they are still interested. |
Please do so! I'm somewhat busy nowadays, so I'd prefer leaving this work to someone who can dedicate their full attention to it :) |
chore(deps): update compatible [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [anstream](https://togithub.com/rust-cli/anstyle) | workspace.dependencies | patch | `0.6.3` -> `0.6.4` | | [base64](https://togithub.com/marshallpierce/rust-base64) | workspace.dependencies | patch | `0.21.3` -> `0.21.4` | | [color-print](https://gitlab.com/dajoha/color-print) | workspace.dependencies | patch | `0.3.4` -> `0.3.5` | | [git2](https://togithub.com/rust-lang/git2-rs) | workspace.dependencies | patch | `0.18.0` -> `0.18.1` | | [libloading](https://togithub.com/nagisa/rust_libloading) | workspace.dependencies | patch | `0.8.0` -> `0.8.1` | | [memchr](https://togithub.com/BurntSushi/memchr) | workspace.dependencies | patch | `2.6.2` -> `2.6.3` | | [proptest](https://proptest-rs.github.io/proptest/proptest/index.html) ([source](https://togithub.com/proptest-rs/proptest)) | workspace.dependencies | minor | `1.2.0` -> `1.3.0` | | [semver](https://togithub.com/dtolnay/semver) | workspace.dependencies | patch | `1.0.18` -> `1.0.19` | | [serde_json](https://togithub.com/serde-rs/json) | workspace.dependencies | patch | `1.0.105` -> `1.0.107` | | [sha1](https://togithub.com/RustCrypto/hashes) | workspace.dependencies | patch | `0.10.5` -> `0.10.6` | | [sha2](https://togithub.com/RustCrypto/hashes) | workspace.dependencies | patch | `0.10.7` -> `0.10.8` | | [syn](https://togithub.com/dtolnay/syn) | workspace.dependencies | patch | `2.0.29` -> `2.0.37` | | [thiserror](https://togithub.com/dtolnay/thiserror) | workspace.dependencies | patch | `1.0.47` -> `1.0.49` | | [unicode-width](https://togithub.com/unicode-rs/unicode-width) | workspace.dependencies | patch | `0.1.10` -> `0.1.11` | | [walkdir](https://togithub.com/BurntSushi/walkdir) | workspace.dependencies | minor | `2.3.3` -> `2.4.0` | --- ### Release Notes <details> <summary>rust-cli/anstyle (anstream)</summary> ### [`v0.6.4`](https://togithub.com/rust-cli/anstyle/compare/anstream-v0.6.3...anstream-v0.6.4) [Compare Source](https://togithub.com/rust-cli/anstyle/compare/anstream-v0.6.3...anstream-v0.6.4) </details> <details> <summary>marshallpierce/rust-base64 (base64)</summary> ### [`v0.21.4`](https://togithub.com/marshallpierce/rust-base64/blob/HEAD/RELEASE-NOTES.md#0214) [Compare Source](https://togithub.com/marshallpierce/rust-base64/compare/v0.21.3...v0.21.4) - Make `encoded_len` `const`, allowing the creation of arrays sized to encode compile-time-known data lengths </details> <details> <summary>rust-lang/git2-rs (git2)</summary> ### [`v0.18.1`](https://togithub.com/rust-lang/git2-rs/blob/HEAD/CHANGELOG.md#0181---2023-09-20) [Compare Source](https://togithub.com/rust-lang/git2-rs/compare/git2-0.18.0...git2-0.18.1) [0.18.0...0.18.1](https://togithub.com/rust-lang/git2-rs/compare/git2-0.18.0...git2-0.18.1) ##### Added - Added `FetchOptions::depth` to set the depth of a fetch or clone, adding support for shallow clones. [#​979](https://togithub.com/rust-lang/git2-rs/pull/979) ##### Fixed - Fixed an internal data type (`TreeWalkCbData`) to not assume it is a transparent type while casting. [#​989](https://togithub.com/rust-lang/git2-rs/pull/989) - Fixed so that `DiffPatchidOptions` and `StashSaveOptions` are publicly exported allowing the corresponding APIs to actually be used. [#​988](https://togithub.com/rust-lang/git2-rs/pull/988) </details> <details> <summary>nagisa/rust_libloading (libloading)</summary> ### [`v0.8.1`](https://togithub.com/nagisa/rust_libloading/compare/0.8.0...0.8.1) [Compare Source](https://togithub.com/nagisa/rust_libloading/compare/0.8.0...0.8.1) </details> <details> <summary>BurntSushi/memchr (memchr)</summary> ### [`v2.6.3`](https://togithub.com/BurntSushi/memchr/compare/2.6.2...2.6.3) [Compare Source](https://togithub.com/BurntSushi/memchr/compare/2.6.2...2.6.3) </details> <details> <summary>proptest-rs/proptest (proptest)</summary> ### [`v1.3.0`](https://togithub.com/proptest-rs/proptest/compare/v1.2.0...v1.3.0) [Compare Source](https://togithub.com/proptest-rs/proptest/compare/v1.2.0...v1.3.0) </details> <details> <summary>dtolnay/semver (semver)</summary> ### [`v1.0.19`](https://togithub.com/dtolnay/semver/releases/tag/1.0.19) [Compare Source](https://togithub.com/dtolnay/semver/compare/1.0.18...1.0.19) - Improve test coverage ([#​299](https://togithub.com/dtolnay/semver/issues/299), thanks [`@​CXWorks](https://togithub.com/CXWorks))` </details> <details> <summary>serde-rs/json (serde_json)</summary> ### [`v1.0.107`](https://togithub.com/serde-rs/json/releases/tag/v1.0.107) [Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.106...v1.0.107) - impl IntoDeserializer for \&RawValue ([#​1071](https://togithub.com/serde-rs/json/issues/1071)) ### [`v1.0.106`](https://togithub.com/serde-rs/json/releases/tag/v1.0.106) [Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.105...v1.0.106) - Add `Value::as_number` accessor ([#​1069](https://togithub.com/serde-rs/json/issues/1069), thanks [`@​chanced](https://togithub.com/chanced))` - Add `Number::as_str` accessor under "arbitrary_precision" feature ([#​1067](https://togithub.com/serde-rs/json/issues/1067), thanks [`@​chanced](https://togithub.com/chanced))` </details> <details> <summary>RustCrypto/hashes (sha1)</summary> ### [`v0.10.6`](https://togithub.com/RustCrypto/hashes/compare/sha1-v0.10.5...sha1-v0.10.6) [Compare Source](https://togithub.com/RustCrypto/hashes/compare/sha1-v0.10.5...sha1-v0.10.6) </details> <details> <summary>dtolnay/syn (syn)</summary> ### [`v2.0.37`](https://togithub.com/dtolnay/syn/releases/tag/2.0.37) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.36...2.0.37) - Work around incorrect future compatibility warning in rustc 1.74.0-nightly ### [`v2.0.36`](https://togithub.com/dtolnay/syn/releases/tag/2.0.36) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.35...2.0.36) - Restore compatibility with `--generate-link-to-definition` documentation builds ([#​1514](https://togithub.com/dtolnay/syn/issues/1514)) ### [`v2.0.35`](https://togithub.com/dtolnay/syn/releases/tag/2.0.35) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.34...2.0.35) - Make rust-analyzer produce preferred brackets for invocations of `Token!` macro ([#​1510](https://togithub.com/dtolnay/syn/issues/1510), [#​1512](https://togithub.com/dtolnay/syn/issues/1512)) ### [`v2.0.34`](https://togithub.com/dtolnay/syn/releases/tag/2.0.34) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.33...2.0.34) - Documentation improvements ### [`v2.0.33`](https://togithub.com/dtolnay/syn/releases/tag/2.0.33) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.32...2.0.33) - Special handling for the `(/*ERROR*/)` placeholder that rustc uses for macros that fail to expand ### [`v2.0.32`](https://togithub.com/dtolnay/syn/releases/tag/2.0.32) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.31...2.0.32) - Add `Path::require_ident` accessor ([#​1496](https://togithub.com/dtolnay/syn/issues/1496), thanks [`@​Fancyflame](https://togithub.com/Fancyflame))` ### [`v2.0.31`](https://togithub.com/dtolnay/syn/releases/tag/2.0.31) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.30...2.0.31) - Parse generics and where-clause on const items ([rust-lang/rust#113521) ### [`v2.0.30`](https://togithub.com/dtolnay/syn/releases/tag/2.0.30) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.29...2.0.30) - Parse unnamed struct/union type syntax ([rust-lang/rust#49804) </details> <details> <summary>dtolnay/thiserror (thiserror)</summary> ### [`v1.0.49`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.49) [Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.48...1.0.49) - Access libcore types through `::core` in generated code ([#​255](https://togithub.com/dtolnay/thiserror/issues/255), thanks [`@​mina86](https://togithub.com/mina86))` ### [`v1.0.48`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.48) [Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.47...1.0.48) - Improve implementation of displaying Path values in a generated Display impl ([#​251](https://togithub.com/dtolnay/thiserror/issues/251), thanks [`@​mina86](https://togithub.com/mina86))` </details> <details> <summary>unicode-rs/unicode-width (unicode-width)</summary> ### [`v0.1.11`](https://togithub.com/unicode-rs/unicode-width/compare/v0.1.10...v0.1.11) [Compare Source](https://togithub.com/unicode-rs/unicode-width/compare/v0.1.10...v0.1.11) </details> <details> <summary>BurntSushi/walkdir (walkdir)</summary> ### [`v2.4.0`](https://togithub.com/BurntSushi/walkdir/compare/2.3.3...2.4.0) [Compare Source](https://togithub.com/BurntSushi/walkdir/compare/2.3.3...2.4.0) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4wLjMiLCJ1cGRhdGVkSW5WZXIiOiIzNy4wLjMiLCJ0YXJnZXRCcmFuY2giOiJtYXN0ZXIifQ==-->
chore(deps): update compatible [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [anstream](https://togithub.com/rust-cli/anstyle) | workspace.dependencies | patch | `0.6.3` -> `0.6.4` | | [base64](https://togithub.com/marshallpierce/rust-base64) | workspace.dependencies | patch | `0.21.3` -> `0.21.4` | | [color-print](https://gitlab.com/dajoha/color-print) | workspace.dependencies | patch | `0.3.4` -> `0.3.5` | | [git2](https://togithub.com/rust-lang/git2-rs) | workspace.dependencies | patch | `0.18.0` -> `0.18.1` | | [libloading](https://togithub.com/nagisa/rust_libloading) | workspace.dependencies | patch | `0.8.0` -> `0.8.1` | | [memchr](https://togithub.com/BurntSushi/memchr) | workspace.dependencies | patch | `2.6.2` -> `2.6.4` | | [proptest](https://proptest-rs.github.io/proptest/proptest/index.html) ([source](https://togithub.com/proptest-rs/proptest)) | workspace.dependencies | minor | `1.2.0` -> `1.3.1` | | [semver](https://togithub.com/dtolnay/semver) | workspace.dependencies | patch | `1.0.18` -> `1.0.19` | | [serde_json](https://togithub.com/serde-rs/json) | workspace.dependencies | patch | `1.0.105` -> `1.0.107` | | [sha1](https://togithub.com/RustCrypto/hashes) | workspace.dependencies | patch | `0.10.5` -> `0.10.6` | | [sha2](https://togithub.com/RustCrypto/hashes) | workspace.dependencies | patch | `0.10.7` -> `0.10.8` | | [syn](https://togithub.com/dtolnay/syn) | workspace.dependencies | patch | `2.0.29` -> `2.0.37` | | [thiserror](https://togithub.com/dtolnay/thiserror) | workspace.dependencies | patch | `1.0.47` -> `1.0.49` | | [unicode-width](https://togithub.com/unicode-rs/unicode-width) | workspace.dependencies | patch | `0.1.10` -> `0.1.11` | | [walkdir](https://togithub.com/BurntSushi/walkdir) | workspace.dependencies | minor | `2.3.3` -> `2.4.0` | --- ### Release Notes <details> <summary>rust-cli/anstyle (anstream)</summary> ### [`v0.6.4`](https://togithub.com/rust-cli/anstyle/compare/anstream-v0.6.3...anstream-v0.6.4) [Compare Source](https://togithub.com/rust-cli/anstyle/compare/anstream-v0.6.3...anstream-v0.6.4) </details> <details> <summary>marshallpierce/rust-base64 (base64)</summary> ### [`v0.21.4`](https://togithub.com/marshallpierce/rust-base64/blob/HEAD/RELEASE-NOTES.md#0214) [Compare Source](https://togithub.com/marshallpierce/rust-base64/compare/v0.21.3...v0.21.4) - Make `encoded_len` `const`, allowing the creation of arrays sized to encode compile-time-known data lengths </details> <details> <summary>rust-lang/git2-rs (git2)</summary> ### [`v0.18.1`](https://togithub.com/rust-lang/git2-rs/blob/HEAD/CHANGELOG.md#0181---2023-09-20) [Compare Source](https://togithub.com/rust-lang/git2-rs/compare/git2-0.18.0...git2-0.18.1) [0.18.0...0.18.1](https://togithub.com/rust-lang/git2-rs/compare/git2-0.18.0...git2-0.18.1) ##### Added - Added `FetchOptions::depth` to set the depth of a fetch or clone, adding support for shallow clones. [#​979](https://togithub.com/rust-lang/git2-rs/pull/979) ##### Fixed - Fixed an internal data type (`TreeWalkCbData`) to not assume it is a transparent type while casting. [#​989](https://togithub.com/rust-lang/git2-rs/pull/989) - Fixed so that `DiffPatchidOptions` and `StashSaveOptions` are publicly exported allowing the corresponding APIs to actually be used. [#​988](https://togithub.com/rust-lang/git2-rs/pull/988) </details> <details> <summary>nagisa/rust_libloading (libloading)</summary> ### [`v0.8.1`](https://togithub.com/nagisa/rust_libloading/compare/0.8.0...0.8.1) [Compare Source](https://togithub.com/nagisa/rust_libloading/compare/0.8.0...0.8.1) </details> <details> <summary>BurntSushi/memchr (memchr)</summary> ### [`v2.6.4`](https://togithub.com/BurntSushi/memchr/compare/2.6.3...2.6.4) [Compare Source](https://togithub.com/BurntSushi/memchr/compare/2.6.3...2.6.4) ### [`v2.6.3`](https://togithub.com/BurntSushi/memchr/compare/2.6.2...2.6.3) [Compare Source](https://togithub.com/BurntSushi/memchr/compare/2.6.2...2.6.3) </details> <details> <summary>proptest-rs/proptest (proptest)</summary> ### [`v1.3.1`](https://togithub.com/proptest-rs/proptest/compare/v1.3.0...v1.3.1) [Compare Source](https://togithub.com/proptest-rs/proptest/compare/v1.3.0...v1.3.1) ### [`v1.3.0`](https://togithub.com/proptest-rs/proptest/compare/v1.2.0...v1.3.0) [Compare Source](https://togithub.com/proptest-rs/proptest/compare/v1.2.0...v1.3.0) </details> <details> <summary>dtolnay/semver (semver)</summary> ### [`v1.0.19`](https://togithub.com/dtolnay/semver/releases/tag/1.0.19) [Compare Source](https://togithub.com/dtolnay/semver/compare/1.0.18...1.0.19) - Improve test coverage ([#​299](https://togithub.com/dtolnay/semver/issues/299), thanks [`@​CXWorks](https://togithub.com/CXWorks))` </details> <details> <summary>serde-rs/json (serde_json)</summary> ### [`v1.0.107`](https://togithub.com/serde-rs/json/releases/tag/v1.0.107) [Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.106...v1.0.107) - impl IntoDeserializer for \&RawValue ([#​1071](https://togithub.com/serde-rs/json/issues/1071)) ### [`v1.0.106`](https://togithub.com/serde-rs/json/releases/tag/v1.0.106) [Compare Source](https://togithub.com/serde-rs/json/compare/v1.0.105...v1.0.106) - Add `Value::as_number` accessor ([#​1069](https://togithub.com/serde-rs/json/issues/1069), thanks [`@​chanced](https://togithub.com/chanced))` - Add `Number::as_str` accessor under "arbitrary_precision" feature ([#​1067](https://togithub.com/serde-rs/json/issues/1067), thanks [`@​chanced](https://togithub.com/chanced))` </details> <details> <summary>RustCrypto/hashes (sha1)</summary> ### [`v0.10.6`](https://togithub.com/RustCrypto/hashes/compare/sha2-v0.10.5...sha2-v0.10.6) [Compare Source](https://togithub.com/RustCrypto/hashes/compare/sha1-v0.10.5...sha1-v0.10.6) </details> <details> <summary>dtolnay/syn (syn)</summary> ### [`v2.0.37`](https://togithub.com/dtolnay/syn/releases/tag/2.0.37) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.36...2.0.37) - Work around incorrect future compatibility warning in rustc 1.74.0-nightly ### [`v2.0.36`](https://togithub.com/dtolnay/syn/releases/tag/2.0.36) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.35...2.0.36) - Restore compatibility with `--generate-link-to-definition` documentation builds ([#​1514](https://togithub.com/dtolnay/syn/issues/1514)) ### [`v2.0.35`](https://togithub.com/dtolnay/syn/releases/tag/2.0.35) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.34...2.0.35) - Make rust-analyzer produce preferred brackets for invocations of `Token!` macro ([#​1510](https://togithub.com/dtolnay/syn/issues/1510), [#​1512](https://togithub.com/dtolnay/syn/issues/1512)) ### [`v2.0.34`](https://togithub.com/dtolnay/syn/releases/tag/2.0.34) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.33...2.0.34) - Documentation improvements ### [`v2.0.33`](https://togithub.com/dtolnay/syn/releases/tag/2.0.33) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.32...2.0.33) - Special handling for the `(/*ERROR*/)` placeholder that rustc uses for macros that fail to expand ### [`v2.0.32`](https://togithub.com/dtolnay/syn/releases/tag/2.0.32) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.31...2.0.32) - Add `Path::require_ident` accessor ([#​1496](https://togithub.com/dtolnay/syn/issues/1496), thanks [`@​Fancyflame](https://togithub.com/Fancyflame))` ### [`v2.0.31`](https://togithub.com/dtolnay/syn/releases/tag/2.0.31) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.30...2.0.31) - Parse generics and where-clause on const items ([rust-lang/rust#113521) ### [`v2.0.30`](https://togithub.com/dtolnay/syn/releases/tag/2.0.30) [Compare Source](https://togithub.com/dtolnay/syn/compare/2.0.29...2.0.30) - Parse unnamed struct/union type syntax ([rust-lang/rust#49804) </details> <details> <summary>dtolnay/thiserror (thiserror)</summary> ### [`v1.0.49`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.49) [Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.48...1.0.49) - Access libcore types through `::core` in generated code ([#​255](https://togithub.com/dtolnay/thiserror/issues/255), thanks [`@​mina86](https://togithub.com/mina86))` ### [`v1.0.48`](https://togithub.com/dtolnay/thiserror/releases/tag/1.0.48) [Compare Source](https://togithub.com/dtolnay/thiserror/compare/1.0.47...1.0.48) - Improve implementation of displaying Path values in a generated Display impl ([#​251](https://togithub.com/dtolnay/thiserror/issues/251), thanks [`@​mina86](https://togithub.com/mina86))` </details> <details> <summary>unicode-rs/unicode-width (unicode-width)</summary> ### [`v0.1.11`](https://togithub.com/unicode-rs/unicode-width/compare/v0.1.10...v0.1.11) [Compare Source](https://togithub.com/unicode-rs/unicode-width/compare/v0.1.10...v0.1.11) </details> <details> <summary>BurntSushi/walkdir (walkdir)</summary> ### [`v2.4.0`](https://togithub.com/BurntSushi/walkdir/compare/2.3.3...2.4.0) [Compare Source](https://togithub.com/BurntSushi/walkdir/compare/2.3.3...2.4.0) </details> --- ### Configuration 📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4wLjMiLCJ1cGRhdGVkSW5WZXIiOiIzNy4wLjMiLCJ0YXJnZXRCcmFuY2giOiJtYXN0ZXIifQ==-->
For named types, I want to offer the potential alternative of using pattern destructuring as a potentially clearer alternative, e.g. struct A { x: i32, y: i32 }
struct B {
A { x, y }: A,
z: i32,
} (This would make As an aside, a different reasonable alternative interpretation of |
…r, r=davidtwco Lowering unnamed fields and anonymous adt This implements rust-lang#49804. Goals: - [x] lowering anonymous ADTs from AST to HIR - [x] generating definitions of anonymous ADTs - [x] uniqueness check of the unnamed fields - [x] field projection of anonymous ADTs - [x] `#[repr(C)]` check of the anonymous ADTs Non-Goals (will be in the next PRs) - capturing generic params for the anonymous ADTs from the parent ADT - pattern matching of anonymous ADTs - structural expressions of anonymous ADTs - rustdoc support of anonymous ADTs
This comment was marked as resolved.
This comment was marked as resolved.
Unresolved question: what should OTOH I assume many of them don't support unions to begin with, and these unnamed fields only really make sense when there are unions involved I think? The RFC also explicitly lists anonymous types as a rejected alternative, and yet the implementation that recently began for this RFC does introduce anonymous ADTs to the compiler. Though maybe if it is impossible to write an expression of these types they are less problematic? That said I assume in the internal compiler IRs such expressions will exist -- the unnamed fields are getting an internal name and field accesses are desugared to use those names. It's that kind of issue that makes me think that adding a new form of unnamed types to Rust (on top of closures/coroutines) is a mistake. The RFC was accepted 6 years ago, our approach to language design and evolution changed since then. I think we need to ensure that this is even still something we want to do in this form. |
Nominating Ralf's comment for T-lang discussion. Context for T-lang: There's currently active compiler dev going on to implement this feature (several merged and open PRs by multiple contributors). I don't want them to continue working on it if it gets thrown out in the end. |
I think this is the wrong implementation approach. The RFC doesn't specify the introduction of any new types. My expectation would be that this feature would be implemented by storing the field list in a tree structure instead of a flat list, for example in |
If they give rise to "tree-shaped types" then should we enforce the tree to strictly alternate between struct and union, i.e., not accept struct fields inside a struct or union fields inside a union? Those would be redundant then and give rise to questions like whether they actually change how the layout is computed. Also, that would require pretty fundamental changes to struct S {
f1: bool,
_: union { f2: u8, f3: u8 }
} Should this entire type behave like a union (any byte sequence is valid), or should the first field still behave like it would inside a struct (must always be a valid All of this would be trivially resolved by allowing unnamed fields with named types only. Or, you know, just naming those fields; very little code has to interact with these complicated C types directly and they can just generate names for these fields and spell them out, making the traversal of this tree-shaped structure explicit. That would also make it much easier to reason about the code, e.g. by making it clear when two fields might overlap. Given that such types are already rare in C (people seem to always use the same 2 or 3 examples when motivating this feature), and writing C bindings is rare in Rust (in the sense that picking some random piece of Rust code, it's rare for that to be C binding code), I think a feature exclusively meant to support such a small fraction of code needs to pass a pretty high bar. The RFC does not seem to have a "prior work" section so I can only assume that thus far, no language besides C (and C++?) has this feature, further confirming my impression that it serves an extremely niche use-case. |
Doesn't it? Imho it's clear from the text, that the validity requirements are the same as if you had named fields with separately defined types. The only thing the RFC does is allow omitting explicit type definition and the corresponding field name in accesses:
I hope not. This feature would allow structural inheritance for structs and unions. That feature would be useful e.g. for representation of C++-like class hierarchy, where subclasses have the fields of superclasses as their initial segments. For unions, it would allow patterns like ad-hoc subtyping of enums and hand-crafted ad-hoc sum types, like the ones OCaml uses to represent its errors. |
That's outside the scope and motivation of the RFC, and the feature is likely a poor fit for this purpose. IMO that's an argument in favor of requiring strict alternation. |
The scope of the RFC is representation of C FFI type without introducing types and field names which don't exist in original code. Anonymous structs can appear inside structs in C, same for unions, so that is explicitly within the scope and motivation of RFC. |
FWIW I offhandedly suggested a conflicting(?) interpretation of this syntax in IRLO a short while ago: https://internals.rust-lang.org/t/phantom-trait/20434/15?u=simonbuchan TLDR:
Where the compiler can implicitly initialize some sensible set of types ( Strictly I guess this use of the syntax doesn't conflict if such types are considered to be empty types somehow? |
It seems that implementation work (#121553) is blocked on the lang team nomination, so it would be nice to clarify what the exact question being asked here is. The libc 1.0 work (rust-lang/libc#3248) is currently blocked on this feature since we would like to make the APIs match C more closely. This is specifically useful for APIs where the field organization can vary between platforms, where some platforms use nested unions but others use distinct fields. |
|
I wasn't aware that this had already been discussed since this issue is still marked as lang-nominated. I know this was a while ago, but it would be nice if @compiler-errors or someone else could summarize the position of the lang team on this feature. |
It sounds like, from the minutes, that some folks would like to see this feature designed differently than it was when it was previously accepted. It wouldn't be the first or last feature to need some design adjustments when lang design met compiler reality. Happy to help with that, so that we can find a design that meets the requirements in the original RFC and any new issues that have arisen since then. |
Note that with the proposal as specified in the RFC, this leads to the same code being safe on some platforms and unsafe on others. IMO some C APIs are just too terrible for us to want to support matching them in Rust. I'm not saying we shouldn't support interop with those platforms -- we always should support interop. We added untagged unions, a major non-trivial language feature, largely to support C interop. So these APIs can be translated to named structs/unions. A consistent API across platforms can be achieved via methods. That's different from what happens in C, but it is not a good idea to copy mistakes (in my eyes) from C just because we want to have APIs that look the same. "It has to match the C API" is a great recipe for being forever stuck with poor choices made decades ago. IMO a new language feature needs stronger motivation than that. |
This is a tracking issue for the RFC "Unnamed fields of struct and union type" (rust-lang/rfcs#2102).
The feature gate for the issue is
#![feature(unnamed_fields)]
.About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
Unresolved questions
None so far.
Implementation history
unnamed_fields
during HIR analysis #121198The text was updated successfully, but these errors were encountered: