Fix vtable ICE on unsatisfied supertrait bounds

[cdown]

When a trait impl doesn't satisfy its supertrait bounds (for example, impl<T: Send> Bar for T where trait Bar: Droppable but T has no Droppable bound), the compiler emits E0277 and then then continues compilation.

If a static initialiser then upcasts through this broken impl, const evaluation builds the vtable and tries to resolve methods for the unsatisfied supertrait (for example, <bool as Droppable>::drop).

One might think that the impossible_predicates guard in vtable_entries should catch this, but it doesn't, because it calls predicates_of(method).instantiate_own(), which only includes the method's own where clauses, and the parent trait's Self: Trait predicate lives on the trait definition, not the method, so the guard passes and we fall through to expect_resolve_for_vtable, which hits a span_bug! when resolution returns Ok(None).

There was a previous attempt to fix this in #152287, which worked by switching to instantiate_and_check_impossible_predicates, which includes parent predicates and the trait ref. But unfortunately this is unsound and was reverted because impossible_predicates has a pre-existing unsoundness with coroutine witness types and opaque types (see #153596).

Let's take a different approach that avoids impossible_predicates entirely. Let's extract the core of expect_resolve_for_vtable into a fallible try_resolve_for_vtable that returns Result<Instance, ErrorGuaranteed>, and on resolution failure emit a delayed_bug. vtable_entries then can use this and return VtblEntry::Vacant on the error path.

Fixes #154073, #137190

[rustbot]

r? @mati865

rustbot has assigned @mati865.
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 69 candidates
• Random selection from 14 candidates

[cdown]

r? @lcnr

[cdown]

^ that's because we happen to have different resolution ordering after this change. but it's the test that needs adjusting really, it shouldn't care which method it hits, only that it should hit the type length limit

[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.

[cdown]

this is because of the change in ordering.

[cdown]

this is also because of the change in ordering.

[theemathas]

Please also test this code from #154073 (comment)

trait Bar: Sync {
    fn method(&self);
} 
impl<T: Sync> Bar for T {
    // missing method
}
static BAR: &dyn Sync = &false as &dyn Bar;
fn main(){}

[cdown]

Thanks, added.