Reachable statics have reachable initializers

[tmiasko]

Static initializer can read other statics. Initializers are evaluated at
compile time, and so their content could become inlined into another
crate. Ensure that initializers of reachable statics are also reachable.

Previously, when an item incorrectly considered to be unreachable was
reached from another crate an attempt would be made to codegen it. The
attempt could fail with an ICE (in the case MIR wasn't available to do
so) in some circumstances the attempt could also succeed resulting in
a local codegen of non-local items, including static ones.

Fixes #84455.

[rust-highfive]

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

[tmiasko]

In 1.50 and earlier releases the bug could result in static items being codegened multiple times (it seems error prone that mono item collector does that). Since 1.51, I think, the worst outcome is an ICE. The only related bug report I found is #84455.

Marking initializer as reachable is far from ideal, since it is an overestimate of what is reachable, but it is most straightforward implementation strategy.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit eaddc8f with merge 7c6cf24dbb417e698304066497ff26a10b194fdd...

[bors]

☀️ Try build successful - checks-actions
Build commit: 7c6cf24dbb417e698304066497ff26a10b194fdd (7c6cf24dbb417e698304066497ff26a10b194fdd)

[rust-timer]

Queued 7c6cf24dbb417e698304066497ff26a10b194fdd with parent 06f0adb, future comparison URL.

[rust-timer]

Finished benchmarking try commit (7c6cf24dbb417e698304066497ff26a10b194fdd): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[varkor]

@tmiasko: do you have any idea about how to adjust this to avoid the performance hit?

[tmiasko]

In the context of existing reachability pass, I don't see how I could make more fine-grained distinction between things that are reachable at runtime and const-eval time. This is somewhat of a pre-existing problem, since we often codegen functions that are only used by const eval.

@rustbot label: +S-waiting-on-review -S-waiting-on-author

[varkor]

@bors r+

[bors]

📌 Commit eaddc8f has been approved by varkor

[bors]

⌛ Testing commit eaddc8f with merge f8e1e92...

[bors]

☀️ Test successful - checks-actions
Approved by: varkor
Pushing f8e1e92 to master...

[apiraino]

beta backport decision on hold (see Zulip discussion) (possibly we will decline the backport and let this patch land on next stable)

[apiraino]

Beta backport declined as per compiler team on Zulip, patch will land on next stable. Seems in the end this behaviour (at least under certain conditions) has always been broken.

@rustbot label -beta-nominated