Skip to content

Conversation

@WaffleLapkin
Copy link
Member

This is the library part of adding MaybeDangling. Note that it doesn't actually do anything described in its docs (yet), I'll make a separate PR for that.

Tracking issue: #118166.

r? libs
cc @RalfJung

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Dec 8, 2025
@WaffleLapkin WaffleLapkin marked this pull request as ready for review December 8, 2025 15:49
@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 Dec 8, 2025
@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Dec 10, 2025

The Miri subtree was changed

cc @rust-lang/miri

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.

Thanks for working on this :-)

View changes since this review

@rustbot

This comment has been minimized.

@rustbot

This comment was marked as resolved.

@rustbot rustbot added has-merge-commits PR has merge commits, merge with caution. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 13, 2025
@WaffleLapkin WaffleLapkin force-pushed the core-mem-maybe-dangling branch from c7db108 to 95eee60 Compare December 13, 2025 13:16
@rustbot
Copy link
Collaborator

rustbot commented Dec 13, 2025

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.

@rustbot rustbot removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. has-merge-commits PR has merge commits, merge with caution. labels Dec 13, 2025
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a comment

Choose a reason for hiding this comment

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

r=me in general with commits squashed, possibly comments addressed (happy to leave specifics up to you)

View changes since this review

///
/// Even though the `Box`e's destructor is not run (and thus we don't have a double free bug), this
/// code is still UB. This is because when moving `boxed` into `forget`, its validity invariants
/// are asserted, causing UB since the `Box` is dangling.
Copy link
Member

Choose a reason for hiding this comment

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

Maybe worth clarifying, e.g., "The safety comment is as such wrong, as moving the boxed variable as part of the call is a use"?

/// **not** dangling -- functions like [`as_ref`] and [`into_inner`] are safe. It is not sound to
/// return a dangling reference in a `MaybeDangling` to safe code. However, it *is* sound
/// to hold such values internally inside your code -- and there's no way to do that without
/// this type.
Copy link
Member

Choose a reason for hiding this comment

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

It sounds like there are alternatives to this type, though, right? Is it worth saying something about ManuallyDrop or some other construct that's already stable?

Copy link
Member

Choose a reason for hiding this comment

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

Hm... yeah fair, some other types will use this type and thus get the same effect; in particular, ManuallyDrop.

/// (and [boxes]) still must be aligned and non-null.
///
/// Additionally note that safe code can still assume that the inner value in a `MaybeDangling` is
/// **not** dangling -- functions like [`as_ref`] and [`into_inner`] are safe. It is not sound to
Copy link
Member

Choose a reason for hiding this comment

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

How do we deal with the implicit Drop for the inner type? Should callers who place e.g. a dangling Box inside just be careful to call forget rather than letting it Drop?


use crate::{mem, ptr};

/// Allows wrapped [references] and [boxes] to dangle.
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a "Not yet actually implemented" or perhaps make maybe_dangling an incomplete lang feature? I worry a bit that as of this PR, from what I can tell, this is UB to use as documented, right? Since the compiler bits aren't there yet.

WaffleLapkin and others added 2 commits December 17, 2025 22:26
@WaffleLapkin WaffleLapkin force-pushed the core-mem-maybe-dangling branch from 95eee60 to 25476d8 Compare December 17, 2025 21:28
@WaffleLapkin
Copy link
Member Author

I think I've addressed all the review comments.
@bors r=Mark-Simulacrum

@bors
Copy link
Collaborator

bors commented Dec 17, 2025

📌 Commit 25476d8 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@bors bors 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 Dec 17, 2025
bors added a commit that referenced this pull request Dec 17, 2025
…Simulacrum

Add `MaybeDangling` to `core`

This is the library part of adding `MaybeDangling`. Note that it doesn't actually do anything described in its docs (yet), I'll make a separate PR for that.

Tracking issue: #118166.

r? libs
cc `@RalfJung`
@bors
Copy link
Collaborator

bors commented Dec 17, 2025

⌛ Testing commit 25476d8 with merge 3d0287a...

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Collaborator

