Forbid references to statics in valtrees #126477
Conversation
rustbot
added
the
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
rustbot
added
the
T-compiler
|
This also rejects references to statics in patterns, and there's not really a good reason to reject those, is there? It would be nice to preserve the property that all consts that pass validity checking can be used in patterns. |
| ); | ||
| let place = ecx.raw_const_to_mplace(const_alloc).unwrap(); | ||
| debug!(?place); | ||
|
|
||
| let mut num_nodes = 0; | ||
|
|
||
| // To preserve provenance of static items, it is crucial that we do not |
There was a problem hiding this comment.
I'd say this is less about provenance and more about preserving their unique absolute address.
complexity of this PR. I fully plan on adding a |
|
In that case I don't think I see the point of this PR. The only effect it has on stable with const_refs_to_static stabilized is to reject some patterns that we want to accept. For const generics we IMO want a completely different solution, based on (as you say) a new kind of valtree leaf that encodes "offset N into this particular static". So to summarize, for patterns this PR doesn't do what we want, and for const generics it doesn't do what we want either. |
|
Jup, as per the discussion in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Refs.20to.20statics.20in.20constants I'm gonna just land the test and the removed unused error variant |
Implements the result of the recent discussions in https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Refs.20to.20statics.20in.20constants
Basically instead of making a decision on how we want to treatreferences to statics in valtrees (and thus in const generics), we just reject them entirely. In the future we could (behind a separate feature gate) create a new valtree node that preserves the static's identity.
cc #119618
Forward compatible with anything we decide in #120961
r? @RalfJung
cc @nikomatsakis