Implement the unsafe-fields RFC. #132915

veluca93 · 2024-11-11T18:25:19Z

RFC: rust-lang/rfcs#3458

Tracking:

Tracking issue for RFC 3458: Unsafe fields #132922

r? jswrenn

rustbot · 2024-11-11T18:25:29Z

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

rustbot · 2024-11-11T19:20:45Z

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

jswrenn

Thanks for implementing this! Here's a first round of comments. :-)

compiler/rustc_feature/src/unstable.rs

compiler/rustc_metadata/src/rmeta/encoder.rs

compiler/rustc_mir_build/src/check_unsafety.rs

compiler/rustc_feature/src/unstable.rs

jswrenn · 2024-11-12T17:24:09Z

@bors try @rust-timer queue

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

bors · 2024-11-12T17:25:21Z

⌛ Trying commit db32d80 with merge ce25ffa...

bors · 2024-11-12T19:09:46Z

☀️ Try build successful - checks-actions
Build commit: ce25ffa (ce25ffa95be3a8577d9d1ff09eafe449df2dcfc3)

rust-timer · 2024-11-12T20:36:56Z

Finished benchmarking commit (ce25ffa): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.0%	[0.0%, 0.0%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.2%	[-1.2%, -1.2%]	1
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -0.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.8%	[1.8%, 1.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.1%	[-3.1%, -3.1%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.7%	[-3.1%, 1.8%]	2

Cycles

Results (secondary 1.7%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.7%	[1.7%, 1.7%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary 0.2%, secondary 0.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.0%, 0.5%]	128
Regressions ❌ (secondary)	0.3%	[0.0%, 0.5%]	29
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.2%	[0.0%, 0.5%]	128

Bootstrap: 787.726s -> 783.8s (-0.50%)
Artifact size: 335.35 MiB -> 335.31 MiB (-0.01%)

jswrenn · 2024-11-19T17:48:11Z

The UI testing checklist I'd like to see completed before we merge this:

if feature(unsafe_fields):
- the 'incomplete features' warning is emitted
- unsafe can be applied to the fields of struct-like variant fields of structs, enums and unions
  - the unsafe field's type must be Copy or ManuallyDrop
- unsafe cannot be applied to tuple-like struct fields
- unsafe cannot be applied to tuple-like enum fields
if not feature(unsafe_fields), even in cfg'd-out code:
- unsafe cannot be applied to the fields of struct-like struct fields
- unsafe cannot be applied to the fields of struct-like enum fields
- unsafe cannot be applied to the fields of struct-like (i.e., all) unions
even if not feature(unsafe_fields):
- initializing, destructuring, referencing, reading, and writing the unsafe fields of a struct/enum/union can only occur in an unsafe context (see these tests as a rough point of reference)
- initializing, destructuring, referencing, reading, and writing the safe fields of a struct/enum/union (even one that that has other unsafe fields) does not require unsafe

rustbot · 2024-11-20T00:47:11Z

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

bors · 2024-11-20T09:28:50Z

☔ The latest upstream changes (presumably #133212) made this pull request unmergeable. Please resolve the merge conflicts.

compiler/rustc_hir_analysis/src/check/check.rs

tests/ui/feature-gates/feature-gate-unsafe_fields.rs

compiler/rustc_metadata/src/rmeta/encoder.rs

bors · 2024-11-21T10:58:27Z

☔ The latest upstream changes (presumably #133280) made this pull request unmergeable. Please resolve the merge conflicts.

jswrenn

This is looking pretty good. Be sure to update the commit message, too! It's no longer a draft implementation — it's just an implementation. :-)

tests/ui/feature-gates/feature-gate-unsafe_fields.rs

tests/ui/unsafe-fields.rs

jswrenn · 2024-11-21T14:24:54Z

tests/ui/unsafe-fields.rs

+    safe_field: u32,
+}
+
+impl WithUnsafeField {


Can you add a test tracking the behavior of this:

&raw const self.unsafe_field

I think (but am not completely certain) it's safe, but we should probably require unsafe in the initial implementation.

I think I would prefer this to be unsafe -- of course, to do something with the result of this that could possibly cause problems requires some other form of unsafe somewhere else (I think...), but making this unsafe is IMO nice because it improves locality-of-safety:

let ptr = &raw const self.unsafe_field; // lots of code unsafe { do_something_with_ptr }

I think it'd be nice to have some sign somewhere that ptr actually comes from an unsafe field.

I think (but am not completely certain) it's safe

It's not safe. All field accesses are "inbounds", so they need to point to valid memory to even take the offset.

See rust-lang/opsem-team#10

Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>

compiler-errors

Generally looks okay. I've got some minor comments about style and code deduplication.

compiler-errors · 2024-11-21T16:36:14Z

compiler/rustc_parse/src/parser/item.rs

+    fn parse_unsafe_field(&mut self) -> Safety {
+        // not using parse_safety as that also accepts `safe`.
+        if self.eat_keyword(kw::Unsafe) {
+            let span = self.prev_token.uninterpolated_span();


Why are you gating the uninterpolated span? Everywhere else in the parser seems to gate on prev_token.span.

compiler-errors · 2024-11-21T16:43:12Z

compiler/rustc_mir_build/src/check_unsafety.rs

                if let ty::Adt(adt_def, ..) = pat.ty.kind() {
+                    for pat in subpatterns {
+                        let field = &pat.field;
+                        if adt_def.variants().iter().next().unwrap().fields[*field].safety


I think you should use non_enum_variant here:

Suggested change

if adt_def.variants().iter().next().unwrap().fields[*field].safety

if adt_def.non_enum_variant().fields[*field].safety

I don't think(?) we use PatKind::Leaf for enums ever.

compiler-errors · 2024-11-21T16:44:11Z

compiler/rustc_mir_build/src/check_unsafety.rs

                if let ty::Adt(adt_def, ..) = pat.ty.kind() {
+                    for pat in subpatterns {
+                        let field = &pat.field;


Why are you taking a ref of a FieldIdx, just to deref it below?

Just inline this into the .fields[&pat.field] below.

compiler-errors · 2024-11-21T16:45:16Z

compiler/rustc_metadata/src/rmeta/encoder.rs

@@ -1599,6 +1599,10 @@ impl<'a, 'tcx> EncodeContext<'a, 'tcx> {
                f.did.index
            }));

+            for field in &variant.fields {
+                self.tables.safety.set_some(field.did.index, field.safety);


record!(self.tables.safety[field.did] <- field.safety);

compiler-errors · 2024-11-21T16:47:02Z

compiler/rustc_hir_analysis/src/check/check.rs

+    for variant in def.variants() {
+        for field in &variant.fields {


This can be a single for loop with def.all_fields().

compiler-errors · 2024-11-21T16:47:40Z

compiler/rustc_hir_analysis/src/check/check.rs

+                continue;
+            };
+
+            if !allowed_union_or_unsafe_field(field_ty, tcx, typing_env) {


tiny nit: always pass tcx as the first field

compiler-errors · 2024-11-21T16:48:38Z

compiler/rustc_hir_analysis/src/check/check.rs

+                let (field_span, ty_span) = match tcx.hir().get_if_local(field.did) {
+                    // We are currently checking the type this field came from, so it must be local.
+                    Some(Node::Field(field)) => (field.span, field.ty.span),
+                    _ => unreachable!("mir field has to correspond to hir field"),


This comment doesn't really make sense. This isn't a "MIR" field, it's just the middle typing layer.

I think this can be simplified to field.did.expect_local(), though, no need for the match.

compiler-errors · 2024-11-21T16:49:26Z

compiler/rustc_hir_analysis/src/check/check.rs

+            } else if field_ty.needs_drop(tcx, typing_env) {
+                // This should never happen. But we can get here e.g. in case of name resolution errors.
+                tcx.dcx()
+                    .span_delayed_bug(span, "we should never accept maybe-dropping union fields");


union -> unsafe?

also, this could perhaps be moved into allowed_union_or_unsafe_field to deduplicate this logic further.

compiler-errors · 2024-11-21T16:50:36Z

compiler/rustc_hir_analysis/src/check/check.rs

@@ -1464,6 +1506,7 @@ fn check_enum(tcx: TyCtxt<'_>, def_id: LocalDefId) {

    detect_discriminant_duplicate(tcx, def);
    check_transparent(tcx, def);
+    check_unsafe_fields(tcx, tcx.def_span(def_id), def_id);


no need to pass the def span of the def id we're already passing in.

rustbot assigned jswrenn Nov 11, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 11, 2024

This comment has been minimized.

Sign in to view

veluca93 force-pushed the unsafe-fields branch from 4cbe0ee to 2cda185 Compare November 11, 2024 19:20

jswrenn requested changes Nov 11, 2024

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 11, 2024

This comment has been minimized.

Sign in to view

veluca93 force-pushed the unsafe-fields branch from 2cda185 to e83abf1 Compare November 11, 2024 20:12

This comment has been minimized.

Sign in to view

veluca93 force-pushed the unsafe-fields branch from e83abf1 to d25841e Compare November 11, 2024 20:52

This comment has been minimized.

Sign in to view

veluca93 force-pushed the unsafe-fields branch from d25841e to 6a5fbe3 Compare November 11, 2024 21:32

traviscross mentioned this pull request Nov 11, 2024

Tracking issue for RFC 3458: Unsafe fields #132922

Open

7 tasks

jswrenn requested changes Nov 11, 2024

View reviewed changes

compiler/rustc_feature/src/unstable.rs Outdated Show resolved Hide resolved

veluca93 force-pushed the unsafe-fields branch 2 times, most recently from ff9aee3 to db32d80 Compare November 11, 2024 23:33

This comment has been minimized.

Sign in to view

rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 12, 2024

bors added a commit to rust-lang-ci/rust that referenced this pull request 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

This comment has been minimized.

Sign in to view

rustbot removed the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Nov 12, 2024

veluca93 force-pushed the unsafe-fields branch from db32d80 to 44c1339 Compare November 20, 2024 00:47

This comment has been minimized.

Sign in to view

veluca93 force-pushed the unsafe-fields branch from 44c1339 to c133735 Compare November 20, 2024 07:54

veluca93 force-pushed the unsafe-fields branch from c133735 to 3a0a424 Compare November 20, 2024 09:36

jswrenn requested changes Nov 20, 2024

View reviewed changes

veluca93 force-pushed the unsafe-fields branch from 3a0a424 to b5d31a4 Compare November 20, 2024 21:26

traviscross added the F-unsafe_fields `#![feature(unsafe_fields)]` label Nov 20, 2024

veluca93 requested a review from jswrenn November 21, 2024 01:19

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 21, 2024

veluca93 force-pushed the unsafe-fields branch from b5d31a4 to 94e9d7e Compare November 21, 2024 11:32

jswrenn requested changes Nov 21, 2024

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 21, 2024

veluca93 force-pushed the unsafe-fields branch from 94e9d7e to 0ddfeb9 Compare November 21, 2024 14:47

This comment has been minimized.

Sign in to view

Implement the unsafe-fields RFC.

d796143

Co-Authored-By: Jacob Pratt <jacob@jhpratt.dev>

veluca93 force-pushed the unsafe-fields branch from 0ddfeb9 to d796143 Compare November 21, 2024 15:37

veluca93 changed the title ~~Draft implementation of unsafe-fields.~~ Implement the unsafe-fields RFC. Nov 21, 2024

compiler-errors requested changes Nov 21, 2024

View reviewed changes

	if adt_def.variants().iter().next().unwrap().fields[*field].safety
	if adt_def.non_enum_variant().fields[*field].safety

		for variant in def.variants() {
		for field in &variant.fields {

Implement the unsafe-fields RFC. #132915

Are you sure you want to change the base?

Implement the unsafe-fields RFC. #132915

Conversation

veluca93 commented Nov 11, 2024 • edited by traviscross Loading

rustbot commented Nov 11, 2024

This comment has been minimized.

rustbot commented Nov 11, 2024

jswrenn left a comment

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

jswrenn commented Nov 12, 2024

This comment has been minimized.

bors commented Nov 12, 2024

bors commented Nov 12, 2024

This comment has been minimized.

rust-timer commented Nov 12, 2024

Overall result: ❌✅ regressions and improvements - no action needed

jswrenn commented Nov 19, 2024

rustbot commented Nov 20, 2024

This comment has been minimized.

bors commented Nov 20, 2024

bors commented Nov 21, 2024

jswrenn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors Nov 21, 2024 • edited Loading

Choose a reason for hiding this comment

This comment has been minimized.

compiler-errors left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors Nov 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors Nov 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

veluca93 commented Nov 11, 2024 •

edited by traviscross

Loading

compiler-errors Nov 21, 2024 •

edited

Loading

compiler-errors Nov 21, 2024 •

edited

Loading

compiler-errors Nov 21, 2024 •

edited

Loading