Open oli-obk opened 6 years ago
So what about constants of type MaybeInitialized<&mut T>
?
That's fine, even on nightly: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2015&gist=a9a11a688079f6535f8e7e548cdbcd3a
Const eval will error out if you leak a local and you can't promote a mutable reference to something other than []
Hm. I am still confused by what exactly the guarantee is that we need.
So it is okay to have &mut
below a union, but not below a tuple? struct
? enum
? What if someone calls into_inner
on that MaybeInitialized<&mut T>
?
Const eval will error out if you leak a local
That's because StorageDead
killed the local, right? Does it do that reliably? And didn't we hope to lift that restriction some day?
I see two parts to this:
&mut
, writing to it will fail. To this end, we have to set the mutability of the allocations appropriately during interning. Currently, what we do is somewhat odd: First of all, we don't actually make sure here that all const
are Mutability::Immutable
(bug?), and secondly, we use the same mutability for the static
/const
itself and anything it references that hasn't been interned already (i.e., anything new, added by this static
/const
). The latter part cannot be right. I think right now it would be correct to make everything that gets referenced immutable because the only legal way for it to refer to something mutable is to reference another static, right?&mut
to an immutable allocation. Validity could perform that check. Is that sufficient?Also, shouldn't this be tracked in https://github.com/rust-rfcs/const-eval/?
we are in rust-rfcs
!? :rofl:
the only legal way for it to refer to something mutable is to reference another static, right?
Not from within another static/const. If an immutable (and thus safe to access) static contained a mutable reference to another static, then you'd be able to "safely" obtain two mutable references to the same static, which is obviously wrong.
That's because StorageDead killed the local, right? Does it do that reliably? And didn't we hope to lift that restriction some day?
Yes, Yes, No
I don't see how we could lift that and how that would be sound.
Making this a validation guarantee does have some nice properties, but fails out of the same reasons that the freeze and needs drop checks can't be part of validation. Associated constants would end up causing monomorphization time errors.
we are in rust-rfcs!? rofl
Oh, eh... look, a three-headed monkey! :monkey_face: :monkey_face: :monkey_face:
Not from within another static/const. If an immutable (and thus safe to access) static contained a mutable reference to another static, then you'd be able to "safely" obtain two mutable references to the same static, which is obviously wrong.
Ah that's your concern. Yeah you should only get shared refs there. So without interior mutability, there wouldn't even be a problem...
While is very important to not have
static
orconst
items of such types, during the evaluation of astatic
orconst
item we might want to work with intermediate values of this type.E.g.
seems totally reasonable.