Why can consts not refer to statics?

[RalfJung]

Is there some deep fundamental reason why that can never work, or is it a limitation of the current (or a former) implementation?

[oli-obk]

I think the root issue is

static FOO: AtomicUsize = AtomicUsize::new(42);

// hides the static behind a regular reference
const BAR: &AtomicUsize = &FOO;
const fn bar() -> usize {
    BAR.swap(99, Ordering::Relaxed)
}

Multiple calls to bar at runtime will yield different results and compile-time calls will error out.

[oli-obk]

Additionally

const WAT: usize = BAR.load(Ordering::Relaxed);

seems very weird, because WAT always has the compile-time value of the static, even though the static can change.

[RalfJung]

Okay, so this is actually again the same problem as with promoteds: It's about statics that could have been mutated. Once again a rule for promoteds is actually a rule for statics.

Maybe we should make the CTFE engine error out on such accesses, just to make sure the static checks didn't miss anything? Not sure how to do that, though.

[RalfJung]

Oh, and this does not explain why the following is not allowed:

static FOO: usize = 13;
const BAR: &usize = &FOO;

Is that just a limitation of the analysis?

[Ixrec]

Maybe a desirable limitation. If that was lifted, we'd get a backwards-compatibility hazard where the lack of privates with interior mutability becomes a non-obvious part of your public API, right? (though I guess it's fine for primitives like usize)

[RalfJung]

@Ixrec I am talking about taking the address of a static without ever using it. That seems fine no matter the type.

Of course the question is how we can be sure that it won't be used. Between ruling out &STATIC and *r, it seems better to have the latter and not the former.

[rpjohnst]

I just hit a use case where some way for a const to refer to a static would be extremely valuable:

My goal was to convert a string interner from handing out indices, to handing out direct pointers. This would have been a performance optimization for programs that frequently do more than simply compare string identities- e.g. printing them out, checking metadata.

Pointers from consts to static come into this because I already had a large collection of consts for "well-known" interned strings, which I used in patterns. With indices, those consts were just (wrapped) integers, the interner constructor inserted the strings in the same order, and everything worked fine. With pointers, all the tests started failing, because separate uses of a const would point to separate copies of the string!

Currently, the only way in Rust to enforce that all parts of a program share a common address in memory is to use a static. But statics don't work in patterns (nor would that really make sense, AIUI), and consts can't point to them, so I'm faced with a frustrating choice: either give up the consts (and the pattern matching), or give up the optimization.

[RalfJung]

@rpjohnst to be clear, computing the value of your constants would not actually read from the static, they would just reference it?

I think that should be soundly possible. We even already should have the const-eval engine checks in place which ensure that you do not read through those references. The main problem however is that I do not see a good way to do such a more precise check (allow references but not reads from statics) pre-monomorphization -- so this would result in more post-monomorphization errors, which is not great.

[rpjohnst]

Yes, I could write it such that computing the value of a constant does not read from a static and only takes its address (or the address of one of its fields, the way I wrote it, which should be just as sound).

(Not related to this issue, but that makes it slightly uglier unless we also get unsized statics or limited type inference for statics, because their type would be StaticEntry<[u8; N]> with a different N for each string. Before I hit this issue I worked around that with an unsizing conversion to &StaticEntry<[u8]>, which makes computing a const read that reference from the static.)

To confirm my understanding of why this would need to be a post-monomorphization check, is this the sort of thing you meant by a choice between "ruling out &STATIC and *r"? https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=4bdb8ceb56797048ba9a406609453f4a

I wonder if we couldn't lift the restriction only for non-generic consts, at least in the short term. Lifting it for generic consts would require some sort of trait-like tracking, for which I can imagine two possibilities at the moment:

• Forbid reading any statics in consts, which would require trait-like logic to apply to values, I think? A post-monomorphization check is probably much simpler than this.
• Piggyback it on Freeze or something like that, so consts would be able to read from statics that can't change. (IIUC this would also be okay?) Leaving this option open would mean being careful how much we allow for non-generic consts in the meantime.