bors commented Dec 17, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Dec 17, 2025
- fixup `BTreeMap` gdb provider
- fixup `ManuallyDrop` natvis thingy

Now that `MaybeUninit` contains `ManuallyDrop` which contains
`MaybeDangling` (tbc this is the addition), we need to unwrap one more
layer.
@WaffleLapkin WaffleLapkin force-pushed the core-mem-maybe-dangling branch from 25476d8 to 6b4f4f5 Compare December 26, 2025 21:03
@WaffleLapkin
Copy link
Member Author

@bors try jobs=aarch64-msvc-1

@rust-bors

This comment has been minimized.

rust-bors bot added a commit that referenced this pull request Dec 26, 2025
Add `MaybeDangling` to `core`

try-job: aarch64-msvc-1
@rust-bors
Copy link
Contributor

rust-bors bot commented Dec 26, 2025

☀️ Try build successful (CI)
Build commit: 553d580 (553d5804c0571418a8c80ae1c8f3449274bc3f7d, parent: 82dd3cb008233bfe50ba6b8d6618e6bbd6054eb1)

@WaffleLapkin
Copy link
Member Author

@bors r=Mark-Simulacrum

@bors
Copy link
Collaborator

bors commented Dec 27, 2025

📌 Commit 6b4f4f5 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@bors bors 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 Dec 27, 2025
@bors
Copy link
Collaborator

bors commented Dec 27, 2025

⌛ Testing commit 6b4f4f5 with merge 0850949...

@bors
Copy link
Collaborator

bors commented Dec 27, 2025

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 0850949 to main...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Dec 27, 2025
@bors bors merged commit 0850949 into rust-lang:main Dec 27, 2025
13 checks passed
@rustbot rustbot added this to the 1.94.0 milestone Dec 27, 2025
@github-actions
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing c7aa99f (parent) -> 0850949 (this PR)

Test differences

Show 184 test diffs

184 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard 08509492139968a96a005ba811a995e2f1d6a2ac --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-gnu-debug: 7263.3s -> 6500.0s (-10.5%)
  2. dist-apple-various: 3957.2s -> 3571.3s (-9.8%)
  3. x86_64-rust-for-linux: 2913.3s -> 2651.7s (-9.0%)
  4. x86_64-msvc-1: 8297.4s -> 9020.0s (+8.7%)
  5. x86_64-gnu: 8208.5s -> 7543.4s (-8.1%)
  6. x86_64-gnu-gcc: 3165.6s -> 3414.0s (+7.8%)
  7. aarch64-apple: 10290.9s -> 9513.2s (-7.6%)
  8. dist-ohos-aarch64: 4527.8s -> 4213.2s (-6.9%)
  9. aarch64-msvc-2: 6400.5s -> 5977.0s (-6.6%)
  10. x86_64-gnu-distcheck: 7868.9s -> 7361.0s (-6.5%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (0850949): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
0.3% [0.1%, 0.6%] 9
Regressions ❌
(secondary)
0.2% [0.1%, 0.5%] 7
Improvements ✅
(primary)
-0.3% [-0.3%, -0.3%] 1
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.2% [-0.3%, 0.6%] 10

Max RSS (memory usage)

Results (primary 0.9%, secondary -0.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
4.8% [2.8%, 6.8%] 2
Regressions ❌
(secondary)
3.0% [2.2%, 3.7%] 2
Improvements ✅
(primary)
-1.7% [-2.2%, -0.9%] 3
Improvements ✅
(secondary)
-2.3% [-4.1%, -1.4%] 4
All ❌✅ (primary) 0.9% [-2.2%, 6.8%] 5

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

Results (primary 0.6%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Bootstrap: 480.868s -> 482.408s (0.32%)
Artifact size: 390.80 MiB -> 390.78 MiB (-0.00%)

@RalfJung
Copy link
Member

This seems to have caused Miri regressions: rust-lang/miri#4793

@panstromek
Copy link
Contributor

perf triage:

Are regressions expected here? Some of those could be noise, it seems like the previous PR had more positive noise (post merge results look better than pre-merge), so this could be just return to normal. The incremental ones look real, though, they have some new deltas in detailed results, for example here for cargo debug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. 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. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants