parser: reduce diversity in error handling mechanisms#67744
parser: reduce diversity in error handling mechanisms#67744bors merged 11 commits intorust-lang:masterfrom
Conversation
rust-highfive
added
the
S-waiting-on-review
| | ^ unexpected `(` after qualified path | ||
| | ------------------^ unexpected `(` after qualified path | ||
| | | | ||
| | the qualified path |
There was a problem hiding this comment.
I could make this recover, but then the vec![...] => recovery has to go away (and I think it should, because it is causing problems in #66364 as well).
There was a problem hiding this comment.
It'd be a shame to lose it entirely, but if it improves this case it might be worth it. For the vec case if we lose the suggestion at least it should recover gracefully.
There was a problem hiding this comment.
Is there a way to have the vec![...] work with resolve instead of first checking if there is an error in expansion (i.e. check if the path is actually {core,std}::vec)? Perhaps we can use diagnostic_items? It feels like the current encoding of the error is problematic in terms of infrastructure. What do you think @petrochenkov?
There was a problem hiding this comment.
The vec![...] hack is really bad, but I cannot answer whether it can be done it a better way without some investigation.
|
Finally! |
|
@bors r+ Perhaps it's time to eliminate |
|
📌 Commit 2e78061 has been approved by |
bors
added
S-waiting-on-bors
Worth a try, I think, 👍. |
…enkov parser: reduce diversity in error handling mechanisms Instead of having e.g. `span_err`, `fatal`, etc., we prefer to move towards uniformly using `struct_span_err` thus making it harder to emit fatal and/or unstructured diagnostics. This PR also de-fatalizes some diagnostics. r? @estebank
Rollup of 6 pull requests Successful merges: - #67574 (Extract `rustc_ast_lowering` crate from `rustc`) - #67685 (Constify Result) - #67702 (Add symbol normalization for proc_macro_server.) - #67730 (Cleanup pattern type checking, fix diagnostics bugs (+ improvements)) - #67744 (parser: reduce diversity in error handling mechanisms) - #67748 (Use function attribute "frame-pointer" instead of "no-frame-pointer-elim") Failed merges: r? @ghost
…chenkov More reductions in error handling diversity In this follow up to rust-lang#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.
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.
5 participants
Instead of having e.g.
span_err,fatal, etc., we prefer to move towards uniformly usingstruct_span_errthus making it harder to emit fatal and/or unstructured diagnostics.This PR also de-fatalizes some diagnostics.
r? @estebank