Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup errors handlers even more #118933

Merged
merged 8 commits into from
Dec 15, 2023

Conversation

nnethercote
Copy link
Contributor

A sequel to #118587.

r? @compiler-errors

It's necessary for `derive(Diagnostic)`, but is best avoided elsewhere
because there are clearer alternatives.

This required adding `Handler::struct_almost_fatal`.
It's unclear why this is used here. All entries in the third column of
`UNICODE_ARRAY` are covered by `ASCII_ARRAY`, so if the lookup fails
it's a genuine compiler bug. It was added way back in rust-lang#29837, for no
clear reason.

This commit changes it to `span_bug`, which is more typical.
@rustbot rustbot added A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 14, 2023
@rustbot
Copy link
Collaborator

rustbot commented Dec 14, 2023

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

@rust-log-analyzer

This comment has been minimized.

compiler/rustc_errors/src/lib.rs Show resolved Hide resolved
"It looks like you're trying to break rust; would you like some ICE?",
);
));
handler.note("the compiler expectedly panicked. this is a feature.");
handler.note(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not making a DiagnosticBuilder<'_, Bug> and appending the notes onto that? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. A couple of reasons, AIUI.

First, the API around Bug is currently a bit of a mess:

  • Handler::struct_bug -> DB<!>
  • Handler::span_bug -> !
  • Handler::bug -> !
  • Handler::create_bug -> DB<Bug> (unused)
  • Handler::emit_bug -> Bug (unused)
  • Bug::diagnostic_builder_emit_producing_guarantee -> ! (not Bug)

I.e. it's a mix of return types, unlike all the other diagnostic levels. I want to straighten this out, but I haven't gotten to it yet. I think part of the problem is that the EmissionGuarantee implemented for ! is tied to Level::Fatal rather than Level::Bug, even though Level::Bug should also cause immediate aborts.

Except, this is the one ICE that doesn't actually abort. So if we used struct_bug + emit it would abort. I guess we could use create_bug + emit_bug, but that would require a new type. Maybe good for a follow-up. Or maybe it should just abort? That would make life easier in the long run.

Also, generating distinct notes gives output like this:

error: internal compiler error: It looks like you're trying to break rust; would you like some ICE?

note: the compiler expectedly panicked. this is a feature.

note: we would appreciate a joke overview: https://github.com/rust-lang/rust/issues/43162#issuecomment-320764675

note: rustc 1.76.0-dev running on x86_64-unknown-linux-gnu

Generating a single (non-fatal) abort with appended notes looks like this:

error: internal compiler error: It looks like you're trying to break rust; would you like some ICE?
  |
  = note: the compiler expectedly panicked. this is a feature.
  = note: we would appreciate a joke overview: https://github.com/rust-lang/rust/issues/43162#issuecomment-320764675
  = note: rustc 1.76.0-dev running on x86_64-unknown-linux-gnu

It's possible that the latter output is better, but I didn't want to change it. (I have been wondering what is the use of standalone notes, as opposed to notes attached to errors/warnings/etc...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per our discussion on Zulip: I changed this to a normal aborting ICE, which meant I could just use struct_bug and emit. It did require changing the notes from standalone diagnostics to notes attached to the bug diagnostic, but that seems fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out my introduction of struct_bug broke some things. So in the end I removed that, and also the removal of span_bug_no_panic, and also the changes to this ICE. They can be done in a follow-up once I figure out how to fix struct_bug properly.

@compiler-errors
Copy link
Member

r=me

@compiler-errors compiler-errors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 14, 2023
To `msg: impl Into<DiagnosticMessage>`, like all the other diagnostics.
For consistency.
The `Handler` functions that directly emit diagnostics can be more
easily implemented using `struct_foo(msg).emit()`. This mirrors
`Handler::emit_err` which just does `create_err(err).emit()`.

`Handler::bug` is not converted because of weirdness involving
conflation bugs and fatal errors with `EmissionGuarantee`. I'll fix that
later.
Compare `Handler::warn` and `Handler::span_warn`. Conceptually they are
almost identical. But their implementations are weirdly different.

`warn`:
- calls `DiagnosticBuilder::<()>::new(self, Warning(None), msg)`, then `emit()`
- which calls `G::diagnostic_builder_emit_producing_guarantee(self)`
- which calls `handler.emit_diagnostic(&mut db.inner.diagnostic)`

`span_warn`:
- calls `self.emit_diag_at_span(Diagnostic::new(Warning(None), msg), span)`
- which calls `self.emit_diagnostic(diag.set_span(sp))`

I.e. they both end up at `emit_diagnostic`, but take very different
routes to get there.

This commit changes `span_*` and similar ones to not use
`emit_diag_at_span`. Instead they just call `struct_span_*` + `emit`.

Some nice side-effects of this:
- `span_fatal` and `span_fatal_with_code` don't need
  `FatalError.raise()`, because `emit` does that.
- `span_err` and `span_err_with_code` doesn't need `unwrap`.
- `struct_span_note`'s `span` arg type is changed from `Span` to
  `impl Into<MultiSpan>` like all the other functions.
@rust-log-analyzer

This comment has been minimized.

Currently, `emit_diagnostic` takes `&mut self`.

This commit changes it so `emit_diagnostic` takes `self` and the new
`emit_diagnostic_without_consuming` function takes `&mut self`.

I find the distinction useful. The former case is much more common, and
avoids a bunch of `mut` and `&mut` occurrences. We can also restrict the
latter with `pub(crate)` which is nice.
@nnethercote
Copy link
Contributor Author

This has some stuff removed from the version given r=me, as described above, so I think it should be fine to approve.

@bors r=compiler-errors

@bors
Copy link
Contributor

bors commented Dec 14, 2023

📌 Commit 9a78412 has been approved by compiler-errors

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 14, 2023
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 15, 2023
…kingjubilee

Rollup of 4 pull requests

Successful merges:

 - rust-lang#118908 (Add all known `target_feature` configs to check-cfg)
 - rust-lang#118933 (Cleanup errors handlers even more)
 - rust-lang#118943 (update `measureme` to 10.1.2 to deduplicate `parking_lot`)
 - rust-lang#118948 (Use the `Waker::noop` API in tests)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 9e872b7 into rust-lang:master Dec 15, 2023
11 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Dec 15, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 15, 2023
Rollup merge of rust-lang#118933 - nnethercote:cleanup-errors-even-more, r=compiler-errors

Cleanup errors handlers even more

A sequel to rust-lang#118587.

r? `@compiler-errors`
@nnethercote nnethercote deleted the cleanup-errors-even-more branch December 15, 2023 02:47
compiler-errors added a commit to compiler-errors/rust that referenced this pull request Dec 23, 2023
…mpiler-errors

Cleanup error handlers: round 4

More `rustc_errors` cleanups. A sequel to rust-lang#118933.

r? `@compiler-errors`
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 23, 2023
Rollup merge of rust-lang#119171 - nnethercote:cleanup-errors-4, r=compiler-errors

Cleanup error handlers: round 4

More `rustc_errors` cleanups. A sequel to rust-lang#118933.

r? `@compiler-errors`
bjorn3 pushed a commit to bjorn3/rust that referenced this pull request Dec 24, 2023
…mpiler-errors

Cleanup error handlers: round 4

More `rustc_errors` cleanups. A sequel to rust-lang#118933.

r? `@compiler-errors`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-query-system Area: The rustc query system (https://rustc-dev-guide.rust-lang.org/query.html) S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants