Disambiguate run_if under rustc's nex generation trait solver

[HugoPeters1024]

Objective

rustc will soon stabilize a next generation trait solver: rust-lang/goals#113.

To use the new solver (and reproduce the compiler error), run the following:

RUSTUP_TOOLCHAIN=nightly-2026-08-22 \
  RUSTFLAGS='-Znext-solver=globally' \
  cargo build -p bevy_pbr

It turns out that this solver is less equipped to disambiguate in some cases, which affect bevy_pbr in a few occasions.

Solution

Some generic function items implement both IntoScheduleConfigs and
ObserverSystemExt. Both traits provide run_if, so the next solver correctly
reports the method call as ambiguous.

Convert the function item to ScheduleConfigs before adding its run condition:

create_surfaces
    .into_configs()
    .run_if(need_surface_configuration)

ScheduleConfigs::run_if is then unambiguous.

Testing

Tested on macOS/aarch64 with separate clean target directories. Looks like this solver is going to shave off meaningful time of bevy's slowest crate 🥳

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

Open question

I suppose this is technically a regression in rustc, although possibly a reasonable one. I can imagine that the disambiguation process was part of the reason that the old solver was less performant. That said, I'll still report this upstream for visiblity.

[SkiFire13]

FYI this is tracked in #25511, it seems the issue is not really an ambiguity but rather an overflow computing some Send trait bounds from wgpu. rust-lang/rust#161552 should have fixed it.

Could also you check how the compile times compare when stacked on top of #25512 ?

[HugoPeters1024]

Thanks @SkiFire13! I should've done a better job scouring existing issues. I haphazardly assumed that I found myself in some niche rabbit hole that wouldn't have been explored before, glad to hear that's not the case!

Could also you check how the compile times compare when stacked on top of #25512 ?

This actually gives very revealing results! Your patch by itself also fixes the same underlying issue that my PR was attempting to fix, and so does compile with the next generation solver.

Adding my patch then naturally doesn't make a big difference, I can only assume that the differences are attributable to noise.

Stack	Solver	bevy_pbr total	Frontend	Codegen
run_if patch	Legacy (-Znext-solver=coherence)	39.0s	32.3s	6.7s
run_if patch	Next (-Znext-solver=globally)	37.6s	29.4s	8.1s
#25512 only	Legacy (-Znext-solver=coherence)	16.7s	10.2s	6.5s
#25512 only	Next (-Znext-solver=globally)	17.4s	9.8s	7.6s
run_if patch + #25512	Legacy (-Znext-solver=coherence)	17.0s	10.4s	6.7s
run_if patch + #25512	Next (-Znext-solver=globally)	16.4s	9.7s	6.8s

[futile]

Adding my patch then naturally doesn't make a big difference, I can only assume that the differences are attributable to noise.

Can you run the "25512 only + Next" and "run_if + 25512 + Next" a couple more times?
Hyperfine (https://github.com/sharkdp/hyperfine) would be a way that gives statistical confidence without needing to specify a certain number of repetitions.
Without that I'd say start with 5-10 repetitions and see what happens?

I'd say 1s total build time for 1 line (maybe with a comment why it was added, i.e., to reduce comp times) would be a nice win, should it turn out not to be noise :)