-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Feature request: custom library-specific lints #6872
Comments
I had a discussion with the maintainer of shipyard, who asked if we could somehow change the If it helps you to get up to speed, you might want to start lints in our nursery and later move them to another project if you deem that the best course of action. Also perhaps some of the lints you want may be generalizable. What is it that you want to have linted? |
From bevyengine/bevy#1602:
These are highly specific lints to bevy for which generalization doesn't make any sense. |
|
Bevy uses it's own ECS. Systems are ordinary functions on which |
A second use case that I just asked about on |
I've been pointed to this issue, asking about a replacement for now deprecated functionality that seems like it would have met our goals: Alternatives to rustc_plugin::registry for (Servo’s) custom lints?. |
I have a list of Rust features that I usually consider inappropriate to use in my projects due to compile time/correctness/usability hazards, but probably would be viewed as overly conservative by most clippy users. I would love to be able to ban various things using a custom lint such as:
I've recently come across the Ravenscar ADA Profile which grants significant safety properties to concurrent hard real-time systems, and I've really been jealous about how that community is able to opt into a restricted feature set to significantly reduce the cost of building safer systems. |
Most of those seem easy to implement and all of the fit nicely into our restriction lint category. The "threads spawned dynamically" lint would be quite hard, because we only perform local analysis and threads could be spawned in functions from other crates. However, we could still lint calls to |
I'd love to be able to create some lints for non-ideal usages of SNAFU!
It certainly seems odd to have those be a part of Clippy proper — will people really be happy with increased Clippy build times / size / code complexity for a crate they might never use? I also wonder about how versioning would work: if I guess I was thinking of some wild process where Clippy
|
I recently posted a proposal for proc-macro based lints: https://internals.rust-lang.org/t/proposal-stabilizable-proc-macro-based-lints/15022/19 |
@shepmaster is already aware of this, but I plan on writing up some of my thoughts for a plugin-based lint system. I'll probably start doing this Tuesday evening and hope to have something to post on Wednesday on IRLO. It'll be a lot of work but long-term I think it will be worth it. @flip1995 has also expressed interest in helping out in this manner. |
Definitely a non-trivial issue, but also something which seems like it would be extremely valuable to libraries for exactly these situations: per the rustfix readme,
I interpret this as meaning that clippy support would be necessary for libraries to be able to use rustfix for their API changes. Such a thing would make iterating on 0.x a lot easier, especially if a library gains significantly in popularity before it reaches 1.0: while 0.x is for development, having tons of users makes BC breaks more wasteful even while you're supposedly allowed to. |
Hey everyone, in response to this, a new project was set up to implement a general stable linting interface for Rust. As part of the designing process, I would like to collect some user stories. If you have the time, it would be appreciated if you could create an issue detailing your custom lint idea: https://github.com/rust-linting/design/issues/new?assignees=&labels=A-user-story&template=user-story.md This can be in the form of a short and simple list (like this), or a detailed lint with example code (like this). With these user stories, I'm especially interested in the role of macros when it comes to linting. Any feedback is highly appreciated :) |
Over at Bevy we've been discussing building a linter for Bevy code bases, to catch common errors and style issues.
We'd love to be able to integrate with Clippy in some way, but obviously, almost all of these will be completely useless to Rustaceans who aren't using Bevy. Furthermore, we'd want to maintain our own lints, without bogging down the rust-clippy team directly.
What would be the best way to go about this?
The text was updated successfully, but these errors were encountered: