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

fix ice reporting in lintcheck #12439

Merged
merged 1 commit into from
Apr 5, 2024
Merged

fix ice reporting in lintcheck #12439

merged 1 commit into from
Apr 5, 2024

Conversation

Jacherr
Copy link
Contributor

@Jacherr Jacherr commented Mar 8, 2024

Fixes #12185

This PR fixes the lack of reported ICEs within lintcheck by modifying the way in which data is collected from each crate being linted.

Instead of lintcheck only reading stdout for warnings, it now also reads stderr for any potential ICE (although admittedly, it is not the cleanest method of doing so). If it is detected, it parses the ICE into its message and backtrace separately, and then adds them to the list of outputs via clippy.

Once all outputs are collected, the formatter then proceeds to generate the file as normal.

Note that this PR also has a couple of side effects:

  • When clippy fails to process a package, but said failure is not an ICE, the stderr will be sent to the console;
  • Instead of ClippyWarning being the primary struct for everything reported, there is now ClippyCheckOutput, an enum which splits the outputs into warnings and ICEs.

changelog: none

@rustbot
Copy link
Collaborator

rustbot commented Mar 8, 2024

r? @blyxyas

rustbot has assigned @blyxyas.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Mar 8, 2024
@Jacherr Jacherr changed the title add support for ice reporting fix ice reporting in lintcheck Mar 8, 2024
Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

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

Meow meow 😸
Hmmm... I think you're over-complicating things.
ClippyWarning::new has an argument of type Diagnostic, a field of this type describes if the diagnostic is produced by an ICE or just a normal warning (the field level).

You could maintain the is_ice field, and just fix the behaviour without manually parsing the stderr and implementing a new enum and struct :)

On line 668 of the original commit, it seems like some filtering is trying to be applied, look for what's wrong and work your way up from there.

@Jacherr
Copy link
Contributor Author

Jacherr commented Mar 15, 2024

The big issue is that there isn't any way to produce proper ClippyWarnings from an ICE. This stems from the fact that ICEs do not follow the normal format of diagnostics (not JSON), so they can't be parsed into a diagnostic like a normal JSON warning (see https://github.com/rust-lang/rust-clippy/blob/master/lintcheck/src/main.rs#L431).

This is also compounded by the fact that Diagnostics cannot be constructed manually due to the fact they are marked #[non_exhaustive]. This is why I had to make a new enum, so I could skip the diagnostic construction step entirely.

For a bit more detailed insight as to why this PR does what it does, I put my findings into a comment on the original issue: #12185 (comment). However, if it would be best to take a new approach (such as making diagnostics no longer #[non_exhaustive]) that should also work.

@blyxyas
Copy link
Member

blyxyas commented Mar 16, 2024

Okis, I'll just focus on logical errors and syntax then, let's hope that nobody has to look at this in the future ❤️

@Jacherr
Copy link
Contributor Author

Jacherr commented Mar 16, 2024

I agree the fix itself isn't the most elegant but sadly I couldn't really think of a better approach given the dilemma of a lack of proper JSON for ICEs 🙃 if such a feature ever comes to exist this can probably be revisited

@matthiaskrgr
Copy link
Member

the missing json for ices is tracked here rust-lang/rust#114302

Comment on lines 119 to 127
for line in lines {
if line.contains("panicked at") {
reading_message = true;
message_lines.push(line.to_owned());
} else if line.contains("stack backtrace:") {
reading_message = false;
reading_backtrace = true;
backtrace_lines.push(line.to_owned());
} else if line.contains("the compiler unexpectedly panicked") {
Copy link
Member

Choose a reason for hiding this comment

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

@matthiaskrgr
Copy link
Member

What you can also do is to check the exit code of clippy (should be 101 for a vanilla ICE (pun intended) for example) https://github.com/matthiaskrgr/icemaker/blob/master/src/main.rs#L1137
in addition to looking at the output, you want both, because if your program by any chance has something like stack backtrace: in a format string that gets linted or throws an error on clippy, you don't want that to be recognized as an ICE.

Comment on lines 118 to 134

for line in lines {
if line.contains("panicked at") {
reading_message = true;
message_lines.push(line.to_owned());
} else if line.contains("stack backtrace:") {
reading_message = false;
reading_backtrace = true;
backtrace_lines.push(line.to_owned());
} else if line.contains("the compiler unexpectedly panicked") {
reading_backtrace = false;
} else if reading_message {
message_lines.push(line.to_owned());
} else if reading_backtrace {
backtrace_lines.push(line.to_owned());
}
}
Copy link
Member

Choose a reason for hiding this comment

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

I remember that I had problems at some point where rustc would generate so much output that I would essentially run out of ram with stderr/stdout.contains() and had to switch over iterating over the output line by line.

there are also different kind of ices, like assertion failures or perhaps "panic!()" inside clippys and rustcs delayed bugs

#![allow(internal_features)]
#![feature(rustc_attrs)]
#[rustc_error(delayed_bug_from_inside_query)]
fn main() {}

I don't think this will be able to parse all of them very well

@blyxyas
Copy link
Member

blyxyas commented Apr 1, 2024

@Jacherr I assumed you were going to apply Matthias' suggestions, but it seems like this has been a little bit paused 😅.

Could you please apply them ❤️

@Jacherr
Copy link
Contributor Author

Jacherr commented Apr 2, 2024

Hi, apologies for the delays, been fairly busy the last couple weeks. I'll go through and take a look now - @matthiaskrgr I suppose the easiest solution is to simply provide a raw stderr rather than attempting to parse anything out of the ICE?

Copy link
Member

@blyxyas blyxyas left a comment

Choose a reason for hiding this comment

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

LGTM, thanks! ❤️
I've added a separator so that people can read the outputs easier and already squashed the commits for you, just because I was there.

Thanks for the contribution! Meow meow 😸

@blyxyas
Copy link
Member

blyxyas commented Apr 5, 2024

@bors r+

@bors
Copy link
Contributor

bors commented Apr 5, 2024

📌 Commit 42d0970 has been approved by blyxyas

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Apr 5, 2024

⌛ Testing commit 42d0970 with merge eecff6d...

@bors
Copy link
Contributor

bors commented Apr 5, 2024

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: blyxyas
Pushing eecff6d to master...

@bors bors merged commit eecff6d into rust-lang:master Apr 5, 2024
5 checks passed
@Jacherr Jacherr deleted the issue-12185 branch May 29, 2024 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lintcheck never reports ICEs
5 participants