Fix error counting #62055
Fix error counting #62055
Conversation
|
@bors r+ rollup |
|
📌 Commit 95a3215 has been approved by |
bors
added
the
S-waiting-on-bors
|
nominating for beta backport since it fixes an ICE that is a stable-to-beta regression. |
pnkfelix
added
beta-nominated
…=pnkfelix Fix error counting Count duplicate errors for `track_errors` and other error counting checks. Add FIXMEs to make it clear that we should be moving away from this kind of logic. Closes rust-lang#61663
…=pnkfelix Fix error counting Count duplicate errors for `track_errors` and other error counting checks. Add FIXMEs to make it clear that we should be moving away from this kind of logic. Closes rust-lang#61663
Rollup of 7 pull requests Successful merges: - #61814 (Fix an ICE with uninhabited consts) - #61987 (rustc: produce AST instead of HIR from `hir::lowering::Resolver` methods.) - #62055 (Fix error counting) - #62078 (Remove built-in derive macros `Send` and `Sync`) - #62085 (Add test for issue-38591) - #62091 (HirIdification: almost there) - #62096 (Implement From<Local> for Place and PlaceBase) Failed merges: r? @ghost
|
@rust-lang/compiler We need to get beta backports approved a little earlier this cycle as we're promoting beta->stable on Saturday. If we could get an FCP going for beta-accepted on this PR that'd be great; or if someone wants to unilaterally beta accept that works too. |
|
I'm going to un-nominate this. The ICEs it resolves do not seem like a critical issue to me: As far as I can tell, the only say these ICEs ever arise is after some legitimate error diagnostic has already been emitted, and we just failed to halt the compilation as soon as we should have. But the compilation should always halt, potentially via an ICE, without generating object code. @matthewjasper does that sound correct to you? Or is there a scenario where this could somehow generate an error diagnostic, but then end up not having any ICE and end up emitting potentially erroneous object code? |
pnkfelix
removed
the
beta-nominated
| @@ -4376,7 +4376,7 @@ pub fn check_bounds_are_used<'tcx>(tcx: TyCtxt<'tcx>, generics: &ty::Generics, t | |||
| } else if let ty::Error = leaf_ty.sty { | |||
| // If there is already another error, do not emit | |||
| // an error for not using a type Parameter. | |||
| assert!(tcx.sess.err_count() > 0); | |||
| assert!(tcx.sess.has_errors()); | |||
There was a problem hiding this comment.
Code like this should probably be using delay_span_bug uniformly.
There was a problem hiding this comment.
I'd prefer an EmittedError type only created by emitting errors and putting that in ty::Error instead.
There was a problem hiding this comment.
That's even nicer - we might want to use that in the AST and HIR as well.
But maybe it should be something less temporarily ordered, so if there is some place where ty::Error needs to be created but it's not the same place the errors is to be reported from, we can still create a proof that "some error has happened or will happen" with delay_span_bug.
Count duplicate errors for
track_errorsand other error counting checks.Add FIXMEs to make it clear that we should be moving away from this kind of logic.
Closes #61663