Enable `-Znext-solver` on nightly by default for testing

[lcnr]

Proposal

The next-generation trait solver is getting close to stabilization. When we stabilized its use in coherence checking, we had to revert the stabilization as it surfaced new issues we didn't detect via the crater run:

• stabilize -Znext-solver=coherence rust#121848
• Revert "Stabilize -Znext-solver=coherence" rust#130249
• stabilize -Znext-solver=coherence again rust#130654

This is deeply unpleasant. It would be a lot worse when stabilizing full -Znext-solver as updating our UI test suite will be an incredibly large diff. We currently have more than 700 UI tests for the new solver and changing trait solvers impacts a lot of diagnostics, so blessing affected tests is a pain.

It's also just useful for the Types Team to get additional confidence when stabilizing the solver that its design doesn't have unknown issues. For this, we would like to enable the new trait solver on nightly for a while purely for testing purposes. This feels slightly non-trivial to me.

Doing so should not require us to modify our UI tests. CI and local development should still use the old solver by default, only the nightly release build should enable -Znext-solver by default.

Given that the old solver will still be used on beta and stable, having worse test coverage for it on nightly makes it easier to introduce regressions. Because of this, we intend to block non-trivial changes to the old solver while the new one is enabled by default.

After finishing the behavior changes of our normalization rework rust-lang/rust#155345 we've now started another crater run and I'd like to actually enable the new solver by default during the next month. I intend to do this after an announcement blogpost and a call for testing. See the discussion on zulip :>

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention them here. You can put your own name here if you are planning to mentor the work.

Process

The main points of the [Major Change Process]MCP are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to [Proposals, Approvals and Stabilization](https://forge.rust-lang.org/compiler/proposals-and-stabilization.html) docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read [more about Major Change Proposals on forge]MCP.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[Mark-Simulacrum]

@rustbot second

There's been a bunch of discussion that I think is largely in favor (and I am), so going to second this.