Skip to content

Conversation

@RalfJung
Copy link
Member

Apparently the real implementation remembers who owned the lock before it got moved, and then the new lock still behaves as-if it is owned by that thread. In Miri we don't currently track the owner across moves so we can't behave like that. Make sure we halt execution in cases where we risk behaving different than the real implementation.

@rustbot
Copy link
Collaborator

rustbot commented Nov 15, 2025

Thank you for contributing to Miri! A reviewer will take a look at your PR, typically within a week or two.
Please remember to not force-push to the PR branch except when you need to rebase due to a conflict or when the reviewer asks you for it.

@rustbot rustbot added the S-waiting-on-review Status: Waiting for a review to complete label Nov 15, 2025
@RalfJung RalfJung enabled auto-merge November 15, 2025 08:26
@RalfJung RalfJung added this pull request to the merge queue Nov 15, 2025
Merged via the queue into rust-lang:master with commit 339caa8 Nov 15, 2025
13 checks passed
@RalfJung RalfJung deleted the apple-os-unfair-lock branch November 15, 2025 09:22
@rustbot rustbot removed the S-waiting-on-review Status: Waiting for a review to complete label Nov 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants