Skip to content

miri/const eval: support MaybeDangling#150446

Merged
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
WaffleLapkin:miri-maybe-dangling
Mar 9, 2026
Merged

miri/const eval: support MaybeDangling#150446
rust-bors[bot] merged 1 commit intorust-lang:mainfrom
WaffleLapkin:miri-maybe-dangling

Conversation

@WaffleLapkin
Copy link
Member

@WaffleLapkin WaffleLapkin commented Dec 27, 2025

View all comments

r? RalfJung

@rustbot
Copy link
Collaborator

rustbot commented Dec 27, 2025

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The Miri subtree was changed

cc @rust-lang/miri

@rustbot 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 Dec 27, 2025
@rust-log-analyzer

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@theemathas
Copy link
Contributor

Does this have insta-stable behavior change for ManuallyDrop in consteval?

@WaffleLapkin WaffleLapkin marked this pull request as draft December 28, 2025 13:42
@rustbot 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 Dec 28, 2025
@RalfJung
Copy link
Member

It should only affect the behavior of code that still has UB until MaybeDangling is stabilized.

@RalfJung
Copy link
Member

RalfJung commented Jan 4, 2026

It is very import that we land #150447 before landing this, to avoid a situation where we generate LLVM IR with UB but Miri reports no UB.

@RalfJung RalfJung added the S-blocked Status: Blocked on something else such as an RFC or other implementation work. label Jan 4, 2026
@WaffleLapkin WaffleLapkin force-pushed the miri-maybe-dangling branch 2 times, most recently from e5b7d00 to 959b31b Compare February 26, 2026 14:28
@WaffleLapkin WaffleLapkin marked this pull request as ready for review February 26, 2026 16:28
@rustbot 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
@WaffleLapkin
Copy link
Member Author

@RalfJung I think I've addressed the review comments and this is ready for review too :)

(still blocked on the compiler change though)

Copy link
Member

@RalfJung RalfJung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, thanks! All nits are minor.

View changes since this review

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't even a borrow checking thing. Please move the test to tests/fail/validity and have it disable Stacked Borrows to ensure we don't rely on the aliasing model for catching this.

}
}
ty::Adt(adt, _) if adt.is_maybe_dangling() => {
let could_dangle = mem::replace(&mut self.may_dangle, true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
let could_dangle = mem::replace(&mut self.may_dangle, true);
let old_may_dangle = mem::replace(&mut self.may_dangle, true);

Ub(DanglingIntPointer { addr: 0, .. }) => NullPtr { ptr_kind, maybe: false },
Ub(DanglingIntPointer { addr: i, .. }) => DanglingPtrNoProvenance {
ptr_kind,
// FIXME this says "null pointer" when null but we need translate
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// FIXME this says "null pointer" when null but we need translate

While we're at it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment doesn't make sense any more since we're skipping that part when may_dangle is true.

Comment on lines 544 to 545
// Make sure this is non-null. We checked dereferenceability above, but if `size` is zero
// that does not imply non-null.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Make sure this is non-null. We checked dereferenceability above, but if `size` is zero
// that does not imply non-null.
// Make sure this is non-null. This is obviously needed when `may_dangle` is set,
// but even if we did check dereferenceability above that would still allow null
// pointers if `size` is zero.

Copy link
Member

@RalfJung RalfJung Mar 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that this case was contentious, please also add a test like

// Under the current models, we do not forbid writing through
// `MaybeDangling<&i32>`. That's not yet finally decided, but meanwhile
// ensure we document this and notice when it changes.
fn write_through_shr(x: MaybeDangling<&i32>) {
  let y: *mut i32 = transmute(x);
  y.write(1);
}

let mutref = &mut 0i32;
write_through_shr(transmute(mutref));

@rust-log-analyzer

This comment has been minimized.

@WaffleLapkin WaffleLapkin force-pushed the miri-maybe-dangling branch 3 times, most recently from 7b01b7c to 4a26802 Compare March 6, 2026 16:38
@WaffleLapkin
Copy link
Member Author

@RalfJung I think I addressed your nits, unless I missed something ^^'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant for this to just be a new test in the other file -- no reason to split it up.

@WaffleLapkin WaffleLapkin force-pushed the miri-maybe-dangling branch from 4a26802 to 76a750a Compare March 9, 2026 11:36
@rustbot
Copy link
Collaborator

rustbot commented Mar 9, 2026

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.

@WaffleLapkin
Copy link
Member Author

@rustbot review

@rustbot 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 Mar 9, 2026
@RalfJung
Copy link
Member

RalfJung commented Mar 9, 2026

Awesome, thanks a lot!
@bors r+

@rust-bors
Copy link
Contributor

rust-bors bot commented Mar 9, 2026

📌 Commit 76a750a has been approved by RalfJung

It is now in the queue for this repository.

@rust-bors rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 9, 2026
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 9, 2026
…r=RalfJung

miri/const eval: support `MaybeDangling`

r? RalfJung
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 9, 2026
…r=RalfJung

miri/const eval: support `MaybeDangling`

r? RalfJung
JonathanBrouwer added a commit to JonathanBrouwer/rust that referenced this pull request Mar 9, 2026
…r=RalfJung

miri/const eval: support `MaybeDangling`

r? RalfJung
rust-bors bot pushed a commit that referenced this pull request Mar 9, 2026
…uwer

Rollup of 4 pull requests

Successful merges:

 - #147834 (Always make tuple elements a coercion site)
 - #150446 (miri/const eval: support `MaybeDangling`)
 - #153053 (stop marking `deref_patterns` as an incomplete feature)
 - #153398 (fix ICE in `const_c_variadic` when passing ZSTs)
rust-bors bot pushed a commit that referenced this pull request Mar 9, 2026
…uwer

Rollup of 4 pull requests

Successful merges:

 - #147834 (Always make tuple elements a coercion site)
 - #150446 (miri/const eval: support `MaybeDangling`)
 - #153053 (stop marking `deref_patterns` as an incomplete feature)
 - #153398 (fix ICE in `const_c_variadic` when passing ZSTs)
@rust-bors rust-bors bot merged commit 8fc4e47 into rust-lang:main Mar 9, 2026
11 checks passed
@rustbot rustbot added this to the 1.96.0 milestone Mar 9, 2026
rust-timer added a commit that referenced this pull request Mar 9, 2026
Rollup merge of #150446 - WaffleLapkin:miri-maybe-dangling, r=RalfJung

miri/const eval: support `MaybeDangling`

r? RalfJung
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Mar 10, 2026
…uwer

Rollup of 4 pull requests

Successful merges:

 - rust-lang/rust#147834 (Always make tuple elements a coercion site)
 - rust-lang/rust#150446 (miri/const eval: support `MaybeDangling`)
 - rust-lang/rust#153053 (stop marking `deref_patterns` as an incomplete feature)
 - rust-lang/rust#153398 (fix ICE in `const_c_variadic` when passing ZSTs)
@WaffleLapkin WaffleLapkin deleted the miri-maybe-dangling branch March 10, 2026 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants