-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 3458: Unsafe fields #132922
Labels
B-experimental
Blocker: In-tree experiment; RFC pending, not yet approved or unneeded.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
F-unsafe_fields
`#![feature(unsafe_fields)]`
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
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 labels +I-lang-nominated Tracking issue created and nominated due to the request for a lang experiment here: |
rustbot
added
the
I-lang-nominated
Nominated for discussion during a lang team meeting.
label
Nov 11, 2024
fmease
added
the
B-experimental
Blocker: In-tree experiment; RFC pending, not yet approved or unneeded.
label
Nov 11, 2024
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Nov 12, 2024
Draft implementation of unsafe-fields. RFC: rust-lang/rfcs#3458 Tracking: - rust-lang#132922 r? jswrenn
We talked about this in our lang triage call today and approved this as an experiment. @joshtriplett is particularly enthusiastic about this work and is willing to liaison. |
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
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
Implement the unsafe-fields RFC. RFC: rust-lang/rfcs#3458 Tracking: - rust-lang/rust#132922 r? jswrenn
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 5, 2024
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.
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 5, 2024
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.
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 5, 2024
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.
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 5, 2024
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.
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 5, 2024
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.
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 6, 2024
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
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 6, 2024
… 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`
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 7, 2024
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`
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
jswrenn
added a commit
to jswrenn/rust
that referenced
this issue
Dec 7, 2024
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
fmease
added a commit
to fmease/rust
that referenced
this issue
Dec 9, 2024
…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`
fmease
added a commit
to fmease/rust
that referenced
this issue
Dec 10, 2024
…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``
fmease
added a commit
to fmease/rust
that referenced
this issue
Dec 10, 2024
…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```
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 10, 2024
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```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
B-experimental
Blocker: In-tree experiment; RFC pending, not yet approved or unneeded.
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
F-unsafe_fields
`#![feature(unsafe_fields)]`
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
This is a tracking issue for:
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
Unresolved Questions
TODO.
Related
TODO.
cc @jswrenn @veluca93 @jhpratt @rust-lang/lang
The text was updated successfully, but these errors were encountered: