beta-backport of provenance-related CTFE changes

[RalfJung]

This is all part of dealing with #99923.

The first commit backports the effects of #101101. @pnkfelix asked for this and it turned out to be easy, so I think this is uncontroversial.

The second commit effectively repeats #99965, which un-does the effects of #97684 and therefore means #99923 does not apply to the beta branch. I honestly don't think we should do this; the sentiment in #99923 was that we should go ahead with the change but improve diagnostics. But @pnkfelix seemed to request such a change so I figured I would offer the option.

I'll be on vacation soon, so if you all decide to take the first commit only, then someone please just force-push to this branch and remove the 2nd commit.

[rustbot]

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @cjgillot

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

[rust-highfive]

⚠️ Warning ⚠️

• Pull requests are usually filed against the master branch for this repo, but this one is against beta. Please double check that you specified the right target!

[pnkfelix]

I suppose I don't know what I want, and I'm trying to get enough information to decide what I want.

I don't want 1.64 to silently break the world; it seems obvious that we do have that, at least with respect to #99923. 👍

I also don't want 1.64 to loudly break the the world. Our crater runs indicate that we probably have that too. 👍

I don't want to re-litigate RFC rust-lang/rfcs#3016, (as some have suggested would be a an implication of reverting #97684 ), in a sudden/rash manner.

• (I personally don't consider suggesting attempting a future-incompat cycle to be re-litigating that RFC; that RFC did not say we would require future-incompat cycles between changes to the UB detection, but it also didn't say we wouldn't. It left the development choices there unspecified, ha ha, and several project members such as myself didn't understand the implications thereof, given the constraints of the current CTfE code architecture until now.)

---

I am tempted to suggest that we go ahead and do exactly what @RalfJung would prefer here: land just the first commit in beta.

That way, we have the second commit in our back pocket if it turns out that 1.64.0 does cause significant breakage, then we do a quick 1.64.1 point release that adds the second commit. (But I'm assuming we are very unlikely to go down that path, so I'm not going to further muse on the implications of that choice on versions 1.65 and above.)

[RalfJung]

r? @pnkfelix

[RalfJung]

I am tempted to suggest that we go ahead and do exactly what @RalfJung would prefer here: land just the first commit in beta.

All right, I removed the 2nd commit.

[apiraino]

Beta backport discussed and accepted in compiler team meeting on Zulip

@rustbot label beta-nominated beta-accepted

[pnkfelix]

@bors r+

[bors]

📌 Commit c7f8e68 has been approved by pnkfelix

It is now in the queue for this repository.

[bors]

⌛ Testing commit c7f8e68 with merge 25912c0...

[bors]

☀️ Test successful - checks-actions
Approved by: pnkfelix
Pushing 25912c0 to beta...