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 semantics #16022

Closed
Zoxc opened this issue Jul 27, 2014 · 2 comments
Closed

UnsafeCell semantics #16022

Zoxc opened this issue Jul 27, 2014 · 2 comments

Comments

@Zoxc
Copy link
Contributor

Zoxc commented Jul 27, 2014

I noticed that we currently emit noalias on function parameters of type &mut unconditionally, even if they contain UnsafeCell. This means that we cannot create aliases to the data of UnsafeCell if we pass it to a function as &mut, which implies that we cannot create aliases to mutable data at all. This seems to go against the spirit and documentation of UnsafeCell. @cmr indicated on IRC that this might be reasonable, since UnsafeCell is supposedly only used with &. I think it's a bit odd that changing from & to &mut will silently break UnsafeCell usage.

I suggest we allow UnsafeCell to work with &mut. I further suggest that we only allow pointers based on (using LLVM's definition) UnsafeCell::get and UnsafeCell::unwrap. This means we can ensure the implementation of UnsafeCell::get doesn't base it's return on &self and then mark all references as noalias.

I'm not sure if that will lead to performance improvements since it will inhibit alias analysis on the unsafe code. An expensive way to fix that would be to remove all non-conservative noalias markers, let UnsafeCell::get's return be based on &self and run LLVM passes again.

@steveklabnik
Copy link
Member

At this point, UnsafeCell and such have been marked as stable, and so changes to it will need to undergo the RFC process. Please open an issue over there if you still think this needs to be changed, thanks!

@aidanhs
Copy link
Member

aidanhs commented Feb 29, 2016

rust-lang/rfcs#1447 - rfc discussing aliasing.

bors added a commit to rust-lang-ci/rust that referenced this issue Dec 11, 2023
…m-macros, r=lnicola

internal: Don't explicitly warn against `semicolon_in_expressions_from_macros`

This has been warn-by-default for two years now and has already been added to the future-incompat lints in 1.68.

See rust-lang#79813 for the tracking issue.
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

No branches or pull requests

3 participants