-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
More reductions in error handling diversity #67770
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of my comments I think get obsoleted by future commits, but along with them, two higher-level comments:
- no real point to moving span_err and friends to struct_span_err(...).emit()
- it is not clear that removing the macros, rather than (e.g.) moving to rustc_errors is helpful
I'm also not super happy with moving things to lints in this PR; feels like maybe there's some discussion to be had, and it's not clear that it brings us benefits from the PR goals perspective. Maybe we could split those commits out? I don't know if we need (e.g.) sign off or so. Seems like probably no, and indeed moving to lints is good.
Would also be good to do some rebase magic and cleanup commits (a few are misspelled or essential duplicates of each other, e.g., I would roll in all the "unused" macro removal into the ~last commit which removes the syntax::diagnostics::macros module.
This comment has been minimized.
This comment has been minimized.
c34ca3b
to
be8f29e
Compare
(For the benefit of everyone reading, here's a summary of notes I left on Discord...)
The point is to encourage adding
I think we should make it harder to emit unstructured / fatal errors as well as hard-coded warnings, and those macros are in the way of that. Also, the diagnostics builder API is good enough that
So lintifying these enabled nixing some of the macros. Beyond that, hard-coded warnings are not something we want outside of things like the NLL transition (which are super rare and don't deserve sugar).
Squashed all into one commit. :) |
Changes look fine to me overall; probably makes sense to wait for @petrochenkov here though. |
+1, if the errors are spanned and structural by default, then it doesn't make sense to write |
We also probably need a variation of |
The variant without a code is just |
@Centril |
be8f29e
to
562389d
Compare
Review comments should be addressed now (except for the new variation on the macro, which I think could be done some other time). |
This comment has been minimized.
This comment has been minimized.
5728919
to
185f28e
Compare
- remove syntax::{help!, span_help!, span_note!} - remove unused syntax::{struct_span_fatal, struct_span_err_or_warn!, span_err_or_warn!} - lintify check_for_bindings_named_same_as_variants + conflicting_repr_hints - inline syntax::{struct_span_warn!, diagnostic_used!} - stringify_error_code! -> error_code! & use it more. - find_plugin_registrar: de-fatalize an error - de-fatalize metadata errors - move type_error_struct! to rustc_typeck - struct_span_err! -> rustc_errors
effdacf
to
20ebb80
Compare
@bors r=petrochenkov |
📌 Commit 20ebb80 has been approved by |
More reductions in error handling diversity In this follow up to #67744, we: - Remove all fatal / error / warning macros in `syntax` except for `struct_span_err`, which is moved to `rustc_errors`. - Lintify some hard-coded warnings which used warning macros. - Defatalize some errors. In general, the goal here is to make it painful to use fatal or unstructured errors and so we hopefully won't see many of these creep in. Fixes #67933.
☀️ Test successful - checks-azure |
Your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Extract `rustc_ast_passes`, move gating, & refactor linting Based on rust-lang#67770. This PR extracts a crate `rustc_ast_passes`: - `ast_validation.rs`, which is contributed by `rustc_passes` (now only has HIR based passes) -- the goal here is to improve recompilation of the parser, - `feature_gate.rs`, which is contributed by `syntax` and performs post-expansion-gating & final erroring for pre-expansion gating, - `show_span`, which is contributed by `syntax`. To facilitate this, we first have to also: - Move `{leveled_}feature_err{_err}` from `syntax::feature_gate::check` into `rustc_session::parse`. - Move `get_features` into `rustc_parse::config`, the only place it is used. - Move some some lint datatypes and traits, e.g. `LintBuffer`, `BufferedEarlyLint`, `BuiltinLintDiagnostics`, `LintPass`, and `LintArray` into `rustc_session::lint`. - Move all the hard-wired lint `static`s into `rustc_session::lint::builtin`.
Extract `rustc_ast_passes`, move gating, & refactor linting Based on rust-lang#67770. This PR extracts a crate `rustc_ast_passes`: - `ast_validation.rs`, which is contributed by `rustc_passes` (now only has HIR based passes) -- the goal here is to improve recompilation of the parser, - `feature_gate.rs`, which is contributed by `syntax` and performs post-expansion-gating & final erroring for pre-expansion gating, - `show_span`, which is contributed by `syntax`. To facilitate this, we first have to also: - Move `{leveled_}feature_err{_err}` from `syntax::feature_gate::check` into `rustc_session::parse`. - Move `get_features` into `rustc_parse::config`, the only place it is used. - Move some some lint datatypes and traits, e.g. `LintBuffer`, `BufferedEarlyLint`, `BuiltinLintDiagnostics`, `LintPass`, and `LintArray` into `rustc_session::lint`. - Move all the hard-wired lint `static`s into `rustc_session::lint::builtin`.
In this follow up to #67744, we:
Remove all fatal / error / warning macros in
syntax
except forstruct_span_err
, which is moved torustc_errors
.Lintify some hard-coded warnings which used warning macros.
Defatalize some errors.
In general, the goal here is to make it painful to use fatal or unstructured errors and so we hopefully won't see many of these creep in.
Fixes #67933.