Skip to content

rustup to e7c23ab933ebc1f205c3b59f4ebc85d40f67d404 #1716

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 20, 2021
Merged

rustup to e7c23ab933ebc1f205c3b59f4ebc85d40f67d404 #1716

merged 1 commit into from
Feb 20, 2021

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Feb 20, 2021

No description provided.

Verified

This commit was signed with the committer’s verified signature.
renovate-bot Mend Renovate
let place = this.deref_operand(place)?;

// make sure it fits into a scalar; otherwise it cannot be atomic
let val = this.read_scalar_atomic(place, atomic)?;
let val = this.read_scalar_atomic(&place, atomic)?;
Copy link
Member

Choose a reason for hiding this comment

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

Why is it deref_operand(place) a few lines above but read_scalar_atomic(&place here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The first ref place binding is being shadowed by let place = this.deref_operand(place)?;.

Copy link
Member

Choose a reason for hiding this comment

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

Oh, good point, thanks.

let old = this.allow_data_races_mut(|this| this.read_scalar(place.into()))?;
this.allow_data_races_mut(|this| this.write_scalar(new, place.into()))?;
let old = this.allow_data_races_mut(|this| this.read_scalar(&place.into()))?;
this.allow_data_races_mut(|this| this.write_scalar(new, &(*place).into()))?;
Copy link
Member

Choose a reason for hiding this comment

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

&place vs &(*place) seems inconsistent here, they are doing the same thing, right?

Copy link
Contributor Author

@tmiasko tmiasko Feb 20, 2021

Choose a reason for hiding this comment

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

First constructs OpTy which has From<&MPlaceTy>, the other construct PlaceTy which has only From<MPlaceTy> (it was unnecessary for rustc).

Copy link
Member

Choose a reason for hiding this comment

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

Oh, I didn't realize you were adding new From instances as well.

@RalfJung
Copy link
Member

RalfJung commented Feb 20, 2021

Thanks a lot, this must have been a lot of work. :)

We can land this as-is, but I am confused by a few things -- see my questions above.
EDIT: Ah, you have already answered them.^^

@RalfJung
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Feb 20, 2021

📌 Commit 0eb3414 has been approved by RalfJung

@bors
Copy link
Contributor

bors commented Feb 20, 2021

⌛ Testing commit 0eb3414 with merge ea86335...

@bors
Copy link
Contributor

bors commented Feb 20, 2021

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing ea86335 to master...

@bors bors merged commit ea86335 into rust-lang:master Feb 20, 2021
@tmiasko tmiasko deleted the rustup branch February 20, 2021 17:55
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.

None yet

3 participants