backport "rerun in original typing mode if we meet any opaques in post analysis" to stable

[lcnr]

backport of #158993 to stable, fixes #161441

we didn't notice that a beta cutoff happened between #156742 and #158993 and it's easy to forget that we need to be careful with next-solver bugs as they can affect stable via coherence and impossible_predicates.

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 75 candidates
• Random selection from 19 candidates

[rustbot]

⚠️ Warning ⚠️

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

[lcnr]

no idea if this is correct for a stable backport xd

[cuviper]

no idea if this is correct for a stable backport xd

Normally we would just label the original PR and discuss from there, but that's ok.

Did the object test come from a different PR?

[lcnr]

the object test is from #161441.

#158993 was already merged on beta by then. So we don't have that test in our test suite (yet)

[theemathas]

Here's my attempt at drafting the release notes and blog post.

Release notes:

[rustc: fix miscompilation in vtable generation](https://github.com/rust-lang/rust/issues/161441)

Blog post (last paragraph copied from the 1.97.1 blog post):

Rust 1.98.1 fixes a [miscompilation in vtable generation](https://github.com/rust-lang/rust/issues/161441).

In Rust 1.98.0, in some circumstances, rustc would incorrectly generate a trait object vtable with a null pointer
where a function pointer should be. When an affected method is called, this is likely to cause a segmentation fault
with optimizations turned off, but may cause (arbitrary) undefined behavior with optimizations turned on.

If you'd like to help us out by testing future releases, you might consider
running your code's CI or locally using the beta channel (`rustup default beta`) or the nightly
channel (`rustup default nightly`). Please
[report](https://github.com/rust-lang/rust/issues/new/choose) any bugs you
might come across!

[cuviper]

Suggested edits: it should be "affected", and we should probably call this UB directly.

-where a function pointer should be. When an effected method is called, this would cause a segmentation fault
-with optimizations turned off, but may cause arbitrary behavior with optimizations turned on.
+where a function pointer should be. When an affected method is called, this would cause a segmentation fault
+with optimizations turned off, but may cause arbitrary undefined behavior with optimizations turned on.

... although I'm not sure it's even safe to make any specific behavior claim about the non-opt case either.

[theemathas]

although I'm not sure it's even safe to make any specific behavior claim about the non-opt case either.

Edited, and added a "likely" qualifier.