Skip to content

Prepare to split clippy_lints #14684

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Jarcho
Copy link
Contributor

@Jarcho Jarcho commented Apr 24, 2025

Based on #14633

The end goal here is to split clippy_lints into several independent crates and have the driver call out to each of them to register lints. clippy_lints takes way too long to compile right now.

r? @flip1995

changelog: none

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Apr 24, 2025
@flip1995
Copy link
Member

Thanks for assigning me to those PRs and requesting my review! However, I can't keep up with my reviews. I suggest Alex as the main reviewer, maybe with the help of Samuel.

I fully trust you that you'll improve our tooling here!

If you really want my review, just keep me assigned and I'll see what I can do this weekend. Otherwise, feel free to re-assign those PRs to Alex and/or Samuel.

(applies to all clippy_dev PRs currently open, just commenting once here)

@Jarcho
Copy link
Contributor Author

Jarcho commented Apr 24, 2025

I only assigned you to this one since splitting will (maybe) affect the sync in an annoying way.

edit: Just rerolled the others.

@Jarcho Jarcho added the S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work label Apr 24, 2025
Copy link
Member

@flip1995 flip1995 left a comment

Choose a reason for hiding this comment

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

Thanks for clarifying! Please also ping me on the PR that does the actual split.

This LGTM. AFAICT, CI failures are due to a different PR.

Just a NIT. Feel free to merge, once the others of the stack got merged :shipit:

}
}

fn crate_root_path(self) -> &'static str {
Copy link
Member

Choose a reason for hiding this comment

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

NIT: Maybe a better name crate_lib_path or even more explicit crate_lib_rs_path.

No strong opinion here though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'll leave this for when I end up having to rebase. Hopefully I don't forget.

@rustbot

This comment has been minimized.

@Jarcho Jarcho force-pushed the split_lint_crate branch from d74d920 to dded6ed Compare May 19, 2025 09:56
@samueltardieu
Copy link
Contributor

When should this PR be merged?

  • Wrt the PRs waiting to be merged into Clippy, those will virtually all be invalidated. That will happen anyway, so we can't do much about it, so any time would do.
  • Wrt the compiler repo, I think it would be best if this PR was merged soon after a successful sync (for example now), and followed again by a sync in order to minimize the time frame where changes could be made to the original src/tools/clippy while the Clippy directory has switched to the new organization.

@Jarcho
Copy link
Contributor Author

Jarcho commented May 19, 2025

Ignore the current state of this. I'm just transferring it to my main computer.

I'll probably split this into a PR the does all the prep work before splitting and separate ones for each module being split. For the most part the conflicts shouldn't be too bad since git will see basically everything as a rename. Doing this with a sync is probably the best anyways just in case. I'll let @flip1995 make that call since he's the one who has to deal with it.

@Jarcho Jarcho force-pushed the split_lint_crate branch from dded6ed to 3948a62 Compare May 23, 2025 11:03
@Jarcho Jarcho removed the S-blocked Status: marked as blocked ❌ on something else such as an RFC or other implementation work label May 23, 2025
@Jarcho Jarcho force-pushed the split_lint_crate branch from 3948a62 to 37d5463 Compare May 23, 2025 11:58
* Move `declare_clippy_lint` to it's own crate
* Move lint/group registration into the driver
* Make `dev update_lints` handle multiple lint crates
@Jarcho Jarcho force-pushed the split_lint_crate branch from 37d5463 to 6376620 Compare May 23, 2025 12:01
@Jarcho
Copy link
Contributor Author

Jarcho commented May 23, 2025

This should be ready now. List of changes:

  • declare_clippy_lint is now it's own crate (I feel like this has gone back and forth a few times). Basically all the changed files are just to import it.
  • The driver now does the lint and group registration. Lint pass registration is still done by the lints crate.
  • update_lints will now handle multiple lint crates.

@Jarcho
Copy link
Contributor Author

Jarcho commented May 23, 2025

r? @Alexendoo

@rustbot rustbot assigned Alexendoo and unassigned flip1995 May 23, 2025
Comment on lines +1 to +3
[package]
name = "declare_clippy_lint"
version = "0.1.89"
Copy link
Member

Choose a reason for hiding this comment

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

Should be added to tests/versioncheck.rs

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Probably should. I don't think I added it to clippy_dev either.

@@ -1,6 +1,7 @@
use clippy_config::Conf;
use clippy_utils::diagnostics::span_lint;
use clippy_utils::is_from_proc_macro;
use declare_clippy_lint::declare_clippy_lint;
Copy link
Member

Choose a reason for hiding this comment

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

We could #[macro_use] the crate to not require lint modules to change, up to you

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I totally forgot that's an option. I personally prefer not having things magically added to a scope, but this is a case where it's not unreasonable.

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.

5 participants