do not normalize all non-scalar constants to a ConstValue::ScalarPair

[RalfJung]

We still need ConstValue::ScalarPair for match handling (matching slices and strings), but that will never see anything Undef. For non-fat-ptr ScalarPair, just point to the allocation like larger data structures do.

Fixes #54387

r? @eddyb

[RalfJung]

Cc @oli-obk

[oli-obk]

@bors r+

[bors]

📌 Commit d62aa3e has been approved by oli-obk

[RalfJung]

A less risky variant for beta might be to just backport the changes in const_eval to normalize fewer things, but not get rid of the ScalarMaybeUndef in ConstValue entirely.

[bors]

⌛ Testing commit d62aa3e with merge 7cbcdae...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: oli-obk
Pushing 7cbcdae to master...

[rust-highfive]

📣 Toolstate changed by #54693!

Tested on commit 7cbcdae.
Direct link to PR: #54693

💔 clippy-driver on windows: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 clippy-driver on linux: test-pass → build-fail (cc @Manishearth @llogiq @mcarton @oli-obk, @rust-lang/infra).
💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
💔 rls on windows: test-pass → build-fail (cc @nrc, @rust-lang/infra).
💔 rls on linux: test-pass → build-fail (cc @nrc, @rust-lang/infra).

[eddyb]

So the argument here is that anything that doesn't need an allocation should be fully initialized?
(I expected ScalarMaybeUndef to be used more, but I see why you'd want the opposite)

[RalfJung]

So the argument here is that anything that doesn't need an allocation should be fully initialized?

Yes. We have those variants only because pattern matching and some code around array lengths need them. No reason they should have to handle Undef.

Everything gets an allocation anyway from the way const_eval works, it's just for some types we decide to get stuff out of the allocation earlier. It's a bit messy, and I'd prefer if these were different types and we had one query that always returns an allocation and another than always returns an immediate (and is only used in a few places).

[RalfJung]

Also see #54738

[RalfJung]

I made a beta backport at #54759

[RalfJung]

Oh dang. Now I see @oli-obk already did that. oops^^

[pnkfelix]

T-compiler accepted #54759 for the backport.