[RalfJung]

(Not related to this issue, but that makes it slightly uglier unless we also get unsized statics or limited type inference for statics, because their type would be StaticEntry<[u8; N]> with a different N for each string. Before I hit this issue I worked around that with an unsizing conversion to &StaticEntry<[u8]>, which makes computing a const read that reference from the static.)

We could even allow that, reads from immutable statics (no mut, no interior mutability) are fine, actually. Just so far, to be conservative, we have rejected reads from all statics.

To confirm my understanding of why this would need to be a post-monomorphization check, is this the sort of thing you meant by a choice between "ruling out &STATIC and *r"?

Yes, that is a great example.

Another way to say this is that we are looking for the property "does this read from a static" in the const-initializer, and that const-initializer is written in a turing-complete language. Thus whether or not the property holds is undecidable (in the "halting problem" sense). So, even without associated consts, basically the only thing we can do is to just run the initializer and see if it does the bad thing. That is in contrast to now where we do an overapporixmative analysis and reject referring to statics, which then also rules out any attempts to read from them.

I wonder if we couldn't lift the restriction only for non-generic consts, at least in the short term.

We could, but that would be a very odd "split" to have, I think. There is no precedent for a split like that as far as I know, and I am undecided if this is better or worse than a post-monomorphization check.

[rpjohnst]

Wait, if we can allow reads from truly-immutable statics then couldn't we just always allow that, even around the generic cases?

The results of "does this reference a !Freeze static" should be equally the same across monomorphizations as today's "does this reference any static." (Though really it would have to be any static that is or can itself refer to anything !Freeze.)

Does that sort of rule feel any better than a post-monomorphization check or the odd "non-generic" split? It should remove the need to actually run the initializer, though it does add a bit of extra information that needs to be propagated across statics (though not consts).

Edit: this would also rely on not having associated/generic statics, I think? We don't currently, but if we added them this sort of analysis would have to become post-monomorphization again, or else we'd get the weird "non-generic" split again.

[RalfJung]

Wait, if we can allow reads from truly-immutable statics then couldn't we just always allow that, even around the generic cases?

I think this is mostly legacy. And you raise a good point, but I need to explain some background to translate this proposal into something more concrete.

Some background

We have two layers of defense against misbehaving consts currently: we have some static checks (in the sense of static analysis, not the static keyword) that take the source-code, analyze it, and try to figure out if running that code could do anything bad. If it could, we throw an error. This is necessarily conservative, i.e., we will reject some code that would not do anything bad -- this is basically the halting problem. Historically, these were the only checks we had.

Over time, we added a second line of defense. When the code is "run" in the interpreter that evaluates const/static initializes, we have some dynamic checks that look at what the code actually does, and when it does something bad, we stop the code. This analysis is precise, meaning it should catch all errors and essentially make the static analysis "unnecessary" (modulo what is tracked in #17 and any other concerns that we missed...), but it runs late, after monomorphization, because it needs all the data to actually compute the initializer.

Current status

The dynamic check currently rejects all reads from statics. This is slightly conservative, we could permit reads from immutable statics, but @oli-obk wanted to start conservative here and I didn't push back. I think we can relax this.

The static check rejects even mentioning any static, because that is the only way we know to be sure that a static won't be read from later. Permitting the code to create a reference to a static, but then ruling out that the reference is actually read from, is not feasible.

Your proposal

I think you are proposing to

• Change the dynamic analysis to permit reads from immutable statics.
• Then, change the static analysis to permit taking references to statics that are guaranteed immutable (so if we ever have "associated/generic statics", which I think we won't, but if we do this is still fine as consts can just conservatively not reference them). With the relaxed dynamic checks, I think our static checks are then still sound wrt. our dynamic checks.

I think that should be fine, and it should not introduce any new post-monomorphization errors. @rust-lang/wg-const-eval what do you think?