#rust-lang

So in Servo we can have &mut references to stuff on the stack,

(let's assume said stuff on the stack doesn't move ever)

and the thing on the stack is also stored as a pointer to a trait object somewhere else in the program, as part of root lists for the JS GC,

is that unsound?

nox: and by "doesn't move ever" I infer that it never gets popped from the stack frame either, so data is morally &'static mut ?

?

No it does get popped from the stack when the function exits.

Not sure how that relates though.

Basically, you have a &mut T somewhere,

you call a JS function that triggers a GC,

the JS engine traverses the root list and traces it to not free stuff that is still used,

that root list ultimately will traverse that &mut T through the pointer in its root list, while you still have your &mut T in scope.

Is that unsound?

I know that using *some* methods are definitely unsound (Vec::drain for example, because some elements are "hidden" from the Vec while the draining iterator exists), but I don't know if it's always unsound.

If it is indeed unsound, we need some pretty drastic changes.

nox: the rooting list thing is immutable-only, right?

eddyb: What do you mean?

nox: I mean the GC only does immutable accesses

Yes.

eddyb: Well, JS itself will mutate stuff, but that stuff is properly behind UnsafeCell<T> on the Rust side.

nox: well if you had &T and interior mutability instead of &mut it's sound I'm pretty sure

nox: because it's basically the same pattern as scoped thread-locals

eddyb: And having a &mut T around while the GC stuff does immutable access is ok too?

nox: I don't think so

nox: or rather, if it's okay, it's *nowhere* near as simple of a reason

Ok.

eddyb: We have RootedVec<T> which stores a Vec<T> and puts a pointer to it in some root list,

nox: wait you can send the &mut T to another thread

and it DerefMut to Vec<T>,

(if you can get *any* &mut)

(to any field)

mutation is fine, &mut isn't

and I've just realised it is pretty bad, because draining and other stuff.

Not sure what you mean by that.

yeah and there's probably worse things than draining

nox: if I can get a &mut u8 or something within that Vec

Mmh…

nox: I can pass that to another thread

so I think having &mut at all is pretty bad

MMMMH

I kinda want to go back to bed and forget everything now.

but not as much

Wait, why is sending &mut u8 an issue?

nox: because now you can data race

Why?

nox: with the shared reference

in the original thread

I don't follow.

there's no way to say that an &mut (of an arbitrary type) must be used in a certain way

so I can do things to it that aren't valid if you can also access that memory through any other way

and by not valid I mean UB

(well u8 isn't enough to cause UB trivially, but still)

I think I see the issue.

nox: &mut being unaliased is still important even in side-channel cases like these

so UnsafeCell and &self methods it is :P

eddyb: `let PAT = EXPR;` is classified as a statement atm, right?

centril: yes

great

eddyb: hmm... what would the proper desugaring of `let A(x) | B(x) = expr;` be? My naive approach is `let x = match expr { A(x) | B(x) => x };`. Idk if that might be problematic tho

centril: uhm

centril: you wouldn't desugar a let pattern

centril: wait so are we adding | to patterns?

I don't want an interpretation which requires | to be at the top-most level at any point in the implementation

eddyb: https://github.com/rust-lang/rfcs/pull/2175#iss...

although you really want nmatsakis

providing desugarings in RFCs which may not be used seems sketchy

centril: ugh so this is top-most-level-only

eddyb: idk what you mean by "top most level only"?

centril: as in not Some(Ok(x) | Err(x))

centril: anyway I can give you the desugaring of let PAT = EXPR;

oh yeah; | inside patterns is a different RFC

let PAT = EXPR; STMT* TAIL_EXPR?

"desugars" (semantically) to