builtin dyn impl no guide inference

[lcnr]

cc #141347

we can already slightly restrict this behavior in the old solver, so why not do so. Needs crater and an FCP.

r? @compiler-errors

[lcnr]

@bors try

[bors]

⌛ Trying commit a7e2981 with merge 15e8bc6...

[bors]

☀️ Try build successful - checks-actions
Build commit: 15e8bc6 (15e8bc6907ab2b3623cb52acc726f4787458df64)

[compiler-errors]

@craterbot check

[craterbot]

👌 Experiment pr-141352 created and queued.
🤖 Automatically detected try build 15e8bc6
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🚧 Experiment pr-141352 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment pr-141352 is completed!
📊 4 regressed and 5 fixed (635013 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[compiler-errors]

That dyn ToJs<...>: ToJs<_> example may be literally the only one that relies on inference here lol: https://crater-reports.s3.amazonaws.com/pr-141352/try%2315e8bc6907ab2b3623cb52acc726f4787458df64/reg/px-wsdom-javascript-0.0.5/log.txt

[lcnr]

This PR disables the incomplete inference guidance if there's both a user-written and builtin trait object implementation in the old solver:

trait Equals<T: ?Sized> {}

impl<T: ?Sized> Equals<T> for T {}

fn impls_equals<T: Equals<U> + ?Sized, U: ?Sized>() {}

fn main() {
    // Two candidates:
    // - via user impl, constrains `U` to `dyn Equals<u32>`
    // - via builtin impl, constrains `U` to `u32`
    //
    // We previously constrained it to `dyn Equals<u32>`, with this change
    // its ambiguous.
    impls_equals::<dyn Equals<u32>, _>();
}

This behavior should be unsound in coherence with the old solver, luckily we no longer use that. I don't think this guidance is desirable and explicitly do not do so in the new solver.

Crater found a single regression: https://crates.io/crates/px-wsdom-javascript/0.0.5. We should open a PR fixing the regression before landing this change.

@rfcbot fcp merge

[rfcbot]

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[compiler-errors]

r=me after fcp

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[lcnr]

@bors r=compiler-errors rollup

[bors]

📌 Commit bde63bb has been approved by compiler-errors

It is now in the queue for this repository.

[apiraino]

Given the beta regression #143831 does this deserve a mention in the relnotes?

[lcnr]

yes, though I think we automatically include changes which went through an FCP regardless, see #142465 which got automatically opened once the FCP finished

[BoxyUwU]

#142465