Skip to content

wasm: rm static mut #142727

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Aug 28, 2025
Merged

wasm: rm static mut #142727

merged 1 commit into from
Aug 28, 2025
+10 −7

Conversation

hkBst
Copy link
Member

@hkBst hkBst commented Jun 19, 2025 •
edited
Loading

More #125035. I'm not sure this is correct, but it compiles.

@rustbot
Copy link
Collaborator

rustbot commented Jun 19, 2025

r? @ChrisDenton

rustbot has assigned @ChrisDenton.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jun 19, 2025
juntyr
juntyr reviewed Jun 19, 2025
View reviewed changes
library/std/src/sys/alloc/wasm.rs

use crate::alloc::{GlobalAlloc, Layout, System};

static mut DLMALLOC: dlmalloc::Dlmalloc = dlmalloc::Dlmalloc::new();
struct SyncDlmalloc(dlmalloc::Dlmalloc);
unsafe impl Sync for SyncDlmalloc {}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only safe if we're in WASM without threads, is this file already gated for that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The same file also contains a Lock impl for the case there are threads, which is used to guard the Allocator impl against unsynchronized accesses.

@tgross35
Copy link
Contributor

Is this motivated by the oldish issue to deprecate static mut in favor of a wrapper type? If so, that was eventually decided against. So I don't think this is needed because the Dlmalloc isn't ever mutably accessed via a & reference, which is what the UnsafeCell would enable. And as @juntyr pointed out, Dlmalloc does not have Sync in its API guarantees (it could choose to use a Cell internally) and there isn't anything that SyncDlmalloc adds to make it such.

Fyi you should be able to sanity check the behavior with ./x miri library/ --target wasm32-unknown-unknown - not that that would catch incorrect impls, but the existing version of this should pass fine.

Cc @RalfJung since you could explain some of this much better than me.

@RalfJung
Copy link
Member

RalfJung commented Jun 20, 2025 •
edited
Loading

It's up to t-libs what they find more clear here. The alternative would be to leave the static mut and then silence the lint e.g. by writing (&mut * &raw mut DLMALLOC). Either way, much more important than static mut vs static is having proper safety comments.

@hkBst
Copy link
Member Author

hkBst commented Jun 20, 2025

Is this motivated by the oldish issue to deprecate static mut in favor of a wrapper type?

It's motivated by #125035, but I admit that I was under the impression that we should get rid of all uses of "static mut", but I see #53639 was closed as not planned.

So should we just try and remove most uses of "static mut" that can easily be replaced by something other than SyncUnsafeCell, or something along those lines?

@ChrisDenton
Copy link
Member

Given the discussion above, this feels like it needs a t-libs decision? I'll nominate it

@rustbot label +I-libs-nominated

@rustbot rustbot added the I-libs-nominated Nominated for discussion during a libs team meeting. label Aug 23, 2025
@Amanieu
Copy link
Member

Amanieu commented Aug 28, 2025

This was discussed in the @rust-lang/libs meeting but there were no strong feeling towards either keeping static mut or changing it to a SyncUnsafeCell. We're tentatively happy to accept this PR as is though.

@Amanieu Amanieu removed the I-libs-nominated Nominated for discussion during a libs team meeting. label Aug 28, 2025
@ChrisDenton
Copy link
Member

@bors r+ rollup

@bors
Copy link
Collaborator

bors commented Aug 28, 2025

📌 Commit ed81a11 has been approved by ChrisDenton

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 28, 2025
@Zalathar Zalathar mentioned this pull request Aug 28, 2025
Merged
bors added a commit that referenced this pull request Aug 28, 2025
@bors
Auto merge of #145958 - Zalathar:rollup-ii9z77c, r=Zalathar
1f7dcc8 
Rollup of 9 pull requests

Successful merges:

 - #142727 (wasm: rm static mut)
 - #143193 (Port `#[link]` to the new attribute parsing infrastructure )
 - #144864 (No source fixes)
 - #145913 (Add spin_loop hint for LoongArch)
 - #145926 (compiletest: Remove several remnants of the old libtest-based executor)
 - #145928 (Rename `Location::file_with_nul` to `file_as_c_str`)
 - #145930 (`const`ify (the unstable) `str::as_str`)
 - #145941 (Disable `integer_to_ptr_transmutes` suggestion for unsized types)
 - #145953 (Update `icu_list` to 2.0)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit bd8fb60 into rust-lang:master Aug 28, 2025
10 checks passed
@rustbot rustbot added this to the 1.91.0 milestone Aug 28, 2025
rust-timer added a commit that referenced this pull request Aug 28, 2025
@rust-timer
Unrolled build for #142727
2978da7 
Rollup merge of #142727 - hkBst:rm-static-mut-wasm, r=ChrisDenton

wasm: rm static mut

More #125035. I'm not sure this is correct, but it compiles.
@hkBst hkBst deleted the rm-static-mut-wasm branch August 28, 2025 17:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
1 more reviewer

@juntyr juntyr juntyr left review comments

Reviewers whose approvals may not affect merge requirements
Assignees

@ChrisDenton ChrisDenton

Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
1.91.0
Development

Successfully merging this pull request may close these issues.
8 participants
@hkBst @rustbot @tgross35 @RalfJung @ChrisDenton @Amanieu @bors @juntyr