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

feat: check-in cargo dylint with format_error lint #13750

Merged
merged 5 commits into from
Dec 1, 2023
Merged

Conversation

BugenZhao
Copy link
Member

@BugenZhao BugenZhao commented Nov 30, 2023

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

Check-in cargo dylint lints. See lints/README.md for more information.

As described in #13725, it's not a good practice to directly format an error with Display or Debug. However, it could be quite painful for developers to manually find and correct them.

In this PR, we leverage cargo dylint to write a custom lint called format_error and check the usages. The experience for both development and check is quite similar to clippy, so it can be easily continuously integrated.

image image image

To keep the PR clean, I haven't integrated it to CI or RiseDev now. Will do this in next PRs.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
Signed-off-by: Bugen Zhao <i@bugenzhao.com>
path = "ui/format_error.rs"

[dependencies]
clippy_utils = { git = "https://github.com/rust-lang/rust-clippy", rev = "a585cda701581a16894858dc088eacd5a02fc78b" } # should match the toolchain version
Copy link
Member

Choose a reason for hiding this comment

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

Maybe we will need to add a script or checklist comments in rust-toolchain for updating toolchain now 🤣

Copy link
Member

Choose a reason for hiding this comment

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

BTW, why does it need to match

Copy link
Member Author

Choose a reason for hiding this comment

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

The internal API of rustc is not stable, which rust-clippy depends on.

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe we will need to add a script or checklist comments in rust-toolchain for updating toolchain now 🤣

It's okay. Mismatched version of clippy_utils usually won't compile.

Copy link

codecov bot commented Nov 30, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (4b02d3a) 68.22% compared to head (f9d9c79) 68.22%.
Report is 7 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main   #13750   +/-   ##
=======================================
  Coverage   68.22%   68.22%           
=======================================
  Files        1523     1523           
  Lines      262075   262075           
=======================================
  Hits       178801   178801           
  Misses      83274    83274           
Flag Coverage Δ
rust 68.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@xxchan xxchan left a comment

Choose a reason for hiding this comment

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

I wanted to rubber stamp, but one thing makes me hesitant: clippy is already very slow, and dylint needs to rebuild the project once again. How to resolve this issue?

@liurenjie1024
Copy link
Contributor

I wanted to rubber stamp, but one thing makes me hesitant: clippy is already very slow, and dylint needs to rebuild the project once again. How to resolve this issue?

+1. Is it really worth it?

@TennyZhuang
Copy link
Contributor

Perhaps one lint is not worth it, but I can think of many rules, so I weakly support this.

@TennyZhuang
Copy link
Contributor

and dylint needs to rebuild the project once again. How to resolve this issue

parallelize them?

@BugenZhao
Copy link
Member Author

I wanted to rubber stamp, but one thing makes me hesitant: clippy is already very slow, and dylint needs to rebuild the project once again. How to resolve this issue?

+1. Is it really worth it?

It's not a question of worth or not because I can't think of any other way to prevent the loss of error information. 😕

In theory, the slowness of clippy is unrelated to the performance of our lints. Note that clippy has hundreds of lints, while we only have one at present. Thus, the process only involves running cargo check and this single lint. If check can be cached, then it would be fast. I'll do further local testing.

If the running time is really a problem, I guess linting in main-cron or even manually is still good.

@BugenZhao
Copy link
Member Author

BugenZhao commented Dec 1, 2023

Whether or not we should integrate dylint to the development workflow is a topic in next PRs. In any case, checking in lints to our repository enable collaboration on improving the quality of RisingWave's codebase. I don't find any reason that I should keep this private on my own computer. 😄

Copy link
Member

@stdrc stdrc left a comment

Choose a reason for hiding this comment

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

The concept looks really good to me. Previously we have some times when we wanted to add some custom lint rules but gave up. Such a dylint integration will make future custom linting easy. Thx!


impl EarlyLintPass for FormatArgsCollector {
fn check_expr(&mut self, cx: &EarlyContext<'_>, expr: &Expr) {
if let ExprKind::FormatArgs(args) = &expr.kind {
Copy link
Member

Choose a reason for hiding this comment

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

Is format_args a special macro which the compiler is aware of?

Copy link
Member Author

Choose a reason for hiding this comment

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

I guess so, at the early pass.

Copy link
Contributor

@liurenjie1024 liurenjie1024 left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -0,0 +1,3 @@
[toolchain]
channel = "nightly-2023-10-21" # should be identical to the root one
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there anyway to sync this with root one automatically?

Copy link
Member Author

Choose a reason for hiding this comment

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

I haven't found one. But as mentioned by @xxchan at #13750 (comment), there's more stuff to do when bumping the toolchain. Maybe we need a dedicated script or instruction for this.

Signed-off-by: Bugen Zhao <i@bugenzhao.com>
@BugenZhao BugenZhao added this pull request to the merge queue Dec 1, 2023
Merged via the queue into main with commit 61d364c Dec 1, 2023
31 of 32 checks passed
@BugenZhao BugenZhao deleted the bz/dylint-checkin branch December 1, 2023 09:12
@xxchan
Copy link
Member

xxchan commented Dec 1, 2023 via email

@xxchan
Copy link
Member

xxchan commented Dec 1, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants