Implement `MaybeDangling` compiler support by WaffleLapkin · Pull Request #150447 · rust-lang/rust

WaffleLapkin · 2025-12-27T21:16:15Z

Tracking issue: #118166

cc @RalfJung

tests/codegen-llvm/manually_drop_refs.rs

compiler/rustc_middle/src/ty/layout.rs

rustbot · 2026-02-26T15:58:58Z

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in tests/codegen-llvm/sanitizer

cc @rcvalle

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

rustbot · 2026-02-26T15:59:00Z

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler, types
compiler, types expanded to 68 candidates
Random selection from 14 candidates

WaffleLapkin · 2026-02-26T15:59:48Z

@RalfJung this is finally ready for review :)

Let me know if you'd prefer the PointeeInfo changes in a separate PR.

RalfJung

This looks generally great, thanks! Nice cleanup for getting rid of those align 1 everywhere.

I left some comments. I don't understand why the may_dangle field exists. Please resolve the conflicts so we can do a perf run.

View changes since this review

compiler/rustc_abi/src/lib.rs

compiler/rustc_middle/src/ty/layout.rs

RalfJung · 2026-03-01T16:05:10Z

compiler/rustc_middle/src/ty/layout.rs

+                if offset.bytes() == 0
+                    && let Some(pointee) = this.ty.boxed_ty() =>
+            {
                let optimize = tcx.sess.opts.optimize != OptLevel::No;


let optimize looks like it could be moved out of the match.

The let optimize = ... line itself is still there, now shadowing the one you put outside the match.

compiler/rustc_middle/src/ty/layout.rs

compiler/rustc_ty_utils/src/abi.rs

compiler/rustc_abi/src/lib.rs

rustbot · 2026-03-02T13:43:06Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

theemathas · 2026-03-02T14:25:59Z

This PR can result in stable code using ManuallyDrop getting less optimization, right?

WaffleLapkin · 2026-03-02T14:27:42Z

@theemathas yes. Importantly also less UB ^^'

RalfJung · 2026-03-02T15:14:58Z

Indeed, that is the intent of this PR. ;)

Note that this PR does not guarantee the absence of those optimizations on stable. It only guarantees it for code that uses MaybeDangling directly, which remains unstable.

Make `size`/`align` always correct rather than conditionally on the `safe` field. This makes it less error prone and easier to work with for `MaybeDangling` / potential future pointer kinds like `Aligned<_>`.

Instead of defaulting to `None` it now defaults to `Align::ONE` i.e. no alignment restriction. Codegen test changes are due to us now skipping `align 1` annotations (they are useless; not skipping them makes all the raw pointers gain an `align 1` annotation which doesn't seem any good)

RalfJung · 2026-03-02T17:04:24Z

compiler/rustc_ty_utils/src/abi.rs

-// Handle safe Rust thin and wide pointers.
+/// Returns argument attributes for a scalar argument.
+///
+/// `drop_target_pointee` is used to special-case the argument of `ptr::drop_in_place`,


Suggested change

/// `drop_target_pointee` is used to special-case the argument of `ptr::drop_in_place`,

/// `drop_target_pointee`, if set, causes the scalar, if it is a pointer, to be treated as a mutable

/// reference to the given type. This is used to special-case the argument of `ptr::drop_in_place`,

This is unlike before where that treatment only happened if the scalar was by itself not already a safe pointer -- right?

if it is a pointer

that is not quite correct, we have an assertion that it's a pointer, not a check.

This is unlike before where that treatment only happened if the scalar was by itself not already a safe pointer -- right?

Yes, before it happened if the scalar was a pointer, and specifically a raw one.

Okay, please make the docs whatever the correct thing is then. :)

RalfJung · 2026-03-02T17:06:58Z

tests/codegen-llvm/manually_drop_refs.rs

Please add a test (or extend an existing one) ensuring that MaybeDangling<&T> is not marked with captures or readonly, with a comment pointing this out as a relevant thing to test.

I wonder if it would make sense to make the tests like tests/codegen-llvm/function-arguments.rs where we actually list all the attributes so that we can easily notice when they change? The fact that I didn't realize that we are setting readdonly captures on these references concerns me.

The reason I made the test like I did is that the differences between local and ci llvm were driving me insane trying to write a test that works on both of them ^^'

I'll look at function-argument.rs

Are you sure that MaybeDangling<&T> actually need to strip captures and readonly? Those do not imply any validity invariants, and effectively only cause restrictions on any &Ts that get extracted out of the MaybeDangling and how they can be used.

That being said, I do not know what the miri paragraph in the RFC is saying because I don't know off the top of my head what retagging is, so... sorry if that's related to the answer to my question (though, even then I feel like this should be spelled out more explicitly).

Are you sure that MaybeDangling<&T> actually need to strip captures and readonly?

For the model implemented in #150446, yes. So I'd say let's implement that model for now because it's the one we have and know how to implement; I have added this as an open question in the tracking issue.

Those do not imply any validity invariants

They do. They have to come from somewhere, after all.

RalfJung · 2026-03-02T17:07:50Z

