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

Allow lints to declare that they're pure #59024

Open
Manishearth opened this issue Mar 8, 2019 · 7 comments
Open

Allow lints to declare that they're pure #59024

Manishearth opened this issue Mar 8, 2019 · 7 comments
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Manishearth
Copy link
Member

Clippy and rustc both have a bunch of allow by default lints. Due to the way lint passes work, these have to be run even if never enabled, since lint passes may store state between check_foo calls.

Most lints don't do this, most lints are zero-sized.

It would be nice to allow LintPasses to declare that they are "pure", and have rustc omit allowed pure passes from the list of lint passes until enabled. This has some performance benefits but would also allow for incremental linting if we ever want that.

cc @Zoxc @oli-obk

@Manishearth Manishearth added the A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. label Mar 8, 2019
@Zoxc
Copy link
Contributor

Zoxc commented Mar 8, 2019

#57293 effectively has this by declaring lints as suitable for incremental compilation. #58019 also makes these lints run in parallel on modules.

@Manishearth
Copy link
Member Author

Can that be made more first-class so that there doesn't have to be a single builtin lint pass that's known to work on a module?

Also avoid running ones which are disabled until they get enabled.

@Manishearth
Copy link
Member Author

Oh, that can be used at the per pass level. Hmm

Still feel like this should be an optional method on the LintPass trait itself

@Zoxc
Copy link
Contributor

Zoxc commented Mar 8, 2019

The single builtin lint pass is there for performance reasons to avoid the virtual dispatch for lints and it also allows LLVM to do inter-lint optimizations.

@Manishearth
Copy link
Member Author

Ah hmmm

@Enselic Enselic added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 16, 2023
@ultrabear
Copy link
Contributor

Has there been any activity on this? it came up as something wanted so that restrict::implicit_drop could be considered (which in turn is a lint that I and others would like to have)

Sending this since it seems the original conversation has died out with no concrete resolution 5 years ago

@Noratrieb
Copy link
Member

@blyxyas has been working on not running unnecessary lints. though i also question whether the lint would actually have such bad perf effects and it seems like it's at least worth a try if you care.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut. C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants