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

UnsafeCell::into_inner should not be unsafe #35067

Closed
strega-nil opened this issue Jul 27, 2016 · 14 comments · Fixed by #47204
Closed

UnsafeCell::into_inner should not be unsafe #35067

strega-nil opened this issue Jul 27, 2016 · 14 comments · Fixed by #47204
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@strega-nil
Copy link
Contributor

It's been unsafe since 2014 when it was called unwrap. Nobody thought about it, I guess, but it shouldn't be unsafe.

@retep998
Copy link
Member

For reference the PR which added it is #12686

@durka
Copy link
Contributor

durka commented Jul 27, 2016

Someone thought about it enough to document the rationale:

This function is unsafe because this thread or another thread may currently be inspecting the inner value.

Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?

@retep998
Copy link
Member

@durka Because the function takes self so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.

@strega-nil
Copy link
Contributor Author

Although this isn't backwards-compatible

let x: unsafe fn(_) -> _ = UnsafeCell::<u32>::into_inner;

there is some prior art of going unsafe -> safe: std::mem::forget (although, that was pre-1.0)

@durka
Copy link
Contributor

durka commented Jul 27, 2016

That's weird, it seems like you ought to be able to assign a safe fn to an
unsafe fn pointer.

On Wed, Jul 27, 2016 at 3:38 PM, Nicole Mazzuca notifications@github.com
wrote:

Although this isn't backwards-compatible

let x: unsafe fn(_) -> _ = UnsafeCell::::into_inner;

there is some prior art of going unsafe -> safe: std::mem::forget
(although, that was pre-1.0)


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#35067 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n27xH8O46Airgb7KocadqJX4BX33ks5qZ7OrgaJpZM4JV6mY
.

@nikomatsakis
Copy link
Contributor

We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.

@nikomatsakis
Copy link
Contributor

(I tend to agree that into_inner could be safe, though, and I highly doubt any existing crates would actually break due to this change.)

@retep998
Copy link
Member

We could always do a crater run just to be absolutely sure nobody is turning UnsafeCell::into_inner into a function pointer.

@steveklabnik steveklabnik added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. and removed A-libs labels Mar 24, 2017
@cyplo
Copy link
Contributor

cyplo commented May 13, 2017

HI ! Any news on this one ?

@nikomatsakis
Copy link
Contributor

No change that I know of.

@Mark-Simulacrum Mark-Simulacrum added the C-enhancement Category: An issue proposing an enhancement or a PR with one. label Jul 25, 2017
varkor added a commit to varkor/rust that referenced this issue Jan 5, 2018
This fixes rust-lang#35067. It will require a Crater run as discussed in that
issue.
@Mark-Simulacrum Mark-Simulacrum added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Jan 5, 2018
bors added a commit that referenced this issue Jan 5, 2018
Make UnsafeCell::into_inner safe

This fixes #35067. It will require a Crater run as discussed in that
issue.
@cramertj
Copy link
Member

cramertj commented Jan 5, 2018

FWIW the relevant coercion was added in #37389.

bors added a commit that referenced this issue Jan 10, 2018
Make UnsafeCell::into_inner safe

This fixes #35067. It will require a Crater run as discussed in that
issue.
bors added a commit that referenced this issue Jan 28, 2018
Make UnsafeCell::into_inner safe

This fixes #35067. It will require a Crater run as discussed in that
issue.
@asomers
Copy link
Contributor

asomers commented Apr 3, 2018

This change is breaking my crate. If I add the unsafe then it will work for older compilers. If I remove the unsafe then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.

@cramertj
Copy link
Member

cramertj commented Apr 3, 2018

@asomers Use #[allow(unused_unsafe)] unsafe { ... }

@asomers
Copy link
Contributor

asomers commented Apr 3, 2018

Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.

yvt added a commit to yvt/ngspades that referenced this issue Apr 25, 2020
- Lifetime bounds in generic parameters of a type are now inferred.
- `std::cell::UnsafeCell::into_inner` is no longer `unsafe`:
  <rust-lang/rust#35067>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants