Skip to content
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

refinement typing go brrrrrr #90016

Closed
wants to merge 3 commits into from
Closed

Conversation

BoxyUwU
Copy link
Member

@BoxyUwU BoxyUwU commented Oct 18, 2021

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 18, 2021
@rust-log-analyzer

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.

@rust-log-analyzer

This comment has been minimized.

@BoxyUwU BoxyUwU force-pushed the refinement_typing branch 3 times, most recently from 03b6261 to a5bcda9 Compare October 22, 2021 21:47
@BoxyUwU BoxyUwU marked this pull request as ready for review October 23, 2021 18:17
@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

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

Probably a good idea to squash some (most?) commits

compiler/rustc_mir_transform/src/refinements.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_transform/src/refinements.rs Outdated Show resolved Hide resolved
SetDiscriminant { place, .. } => trans.clear(place.local),
Assign(box (lhs_p, rhs)) => {
trans.clear(lhs_p.local);
if let Rvalue::Ref(_, BorrowKind::Mut { .. }, ref_p) = rhs {
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably need to do the same for AddressOf. Also immut borrows can be a problem with interior mut

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think interior mut is problematic though im having trouble explaining why I think that 🤔

Copy link
Contributor

@oli-obk oli-obk Oct 24, 2021

Choose a reason for hiding this comment

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

I had the same reaction as you, but couldn't explain it. Some thinking lead me to believe the reason is that interior mutability means you can only access the data via methods, so you lose all refinements anyway.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am going to just clear refinements on AddressOf even when its not mutable to be on the safe side. I think that even though it seems unproblematic i don't trust it 😅

Copy link
Member Author

@BoxyUwU BoxyUwU Oct 24, 2021

Choose a reason for hiding this comment

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

Looking at how UnsafeCell is implemented in core I think that its probably fine right now given the combination of no refinements on projections and only being able to get at the inner value through methods. This all feels rather sketchy though...

Copy link
Contributor

Choose a reason for hiding this comment

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

The current implementation also makes implicit assumption that an assignment invalidates all existing borrows.

Copy link
Member Author

Choose a reason for hiding this comment

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

is this assumption not correct

compiler/rustc_mir_transform/src/refinements.rs Outdated Show resolved Hide resolved
compiler/rustc_mir_transform/src/refinements.rs Outdated Show resolved Hide resolved
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 28, 2021
Comment on lines +216 to +218
for refine in self.0.iter_mut() {
*refine = Some(RefineRange::from(0..=(u128::MAX)));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
for refine in self.0.iter_mut() {
*refine = Some(RefineRange::from(0..=(u128::MAX)));
}
self.0.fill(Some(RefineRange::from(0..=u128::MAX)));

@apiraino
Copy link
Contributor

apiraino commented Nov 24, 2021

my understanding is that this is now:

@rustbot label -S-waiting-on-review +S-waiting-on-author

(btw I miss the meaning implied by the title of this PR)

@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 Nov 24, 2021
@bors
Copy link
Contributor

bors commented Dec 3, 2021

☔ The latest upstream changes (presumably #91469) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnCSimon
Copy link
Member

Ping from triage:
@BoxyUwU - Can you please post the status of this PR? Thank you.

@BoxyUwU
Copy link
Member Author

BoxyUwU commented Jan 30, 2022

just gonna close this because im tired and dont want to think about this PR lol

@BoxyUwU BoxyUwU closed this Jan 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.