compiler/rustc_middle/src/ty/layout.rs

+                        safe: None,
+                        // Make sure we don't assert dereferenceability of the pointer.
+                        size: Size::ZERO,
+                        ..info


Suggested change

..info

// Preserve the alignment assertion! That is required even inside `MaybeDangling`.

..info

RalfJung · 2026-03-02T17:08:08Z

tests/codegen-llvm/manually_drop_refs.rs

Also, why does this test ManuallyDrop? The actually relevant type is MaybeDangling.

(it's because that's the currently stable type that users care about)

Will change it though, no real reason to test ManuallyDrop

RalfJung · 2026-03-02T17:09:10Z

compiler/rustc_middle/src/ty/adt.rs

        /// Indicates whether the type is `FieldRepresentingType`.
        const IS_FIELD_REPRESENTING_TYPE    = 1 << 13;
+        /// Indicates whether the type is `MaybeDangling<_>`.
+        const IS_MAYBE_DANGLING             = 1 << 14;


Most of these are mutually exclusive so it is a huge waste of bits to have a separate bit for each of them... 🤷 that's pre-existing though, not for this PR to fix.

WaffleLapkin force-pushed the maybe-dangling-semantics branch 2 times, most recently from aebfd56 to 63e07cf Compare December 27, 2025 21:28

This comment has been minimized.

Sign in to view

RalfJung reviewed Dec 28, 2025

View reviewed changes

tests/codegen-llvm/manually_drop_refs.rs Show resolved Hide resolved

RalfJung reviewed Dec 28, 2025

View reviewed changes

compiler/rustc_middle/src/ty/layout.rs Outdated Show resolved Hide resolved

RalfJung mentioned this pull request Jan 4, 2026

miri/const eval: support MaybeDangling #150446

Open

WaffleLapkin force-pushed the maybe-dangling-semantics branch from 63e07cf to c40ca7d Compare February 19, 2026 14:35

This comment has been minimized.

Sign in to view

rustbot added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Feb 19, 2026

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch from 6d96bdb to d71787d Compare February 19, 2026 18:35

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch 2 times, most recently from f6fafff to baa9118 Compare February 19, 2026 23:25

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch from baa9118 to c135ac1 Compare February 23, 2026 16:07

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch from c135ac1 to f399322 Compare February 25, 2026 23:07

rustbot added the PG-exploit-mitigations Project group: Exploit mitigations label Feb 25, 2026

WaffleLapkin force-pushed the maybe-dangling-semantics branch 3 times, most recently from 8bbf80d to a72a3f3 Compare February 25, 2026 23:34

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch from a72a3f3 to 42ce338 Compare February 26, 2026 12:26

This comment has been minimized.

Sign in to view

WaffleLapkin force-pushed the maybe-dangling-semantics branch 2 times, most recently from 51a5c77 to efc351d Compare February 26, 2026 13:52

WaffleLapkin marked this pull request as ready for review February 26, 2026 15:58

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 Feb 26, 2026

rustbot assigned fee1-dead Feb 26, 2026

This comment has been minimized.

Sign in to view

RalfJung requested changes Mar 1, 2026

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 Mar 1, 2026

add an adt flag for MaybeDangling

7cefcb4

WaffleLapkin force-pushed the maybe-dangling-semantics branch from efc351d to 8102f65 Compare March 2, 2026 13:43

WaffleLapkin added 5 commits March 2, 2026 16:48

refactor PointeeInfo

783fbca

Make `size`/`align` always correct rather than conditionally on the `safe` field. This makes it less error prone and easier to work with for `MaybeDangling` / potential future pointer kinds like `Aligned<_>`.

add a codegen-llvm test for ManuallyDrop

1a45ec7

add semantics to MaybeDangling

f65ad49

strip readonly/captures from MaybeDangling<&T>

62cbdee

WaffleLapkin force-pushed the maybe-dangling-semantics branch from 395a073 to 62cbdee Compare March 2, 2026 15:48

RalfJung reviewed Mar 2, 2026

View reviewed changes

	/// `drop_target_pointee` is used to special-case the argument of `ptr::drop_in_place`,
	/// `drop_target_pointee`, if set, causes the scalar, if it is a pointer, to be treated as a mutable
	/// reference to the given type. This is used to special-case the argument of `ptr::drop_in_place`,

	..info
	// Preserve the alignment assertion! That is required even inside `MaybeDangling`.
	..info

Uh oh!

Conversation

WaffleLapkin commented Dec 27, 2025 • edited by RalfJung Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

rustbot commented Feb 26, 2026

Uh oh!

rustbot commented Feb 26, 2026

Uh oh!

WaffleLapkin commented Feb 26, 2026

Uh oh!

This comment has been minimized.

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Mar 2, 2026

Uh oh!

theemathas commented Mar 2, 2026

Uh oh!

WaffleLapkin commented Mar 2, 2026

Uh oh!

RalfJung commented Mar 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

WaffleLapkin commented Dec 27, 2025 •

edited by RalfJung

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung Mar 2, 2026 •

edited

Loading

RalfJung Mar 2, 2026 •

edited

Loading