Revert diagnostics hack to fix ICE 132920

[lqd]

This reverts 8a568d9 from #128849 to fix the diagnostics ICE in #132920.

The hack mentioned in that commit was supposed to be tailored to E277, but that codepath is used actually shared with other errors, e.g. at least the E283 from the linked issue.

We may have to eat the slightly worse diagnostics until a non-hacky way to make this error less verbose is implemented (or I guess a different hack specializing even more to E277's structure).

Sorry @estebank 🙏. I can close this if you'd prefer to fix it in a different way.

Since it seems unexpected that #128849 would impact the repro, here's how the error used to look before that PR.

warning: unused import: `minirapier::Ray`
 --> src/main.rs:2:5
  |
2 | use minirapier::Ray;
  |     ^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0283]: type annotations needed
  --> src/main.rs:10:5
   |
10 |     insert_resource(Res.into());
   |     ^^^^^^^^^^^^^^^ ---------- type must be known at this point
   |     |
   |     cannot infer type of the type parameter `R` declared on the function `insert_resource`
   |
   = note: cannot satisfy `_: Resource`
   = help: the trait `Resource` is implemented for `Res`
note: required by a bound in `insert_resource`
  --> src/main.rs:4:23
   |
4  | fn insert_resource<R: Resource>(_resource: R) {}
   |                       ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
   |
10 |     insert_resource::<R>(Res.into());
   |                    +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
   |
10 -     insert_resource(Res.into());
10 +     insert_resource(Res);

And how it looks now without the ICE.

warning: unused import: `minirapier::Ray`
 --> src/main.rs:2:5
  |
2 | use minirapier::Ray;
  |     ^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

error[E0283]: type annotations needed
  --> src/main.rs:10:5
   |
10 |     insert_resource(Res.into());
   |     ^^^^^^^^^^^^^^^ ---------- type must be known at this point
   |     |
   |     cannot infer type of the type parameter `R` declared on the function `insert_resource`
   |
   = note: cannot satisfy `_: Resource`
note: there are multiple different versions of crate `minibevy` in the dependency graph
  --> /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_b/src/lib.rs:1:1
   |
1  | pub trait Resource {}
   | ^^^^^^^^^^^^^^^^^^ this is the required trait
   |
  ::: src/main.rs:1:5
   |
1  | use minibevy::Resource;
   |     -------- one version of crate `minibevy` is used here, as a direct dependency of the current crate
2  | use minirapier::Ray;
   |     ---------- one version of crate `minibevy` is used here, as a dependency of crate `minirapier`
   |
  ::: /home/lqd/rust/tmp/minimization/issue-132920/rustc-ice-version-conflict/minibevy_a/src/lib.rs:1:1
   |
1  | pub trait Resource {}
   | ------------------ this is the found trait
   = help: you can use `cargo tree` to explore your dependency tree
note: required by a bound in `insert_resource`
  --> src/main.rs:4:23
   |
4  | fn insert_resource<R: Resource>(_resource: R) {}
   |                       ^^^^^^^^ required by this bound in `insert_resource`
help: consider specifying the generic argument
   |
10 |     insert_resource::<R>(Res.into());
   |                    +++++
help: consider removing this method call, as the receiver has type `Res` and `Res: Resource` trivially holds
   |
10 -     insert_resource(Res.into());
10 +     insert_resource(Res);
   |

The improvements from #128849 are still present and the note about the trait coming from the 2 versions of bevy is more explanatory/helpful than before, albeit a bit verbosely.

Fixes #132920.

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
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

[jieyouxu]

Thanks, unfortunate diagnostics change, but ICEing isn't ideal either. You can r=me after PR CI is green.

[jieyouxu]

Remark: this is indeed quite the setup... Thanks for the comments.

[jieyouxu]

Actually I just saw estebank wanted to look at this on zulip, so r? @estebank

[lqd]

Thanks for the quick review @jieyouxu

Esteban may take a look at it soon as well, according to https://rust-lang.zulipchat.com/#narrow/channel/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-11-21/near/483761338 so r? @estebank until then.

[jieyouxu]

(We raced 😆)

[estebank]

@bors r+

[bors]

📌 Commit 764e3e2 has been approved by estebank

It is now in the queue for this repository.

[lqd]

Unfortunately, I hadn't noticed that #128849 was in beta already when we landed this.

So now #132920 could be encountered on stable, and while the setup was quite involved there, another issue with code unrelated to it was opened for the same ICE in #135410.

I guess we can stable nominate this PR, even though it doesn't seem worthy of a point release on its own. A lukewarm nomination.

[apiraino]

Stable backport accepted as per compiler team on Zulip. A backport PR will be authored by the release team. Backport labels handled by them.

This backport alone probably does not justify a dot release.

@rustbot label +stable-accepted +T-compiler