Preserve placeholder ambiguity during normalization

[amirHdev]

Fixes #159896

[rustbot]

r? @chenyukang

rustbot has assigned @chenyukang.
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 74 candidates
• Random selection from 16 candidates

[chenyukang]

@rustbot reroll

[petrochenkov]

r? types

[lcnr]

I immediately get this change, can you provide some comment/PR description for what went wrong and why this is correct

r? BoxyUwU

[rustbot]

Failed to set assignee to BoxyUwU: error sending request

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[amirHdev]

I immediately get this change, can you provide some comment/PR description for what went wrong and why this is correct

The problem was that the certainty of the nested goals was combined with the placeholder certainty and then dropped in the normalization path. It is fine to ignore ambiguity from nested goals there since those goals are returned to the caller. placeholder ambiguity is different because it is not reflected in the returned goals
this patch keeps the two values separate and only ignores the nested goal certainty

[lcnr]

r? lcnr makes sense

@bors r+ rollup

[rust-bors]

📌 Commit ba4e2f6 has been approved by lcnr

It is now in the queue for this repository.

[jhpratt]

@bors r- #160128 (comment)

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#160128), which was unapproved.

View changes since this unapproval

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[amirHdev]

@lcnr Rebased onto current main and fixed the ICE by restoring normalization of TypeOutlives caller bounds
@rustbot ready

[rustbot]

Requested reviewer is already assigned to this pull request.

Please choose another assignee.

[rustbot]

Failed to set assignee to ready: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[lcnr]

fixed the ICE by restoring normalization of TypeOutlives caller bounds

please don't. We should properly fix the underlying issues here instead, cc https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/rigid.20aliases.20in.20region.20handling/with/615617676

why does this PR result in new ICEs here? is that a case not covered in the zulip discussion?

[lcnr]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[amirHdev]

why does this PR result in new ICEs here? is that a case not covered in the zulip discussion?

Yes this looks like a separate case
ocx.normalize produces a rigid opaque for the TypeOutlives clause but the following set_opaques_to_non_rigid turns it non-rigid again before region checking which triggers the ICE

Waiting for CI