wasm: rm static mut

[hkBst]

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

[rustbot]

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

[juntyr]

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

[hkBst]

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]

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]

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]

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?