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

Allow (unsafe) access to the UnsafeCell inside RefCell #18131

Closed
kmcallister opened this issue Oct 17, 2014 · 4 comments · Fixed by #18212
Closed

Allow (unsafe) access to the UnsafeCell inside RefCell #18131

kmcallister opened this issue Oct 17, 2014 · 4 comments · Fixed by #18212
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@kmcallister
Copy link
Contributor

This would be useful in cases where we mostly want to enforce RefCell guarantees but need to break the rules in one place. (e.g. the Servo interface to html5ever which needs to GC-trace a mutably-borrowed parser)

@kmcallister kmcallister added A-libs E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. labels Oct 17, 2014
@jdm
Copy link
Contributor

jdm commented Oct 18, 2014

Similarly, this would be useful for RAII classes that need to be fail-proof in the face of task failure while there are outstanding RefCell borrows.

@sfackler
Copy link
Member

@jdm I don't think that case should be an issue; the Ref/RefMut destructors have to run before their RefCell's. They don't right now in some cases due to some unsoundness problems but that will be fixed: #8861.

@Ms2ger
Copy link
Contributor

Ms2ger commented Oct 21, 2014

@kmcallister
Copy link
Contributor Author

Does the accessor itself need to be unsafe? I don't think so, because the relevant UnsafeCell ops are unsafe and we're only handing out shared references to it.

kmcallister added a commit to kmcallister/servo that referenced this issue Oct 24, 2014
This gets rid of a dubious transmute:

    let val = mem::transmute::<&RefCell<T>, &T>(&self.base);

The code duplication will be reduced once rust-lang/rust#18131 is fixed.
kmcallister added a commit to kmcallister/rust that referenced this issue Oct 24, 2014
kmcallister added a commit to kmcallister/servo that referenced this issue Oct 24, 2014
This gets rid of a dubious transmute:

    let val = mem::transmute::<&RefCell<T>, &T>(&self.base);

The code duplication will be reduced once rust-lang/rust#18131 is fixed.
RonakNisher pushed a commit to RonakNisher/servo that referenced this issue Nov 19, 2014
This gets rid of a dubious transmute:

    let val = mem::transmute::<&RefCell<T>, &T>(&self.base);

The code duplication will be reduced once rust-lang/rust#18131 is fixed.
lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
…rate, r=Veykril

fix: Get rid of `$crate` in expansions shown to the user

Be it "Expand Macro Recursively", "Inline macro" or few other things.

We replace it with the crate name, as should've always been.

Probably fixes some issues, but I don't know what they are.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants