Addressing a Share static mut should be safe
#13232
Labels
Comments
|
cc @flaper87 |
|
Nominating. |
|
Makes sense to me! Assigning myself to this issue. |
|
Marking P-low, not on 1.0 milestone. (We can add this backwards compatibly, at least if one ignores lints.) |
flaper87
added a commit
to flaper87/rust
that referenced
this issue
Apr 11, 2014
flaper87
added a commit
to flaper87/rust
that referenced
this issue
Apr 11, 2014
In general, it's not allowed to access mutable static items outside an unsafe block. However, taking an immutable address of a mutable static items whose type implements `Share` is considered a safe operation. This is enforced by `rustc::middle::effect` Closes rust-lang#13232
|
cc me |
alexcrichton
added a commit
to alexcrichton/rust
that referenced
this issue
Aug 1, 2014
Taking a shareable loan of a `static mut` is safe if the type contained in the
location is ascribes to `Share`. This commit removes the need to have an
`unsafe` block in these situations.
Unsafe blocks are still required to write to or take mutable loans out of
statics. An example of code that no longer requires unsafe code is:
use std::sync::atomics;
static mut CNT: atomics::AtomicUint = atomics::INIT_ATOMIC_UINT;
let cnt = CNT.fetch_add(1, atomics::SeqCst);
As a consequence of this change, this code is not permitted:
static mut FOO: uint = 30;
println!("{}", FOO);
The type `uint` is `Share`, and the static only has a shareable loan taken out
on it, so the access does not require an unsafe block. Writes to the static are
still unsafe, however, as they can invoke undefined behavior if not properly
synchronized.
Closes rust-lang#13232
|
Bug fixed by 4c62486 |
notriddle
pushed a commit
to notriddle/rust
that referenced
this issue
Sep 20, 2022
Refactor macro-by-example code I had a look at the MBE code because of rust-lang#7857. I found some easy readability wins, that might also _marginally_ improve perf.
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Aug 8, 2024
Add path prefixes back when compiling `clippy_dev` and `lintcheck` `cargo dev` and `cargo lintcheck` use `--manifest-path` to select the package to compile, with this Cargo changes the CWD to the package's containing directory meaning paths in diagnostics start from e.g. `src/` instead of `clippy_dev/src/` Lintcheck uses a `--remap-path-prefix` trick when linting crates to re-add the directory name in diagnostics: https://github.com/rust-lang/rust-clippy/blob/5ead90f13ae3e03f0c346aea3198f18298960d83/lintcheck/src/main.rs#L93-L94 https://github.com/rust-lang/rust-clippy/blob/5ead90f13ae3e03f0c346aea3198f18298960d83/lintcheck/src/main.rs#L102-L103 It works well as far as I can tell, when absolute paths appear they stay absolute and do not have the prefix added [`profile-rustflags`](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-rustflags-option) allows us to set per package `RUSTFLAGS` in order to use the same trick on the `clippy_dev` and `lintcheck` packages themselves Now when you run into warnings/errors the filename will be correctly clickable Before ``` error[E0425]: cannot find value `moo` in this scope --> src/lib.rs:41:5 | 41 | moo; | ^^^ not found in this scope ``` After ``` error[E0425]: cannot find value `moo` in this scope --> clippy_dev/src/lib.rs:41:5 | 41 | moo; | ^^^ not found in this scope ``` r? `@flip1995` changelog: none
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We talked about this at the most recent workweek, but I believe this code should compile as-is:
Specifically, you should be allowed to take the address (
&-pointer) of astatic mut, and you should continue to needunsafeto take a&mut-pointer to astatic mut.The text was updated successfully, but these errors were encountered: