Regression in trait disambiguation with the next generation trait solver (`-Znext-solver=globally`)

[HugoPeters1024]

I was playing with the next generation trait solver (which is said to stabilize soon: rust-lang/goals#113) on Bevy. Bevy has a notoriously slow to compile subcrate called bevy_pbr and was hoping to see some improvements.

The good new is that the improvement is real and substantial:

Solver	bevy_pbr total	Frontend	Codegen
Legacy (-Znext-solver=coherence)	40.8s	33.9s	6.9s
Next (-Znext-solver=globally)	32.9s	25.5s	7.4s

The bad news is that it became less equipped to deal with ambiguity. In this case the patch is relatively simple and acceptable: bevyengine/bevy#25533. That said, stabilization of the next generation trait solver would technique constitute a regression.

If the answer is, "the next generation solver can only be this performant because it chooses to reject ambiguity" then I'm also relatively satisfied, just wanted to make sure this is a conscious decision.

Tested using rustc 1.100.0-nightly (c656540d6 2026-08-21)

[HugoPeters1024]

While trying to make a minimal, dependency-free reproducer, I've come to wonder if it's not actually the current coherence solver that is at fault. Because I don't see how it is able to resolve the following ambiguity without simply discarding the possibility that the opaque impl Sized return type could be u32, making both Schedule::run_if and the blanket Observer::run_if applicable.

// `rustc -Znext-solver=coherence this_file.rs` accepts this on
// nightly-2026-08-22. Replacing `coherence` with `globally` gives E0034.
//
// Crux: the recursive opaque return type might be `u32`, so the next solver
// considers both extension traits below to be candidates for `.run_if()`.

struct System<T>(T);

trait Schedule: Sized {
    fn run_if(self) {}
}

impl Schedule for System<u32> {}

trait Observer: Sized {
    fn run_if(self) {}
}

impl<T> Observer for System<T> {}

fn system(recurse: bool) -> System<impl Sized> {
    if recurse {
        system(false).run_if();
    }
    System(42_i32)
}

fn main() {}

[lcnr]

can you try the current main branch with https://github.com/kennytm/rustup-toolchain-install-master (or nightly tomorrow)

I think this should be fixed by #161552 which has been merged today. I think the bevy regression was bevyengine/bevy#25511?

[lcnr]

jup, bevy_pbr also compiles with after that change

warning: overflow evaluating the requirement `WireframeWideBindGroups: Sync`
   --> src/wireframe.rs:407:10
    |
407 | #[derive(Resource, Default)]
    |          ^^^^^^^^
    |
    = note: which requires `bevy_platform::collections::HashMap<AssetId<bevy_mesh::Mesh>, (bevy_render::render_resource::BindGroup, u32)>: Sync`
    = note: which requires `hashbrown::map::HashMap<AssetId<bevy_mesh::Mesh>, (bevy_render::render_resource::BindGroup, u32), FixedHasher>: Sync`
    = note: which requires `hashbrown::raw::RawTable<(AssetId<bevy_mesh::Mesh>, (bevy_render::render_resource::BindGroup, u32))>: Sync`
    = note: which requires `(AssetId<bevy_mesh::Mesh>, (bevy_render::render_resource::BindGroup, u32)): Sync`
    = note: which requires `(bevy_render::render_resource::BindGroup, u32): Sync`
    = note: which requires `bevy_render::render_resource::BindGroup: Sync`
    = note: which requires `WgpuWrapper<wgpu::api::bind_group::BindGroup>: Sync`
    = note: which requires `wgpu::api::bind_group::BindGroup: Sync`
    = note: which requires `wgpu::dispatch::DispatchBindGroup: Sync`
    = note: which requires `Arc<wgpu::backend::wgpu_core::CoreBindGroup>: Sync`
    = note: which requires `wgpu::backend::wgpu_core::CoreBindGroup: Send`
    = note: which requires `wgpu::backend::wgpu_core::ContextWgpuCore: Send`
    = note: which requires `Arc<wgpu_core::global::Global>: Send`
    = note: which requires `wgpu_core::global::Global: Send`
    = note: which requires `wgpu_core::hub::Hub: Send`
    = note: and so on...
    = help: consider adding a manual `impl` of auto traits like `Send` for intermediate types, if auto traits are involved
    = help: or consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`bevy_pbr`)
    = note: this lint is attached to the whole crate and can't be disabled on a per-function basis
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #159228 <https://github.com/rust-lang/rust/issues/159228>
    = note: `#[warn(recursion_depth_exceeding_limit)]` (part of `#[warn(future_incompatible)]`) on by default
    = note: this warning originates in the derive macro `Resource` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: `bevy_pbr` (lib) generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 32s

[theemathas]

@lcnr Does that PR change how method resolution works? That sounds odd to me.

[HugoPeters1024]

@lcnr it looks like the bevy_pbr problem itself was already discovered and root caused some extent: bevyengine/bevy#25511. It confusingly was the result of some Send/Sync shenanigans.

However, the reproducer I posted above still fails on the latest main (04a3cad16c5) with globally solver but not coherence 🤔

[lcnr]

@lcnr Does that PR change how method resolution works? That sounds odd to me.

that PR causes method selection to discard candidates if they depend on a goal which only evaluates to NoSolution with double the recursion limit.

However, the reproducer I posted above still fails on the latest main (04a3cad) with globally solver but not coherence 🤔

👍 that is not required for bevy_pbr, is it? I don't have a strong opinion on whether this example should compile. We don#t know the fact that impl Sized is i32 at the point of doing method selection here.

What is your expected behavior for

struct System<T>(T);

trait Schedule: Sized {
    fn run_if(self) {}
}

impl Schedule for System<u32> {}

trait Observer: Sized {
    fn run_if(self) {}
}

impl<T> Observer for System<T> {}

fn system(recurse: bool) -> System<impl Sized> {
    if recurse {
        system(false).run_if();
    }
    System(42_u32)
}

fn main() {}

[HugoPeters1024]

that is not required for bevy_pbr, is it?

Having now understood the issue better, it's clear that my reproducer was not representative of the bevy_pbr issue.

In fact, I'd say that throwing an error on that file is in fact the desired behavior! In the case of System(42_u32) there really are 2 equivalently valid choices. So in hindsight, I think globally actually improves upon coherence here 🥳