Better handling for panics during linting#20252
Better handling for panics during linting#20252amyreese wants to merge 3 commits intogh/amyreese/2/basefrom
Conversation
- Convert panics to diagnostics with id `Panic`, severity `Fatal`, and the error as the diagnostic message, annotated with a `Span` with empty code block and no range. - Updates the post-linting message diagnostic handling to track the maximum severity seen, and then prints the "report a bug in ruff" message only if the max severity was `Fatal` This depends on the sorting changes since it creates diagnostics with no range specified. ghstack-source-id: cf7173c Pull-Request: #20252
- Convert panics to diagnostics with id `Panic`, severity `Fatal`, and the error as the diagnostic message, annotated with a `Span` with empty code block and no range. - Updates the post-linting message diagnostic handling to track the maximum severity seen, and then prints the "report a bug in ruff" message only if the max severity was `Fatal` This depends on the sorting changes since it creates diagnostics with no range specified. ghstack-source-id: 77a0547 Pull-Request: #20252
ntBre
left a comment
There was a problem hiding this comment.
Thanks! I had a few suggestions, mostly based on the related code in ty. I'd also be interested in adding a panicking test rule so that we can see this in action. You can see some examples of those here:
ruff/crates/ruff_linter/src/rules/ruff/rules/test_rules.rs
Lines 1 to 3 in df142de
crates/ruff/src/commands/check.rs
Outdated
There was a problem hiding this comment.
I wonder if we should follow ty again here, or maybe even factor out a common panic Diagnostic constructor:
ruff/crates/ty_project/src/lib.rs
Lines 687 to 697 in df142de
Some of the code for constructing the main message might even be helpful for us too.
There was a problem hiding this comment.
I think the benefit of putting this outside the diagnostic is that we get the clear error message at the bottom after the diagnostic messages, cluing the user into the existence of a panic.
There was a problem hiding this comment.
Oh right, I was still thinking that we'd sort by ascending severity, like in RenderingSortKey, so that the panics would be at the end, but that makes sense if we don't want to sort.
There was a problem hiding this comment.
Oh that's not the main comparison in RenderingSortKey anyway, hmm. It looks like ty has a relatively short logging/tracing message but still most of this in the diagnostic:
Lines 365 to 369 in df142de
I've got a commit in progress to do that, but I need to figure out how to get that panic to only happen on the right inputs or whatever, because otherwise it breaks/ruins all the existing text rule fixtures/snapshots. But also the current test rule doesn't go through the same code path, so it ends up creating a |
- Convert panics to diagnostics with id `Panic`, severity `Fatal`, and the error as the diagnostic message, annotated with a `Span` with empty code block and no range. - Updates the post-linting message diagnostic handling to track the maximum severity seen, and then prints the "report a bug in ruff" message only if the max severity was `Fatal` This depends on the sorting changes since it creates diagnostics with no range specified. ghstack-source-id: 8cda710 Pull-Request: #20252
Stack from ghstack (oldest at bottom):
Panic, severityFatal, andthe error as the diagnostic message, annotated with a
Spanwithempty code block and no range.
maximum severity seen, and then prints the "report a bug in ruff"
message only if the max severity was
FatalThis depends on the sorting changes since it creates diagnostics with no
range specified.