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

"Moving" out of a static could be a memcpy #13233

Closed
alexcrichton opened this issue Mar 31, 2014 · 7 comments
Closed

"Moving" out of a static could be a memcpy #13233

alexcrichton opened this issue Mar 31, 2014 · 7 comments
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@alexcrichton
Copy link
Member

This was discussed at the recent work week, but it appears that our notes to not reflect a decision one way or another. I would expect this code to compile:

use std::sync::atomics;

fn main() {
    let a = atomics::INIT_ATOMIC_UINT;
}

Specifically, you can "move" out of any non-mut static, it just turns in to a memcpy. The contents of the static have already been validated to not own anything and have no destructors, so this should be safe.

@flaper87
Copy link
Contributor

Moves out of static items were disallowed as part of 8784d2f

Relaxing this to just mutable static items should be pretty straightforward. I'm tagging the issue as e-easy, I can mentor.

@malu
Copy link

malu commented Mar 31, 2014

I'd be interested to try this. Is it correct that I would either have to add a new option to categorization in middle/mem_categorization.rs or add a boolean field to the cat_static_item option to represent mutability?

Edit: Ok, I guess that is unnecessary given that I can get the mutability through the cmt_ struct. Am I understanding all this correctly?

I should probably add I'm talking about changing the check_is_legal_to_move_from function in middle/borrowck/gather_loans/gather_moves.rs.

@flaper87
Copy link
Contributor

flaper87 commented Apr 1, 2014

@malu correct, you don't need to add anything to cat_static_item because cmt already has the information you need.

The change consists in adding an arm for cat_static_item and returning true or false based on the mutability.

@malu
Copy link

malu commented Apr 1, 2014

Please see https://github.com/malu/rust/tree/issue-13233 and tell me if I did something wrong or if something is missing.

@flaper87
Copy link
Contributor

flaper87 commented Apr 1, 2014

@malu it's easier (and better) to comment on pull-requests. Would you mind submitting a PR ? I can provide feedback there. Thanks a lot for working on this.

@nikomatsakis
Copy link
Contributor

cc me

@huonw
Copy link
Member

huonw commented Nov 10, 2014

This role is now filled by const. Closing.

@huonw huonw closed this as completed Nov 10, 2014
Jarcho pushed a commit to Jarcho/rust that referenced this issue Aug 24, 2024
`declare_interior_mutable_const`: Ignore pointer types.

fixes rust-lang#12951
fixes rust-lang#13233

changelog: `declare_interior_mutable_const`: Ignore pointer types.
Jarcho pushed a commit to Jarcho/rust that referenced this issue Aug 26, 2024
`declare_interior_mutable_const`: Ignore pointer types.

fixes rust-lang#12951
fixes rust-lang#13233

changelog: `declare_interior_mutable_const`: Ignore pointer types.
Jarcho pushed a commit to Jarcho/rust that referenced this issue Aug 26, 2024
`declare_interior_mutable_const`: Ignore pointer types.

fixes rust-lang#12951
fixes rust-lang#13233

changelog: `declare_interior_mutable_const`: Ignore pointer types.
MabezDev pushed a commit to esp-rs/rust that referenced this issue Sep 3, 2024
`declare_interior_mutable_const`: Ignore pointer types.

fixes rust-lang#12951
fixes rust-lang#13233

changelog: `declare_interior_mutable_const`: Ignore pointer types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants