Tracking issue for RFC 3458: Unsafe fields #132922

traviscross · 2024-11-11T23:14:48Z

This is a tracking issue for:

Unsafe fields rfcs#3458

The feature gate for the issue is #![feature(unsafe_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

Approve as lang experiment.
Accept an RFC.
- Unsafe fields rfcs#3458
Implement in nightly.
Add documentation to the dev guide.
- See the instructions.
Add documentation to the reference.
- See the instructions.
Add formatting for new syntax to the style guide.
- See the nightly style procedure.
Stabilize.
- See the instructions.

Unresolved Questions

TODO.

If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Makes progress towards rust-lang#132922.

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, it implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

… r=compiler-errors Do not implement unsafe auto traits for types with unsafe fields If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Consequently, auto implementations of unsafe auto traits should not be generated for types with unsafe fields. Tracking: rust-lang#132922 r? `@compiler-errors`

Rollup merge of rust-lang#133934 - jswrenn:unsafe-fields-auto-traits, r=compiler-errors Do not implement unsafe auto traits for types with unsafe fields If a type has unsafe fields, its safety invariants are not simply the conjunction of its field types' safety invariants. Consequently, it's invalid to reason about the safety properties of these types in a purely structural manner — i.e., the manner in which `auto` traits are implemented. Consequently, auto implementations of unsafe auto traits should not be generated for types with unsafe fields. Tracking: rust-lang#132922 r? `@compiler-errors`

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, it implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

…iler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? `@compiler-errors`

…iler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? ``@compiler-errors``

…iler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? ```@compiler-errors```

Rollup merge of rust-lang#134008 - jswrenn:unsafe-fields-copy, r=compiler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? ```@compiler-errors```

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

…iler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? ```@compiler-errors```

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

…iler-errors Make `Copy` unsafe to implement for ADTs with `unsafe` fields As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also entail `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922 r? ```@compiler-errors```

As a rule, the application of `unsafe` to a declaration requires that use-sites of that declaration also require `unsafe`. For example, a field declared `unsafe` may only be read in the lexical context of an `unsafe` block. For nearly all safe traits, the safety obligations of fields are explicitly discharged when they are mentioned in method definitions. For example, idiomatically implementing `Clone` (a safe trait) for a type with unsafe fields will require `unsafe` to clone those fields. Prior to this commit, `Copy` violated this rule. The trait is marked safe, and although it has no explicit methods, its implementation permits reads of `Self`. This commit resolves this by making `Copy` conditionally safe to implement. It remains safe to implement for ADTs without unsafe fields, but unsafe to implement for ADTs with unsafe fields. Tracking: rust-lang#132922

traviscross added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Nov 11, 2024

rustbot added the I-lang-nominated Nominated for discussion during a lang team meeting. label Nov 11, 2024

jswrenn mentioned this issue Nov 11, 2024

Implement the unsafe-fields RFC. #132915

Merged

fmease added the B-experimental Blocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stablize). label Nov 11, 2024

traviscross mentioned this issue Nov 12, 2024

Unsafe fields rust-lang/rfcs#3458

Open

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 12, 2024

Auto merge of rust-lang#132915 - veluca93:unsafe-fields, r=<try>

ce25ffa

Draft implementation of unsafe-fields. RFC: rust-lang/rfcs#3458 Tracking: - rust-lang#132922 r? jswrenn

CBenoit mentioned this issue Nov 14, 2024

feat(libxmf): expose libvpx,add rust examples with it Devolutions/cadeau#55

Merged

traviscross added F-unsafe_fields `#![feature(unsafe_fields)]` and removed I-lang-nominated Nominated for discussion during a lang team meeting. labels Nov 20, 2024

bors added a commit to rust-lang-ci/rust that referenced this issue Nov 23, 2024

Auto merge of rust-lang#132915 - veluca93:unsafe-fields, r=jswrenn

6e1c115

Implement the unsafe-fields RFC. RFC: rust-lang/rfcs#3458 Tracking: - rust-lang#132922 r? jswrenn

github-actions bot pushed a commit to rust-lang/miri that referenced this issue Nov 28, 2024

Auto merge of #132915 - veluca93:unsafe-fields, r=jswrenn

2355f12

Implement the unsafe-fields RFC. RFC: rust-lang/rfcs#3458 Tracking: - rust-lang/rust#132922 r? jswrenn

jswrenn mentioned this issue Dec 5, 2024

Do not implement unsafe auto traits for types with unsafe fields #133934

Merged

jswrenn mentioned this issue Dec 7, 2024

Make Copy unsafe to implement for ADTs with unsafe fields #134008

Merged

dtolnay mentioned this issue Dec 15, 2024

Parse unsafe fields dtolnay/syn#1792

Open

nikomatsakis added this to Lang team champions Feb 21, 2025

nikomatsakis moved this to Exploration in Lang team champions Feb 21, 2025

nikomatsakis assigned jswrenn and scottmcm Feb 21, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue for RFC 3458: Unsafe fields #132922

Tracking issue for RFC 3458: Unsafe fields #132922

traviscross commented Nov 11, 2024 •

edited by aDotInTheVoid

Loading

traviscross commented Nov 11, 2024 •

edited

Loading

traviscross commented Nov 20, 2024 •

edited

Loading

Tracking issue for RFC 3458: Unsafe fields #132922

Tracking issue for RFC 3458: Unsafe fields #132922

Comments

traviscross commented Nov 11, 2024 • edited by aDotInTheVoid Loading

About tracking issues

Steps

Unresolved Questions

Related

traviscross commented Nov 11, 2024 • edited Loading

traviscross commented Nov 20, 2024 • edited Loading

traviscross commented Nov 11, 2024 •

edited by aDotInTheVoid

Loading

traviscross commented Nov 11, 2024 •

edited

Loading

traviscross commented Nov 20, 2024 •

edited

Loading