-
Notifications
You must be signed in to change notification settings - Fork 979
Get the Check Diff rust binary working #6751
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
Conversation
db0480a to
01e646c
Compare
c3cd596 to
8bf953a
Compare
8bf953a to
78fdb19
Compare
This is how cargo determines which environment variable to set when running `cargo run` and helps to allow the binary to run on more operating systems than just linux.
I think this makes the overall code better. Also removes an unecessary lifetime annotation.
in most cases I'd expect to get valid UTF-8, and in the rare event that we don't get valid UTF-8 including some replacement characters should be fine.
The `CheckDiffError` that was returned in the error case was too broad and I felt that the code could be simplified if we returned a type that specifically captured what went wrong.
The `CheckDiffError` that was previously returned in the error case was too broad and I felt that the code could be simplified if we returned a type that specifically captured what went wrong when trying to create a diff between two formatter.
This updates some logging output to be more descriptive and also adds some `debug!` and `error!` logging.
Now after we compile both rustfmt binaries we iterate through each repository and process each check in its own thread. This implementation more or less follows the behavior from `ci/check_diff.sh`, but it's faster since we're able to process each repository in parallel.
When rustfmt knows the file path it's able to skip formatting for files listed in the repo's rustfmt.toml `ignore` list. This helps when us process files in r-l/rust that have been explicitly skipped. Otherwise we'll try to format files that cause rustfmt to hang.
`i32` didn't seem like the right return type to me. Since we're just recording that any error happened `u8` seemed good enough for that.
This let's us controll the rust language edition used to parse source code and the rustfmt style edition used for code formatting.
78fdb19 to
45967f5
Compare
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.
Thanks! Looks good to me overall, a few nits
(Reviewed commit-by-commit, not sure if new github review experience is handling that quite right)
| let Ok(tmp_dir) = tempdir() else { | ||
| warn!( | ||
| "Failed to create a tempdir for {}. Can't check formatting diff for {}", | ||
| &url, repo_name | ||
| ); | ||
| return; | ||
| }; |
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.
Discussion: should this just error1? Feels a bit strange if diffchecks between different runs of the job can be over a different set of repos (over possibly transient fs/env issues).
Ditto for the git repo clone below, but that one is particularly susceptible to network conditions and github's own availability...
EDIT: I realize (as a counter-argument to erroring) that it's possible to have timings where the main/master/default branch of these repos don't necessarily build against the nightly toolchain corresponding to the main/feature rustfmt (in theory), due to some recently bumped lints and such. But yeah.
Footnotes
-
As in, we can (in a follow-up) either add retry logic to tempdir creation, or retry the entire job, or a combination of both ↩
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.
Adding some retry logic here would be really valuable. I'd be happy to work on that in a follow up PR. The one thing I was trying to avoid was having the whole job fail just because we failed to create the tempdir or clone one or two of the repos that we wanted to check.
I feel like the main purpose of this job is to give us confidence that we're not releasing any breaking changes, and as long as we cover a decent number of codebases I think we'll still be okay even if some fail.
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.
Yeah, that makes sense 👍
| /// rust edition 2024 | ||
| Edition2024, |
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.
Remark (non-actionable): internally in rustc, there's also edition=next
|
@jieyouxu Happy to address any nits before moving forward. Thanks for taking a look at the PR! |
Now we'll output the error that lead to us failing to compile one or both of the rustfmt binaries before exiting with a failure.
jieyouxu
left a comment
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.
The current version looks good to me, thanks!
The Diff Check Job is integral to making sure we don't introduce breaking formatting changes. An effort was started by a contributor a while ago to rewrite the tool in rust, but that stalled out. I'd like to cut over to this rewritten rust version, which I think is an improvement over the current shell script and I think it should should help us get things unstuck and allow us to complete the next subtree sync with confidence that we're not introducing any breaking changes.
The PR is broken up into smaller commits, and I'd recommend reviewing things one commit at a time, but also happy to break this up into smaller commits if that's preferred.
Note: I plan to update the
.github/workflows/check_diff.ymlin a follow PR after this landsr? @calebcartwright @jieyouxu @Manishearth