Ensure stack in two places that affect s390x

[cuviper]

In our Fedora s390x test results, we found two tests that started hitting stack
overflows in the 1.87.0 update. It seems to be related in some part to our use
of PGO as well, probably inlining more into stack frames that were already
recursive. The main points of recursion that I identified were:

• ui/parser/survive-peano-lesson-queue.rs in ThirBuildCx::mirror_exprs
• ui/associated-consts/issue-93775.rs in Parser::parse_ty

A couple new ensure_sufficient_stack calls will solve these tests.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
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

[workingjubilee]

so completely randomly: how does stack work on s390x, @cuviper? is it a normal architecture from the perspective of Rust code, with a stack guard page and normal signals?

[oli-obk]

@bors r+ rollup

[bors]

📌 Commit af2a85b has been approved by oli-obk

It is now in the queue for this repository.

[cuviper]

so completely randomly: how does stack work on s390x, @cuviper? is it a normal architecture from the perspective of Rust code, with a stack guard page and normal signals?

AFAIK it is normal in that regard, so these overflows still hit a SIGSEGV and executed rustc's handler, including the cycle-detecting backtrace which helped me see where we needed the ensure checks. The SystemZ backend just has different optimization tuning that can sometimes cause problems that we don't see on others, like inlining thresholds are probably the culprit here.

These particular test cases do fail on e.g. x86_64 as well if you tighten the default RUST_MIN_STACK, and they pass on s390x if you set a bigger stack. So it's kind of bad luck that only s390x failed in this way, and larger tests probably would have failed everywhere.