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

Cast-to-raw: inherit permission from parent pointer? #227

Closed
RalfJung opened this issue Mar 12, 2020 · 1 comment
Closed

Cast-to-raw: inherit permission from parent pointer? #227

RalfJung opened this issue Mar 12, 2020 · 1 comment
Labels
A-aliasing-model Topic: Related to the aliasing model (e.g. Stacked/Tree Borrows) A-SB-vs-TB Topic: Design questions where SB and TB are opposite sides of the design axis C-open-question Category: An open question that we should revisit

Comments

@RalfJung
Copy link
Member

With the introduction of &raw, casting a reference to a raw pointer no longer incurs an implicit reborrow. x as *const _ translates to &raw const *x, so whatever tag x has is the parent tag of the raw reborrow that occurs.

This gives us a chance to do something about rust-lang/rust#56604: currently, on a raw reborrow, we use the raw ptr type to figure out which permission to add for the new tag. But instead we could (per location) check which permission the parent pointer has, and use that. Then *mut _ vs *const _ would truly not make a different for Stacked Borrows.

Problems with this approach:

  • It breaks the current Stacked Borrows structure, so the change is non-trivial.
  • The borrow checker still treats *mut _ and *const _ differently, not matching that could cause issues.
  • We need to be careful that the new item is placed in the right spot of the stack, as all sorts of existing items must still keep working.
  • What do we do when the parent ptr is untagged, and there is both an untagged read-only and an untagged read-write item in the stack? Which one do we "match"? Probably the one furthest up, but that could lead to getting a read-only permission when read-write would be possible (at the cost of popping some more items). Currently, when reborrowing to *mut T, the new pointer will always get read-write permission. So maybe the pointer type should still be relevant in this specific case?
@RalfJung
Copy link
Member Author

RalfJung commented Apr 1, 2024

This is basically the same issue as #134, so closing in favor of that.

@RalfJung RalfJung closed this as completed Apr 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-aliasing-model Topic: Related to the aliasing model (e.g. Stacked/Tree Borrows) A-SB-vs-TB Topic: Design questions where SB and TB are opposite sides of the design axis C-open-question Category: An open question that we should revisit
Projects
None yet
Development

No branches or pull requests

1 participant