-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Update Documentation to Focus on LateLintPass
#9426
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
r? @llogiq (rust-highfive has picked a reviewer for you, use r? to override) |
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.
This looks like a good start! Let me know if you need anything.
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.
I like the general tone :)
I've added some comments which may be a bit nitpicky, feel free to ignore them in that case :)
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 lint pass chapter looks good to me and also correct. Still, it would be good if someone else could double-check the differentiation, as I helped with the content of these docs 🙃
Maybe @flip1995 🙃
Sorry about not commenting on this. It's on my radar, but I currently really struggle to find time for Clippy, besides the plumbing stuff for releases/syncs/... 😐 I hope that will get better soon, but with how $day_job is currently going, I can't promise anything. |
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.
This is just a partial review, but I like what I've read so far. Thank you for all the work, you've already put into this!
/// | ||
/// ### Example | ||
/// | ||
/// ```rust,ignore |
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.
Here and below, I would remove the ,ignore
as these should be tested as part of the CI in most cases :)
} | ||
``` | ||
|
||
Make sure you put some love into writing a good documentation so that |
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.
Here we could also add something about the special magic {{produces}}
. Our metadata collection actually supports the automated linting of blocks and adding the output to the website. This was added in #8947 . All that's required is to add {{produces}}
below a code block, and the rest is done by black magic. Sadly, we don't have any lints yet using this. (Only because nobody got to adding them 😅)
Besides this, another awesome chapter!
// Optionally, we can check the type of the self argument whenever necessary. | ||
// See "Type Checking" chapter of the Clippy book for more information. |
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.
It's good that you mentioned this, since this is an easy thing to overlook and already came up a few times in my reviews. But, I think this should be formulated stronger. It's almost never correct to only check for the name. For example, just because the method is called map
doesn't mean that it actually belongs to an Iterator
. It could be an option or a user-defined type and method. Maybe we can directly add the type check, even if that overloads the example a bit 🤔
in [PathSegment], which is a value of the `MethodCall` enum variant, | ||
contains a field `name` that is defined as a `Symbol`. | ||
|
||
## Checking if a type defines a specific method |
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.
You could also add a reference to the section about checking if a type implements a certain trait. I can imagine this part could also be confused with that.
Otherwise, this is solid and a fun read. I'm looking forward to merging this :)
dependencies. | ||
|
||
Using one of its `*_trait` method, we could obtain the [DefId] of any | ||
specific item, such as `clone`, `copy`, `drop`, `eq`, which are familiar |
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.
specific item, such as `clone`, `copy`, `drop`, `eq`, which are familiar | |
specific item, such as `Clone`, `Copy`, `Drop`, `Eq`, which are familiar |
|
||
Besides diagnostic items, we can also use [`lang_items`][lang_items]. | ||
Take a look at the documentation and we find that `LanguageItems` contains | ||
all defined or undefined language items both from the current crate or its |
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.
all defined or undefined language items
I believe this could be confusing and doesn't affect the lint implementation, IIRC. Therefore, I would leave this out :)
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 so so much for writing this and your patience on my review. I haven't done any detailed reading yet, but just looked at this from a high level perspective.
It will be nearly impossible for me to review this as a whole. Or rather: this will take months to get it merge ready (because of me). I would suggest to take one chapter out of this PR and put it in its own PR. In this PR we can refine this chapter, focus on it and then merge it.
I would suggest to start with define_lints
.
May general feedback: I like your writing style and the story telling you are doing in parts of the documentation. However, some parts of the documentation shouldn't contain any story telling, but just hard facts. The example, which goes through a whole lint implementation can contain story telling and should have a nice flow when reading. Technical chapters that explain how to do something should just contain hard facts though. Short concise documentation that you don't have to read in depth to understand what's going on.
You might have come across [Clippy lints list][lint_list] and | ||
read about a few lints that you want to use, restrict, or understand. | ||
|
||
These lints's documentation is generated by using the `declare_clippy_lint` | ||
macro and by writing the documentation inside: |
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.
I would write this something like
Clippy's lint documentation, that is available on the Clippy lints list
is generated from the `declare_clippy_lint` macro.
@@ -0,0 +1,46 @@ | |||
# Adding Documentation for New Lint |
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.
There shouldn't be any story telling in here. Just the code snippet how the declaration/documentation looks like and a short explanation for each section in the documentation.
impl EarlyLintPass for FooFunctions { | ||
fn check_fn(&mut self, cx: &EarlyContext<'_>, fn_kind: FnKind<'_>, span: Span, _: NodeId) { | ||
// Imagine a `is_foo_function` that checks for functions named `foo` | ||
if is_foo_function(fn_kind) { |
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.
I wouldn't put examples in here, but rather explain lint passes and how they work in general.
I think my issue with this file is, that it thows together lint emission and lint passes. I think both things deserve their own chapter
- Lint passes: What are those? How does rustc call them? How to implement them (high level)? Difference Early/Late? EDIT: Just saw that this chapter already exists. So I would focus here on the next point.
- Lint emission: How to emit a lint in Clippy? How to get code snippets? How to produce suggestions? Applicability? Difference between suggestion/help/note?
is aimed to do. | ||
|
||
Additionally, since restricting `pub use ...` is for very specific cases, | ||
we probably want to create a lint but put it into `clippy::restriction` |
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.
I wouldn't chose an restriction lint here. Those lints are for really special use cases only and people might not relate to it and won't see the motivation. There is probably a simple early lint that is warn-by-default?
Alas, `HirId`s are very useful to Clippy developers. Below are some | ||
examples for when we might need `HirId`s. | ||
|
||
## `find_parent_node` method |
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.
Wait, this chapter is not at all about hir_id
s but rather about util functions using hir_id
s. I'm really unsure if this chapter is necessary. We should have a list with abbreviations and terms, that lists the HirId
with a lint to the rustc
HIR identifier documentation. This should be enough.
A chapter with a list of useful functions might be good. But this can also be really bitrotty.
As a reminder, run the following command to generate boilerplates for lints | ||
using `LateLintPass`: | ||
|
||
```sh | ||
$ cargo dev new_lint --name=<your_new_lint> --pass=late --category=<your_category_choice> | ||
``` |
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.
This is weirdly placed. I would remove it.
@@ -0,0 +1,137 @@ | |||
# Lint passes |
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.
So this chapter already exists. I think there is a little documentation missing on what a lint pass is in general and how it works together with rustc.
Hey @flip1995 a small ping from triage. What is the status on this PR/the sub PRs? I still really like the changes and believe that they'll improve the docs and approachability for newcomers. My understanding was that you wanted to review the sub PRs. Is that correct? |
I don't think that this PR will ever get merged as-is. I'll review and merge the sub PRs and then we'll continue pulling the next things out of this PR. |
Sounds good :) I'll continue on this thread soon. Still getting used to my new job (also using 🦀) |
@nahuakang Any thoughts on continuing with the project, is this abandoned? It's a very cool project and very sad that it has been stale for 211 days. If you do not mind someone else taking the lead partitioning this and making the whole PR process for each file, let me know. |
@blyxyas Are you interested in taking the lead? Feel free to do so since I'll focus on some other stuff this year :) This branch contains everything I wrote. Feel free to cherry pick. |
@nahuakang Yeah, the Clippy documentation feels pretty outdated and definitely needs some updates, but I was worried that you wanted the PRs to your name for some reason. Thanks for giving the green light to continue the project! |
@blyxyas It's open source. No need for name attached to PRs haha 😄 |
@blyxyas You can use Damn, I really need to get to reviews... I try to sort things out over Easter. |
I'll push this over the finish line then. @nahuakang Do you want to still manage #9659, #9668 and #9740 or do I open new PRs of those chapters and you close those? |
@blyxyas They are closed now :) |
@blyxyas Please also split out smaller PRs, instead of trying to rebase this one. @nahuakang I'm really sorry I never got to review those... |
@flip1995 Would you like to review the new PRs about Book Chapter Updates Reborn or are you busy (or don't want to read)? In honor of the old PRs |
I would really like to review them. So please assign me to them. If I won't get to them within 2-3 weeks, I'll reassign them. |
Clippy Book Chapter Updates Reborn: Defining Lints Revival of #9659, I've made a few changes (mainly ones from reviews from #9426, like removing mid-section storytelling) and some re-writes. The goal of the project would be to slowly re-write the Clippy book (only chapters that need it) to more up-to-date style. ## Notes - Things like `git status` commands have changed, we need to make sure that they're correct. - As this is a team-wide effort, I would please ask anyone and everyone to read it and give your opinion. - To talk about the whole project, please use the tracking issue for the project #10597 (It also contains a timeline, discussions and more information) --- changelog: Add a new "Defining lints" chapter to the book r? `@flip1995`
Clippy Book Chapter Updates Reborn: Writing tests This PR adds a new chapter to the book: "Writing tests". The changes have been mainly done from reviews from #9426 and some minor re-writes. ## Notes - We still need to check that the `git status`es are correct, as `cargo dev new_lint` changed a lot since 2022. - Requires #10598: Link to "Emitting Lints" where I flagged with `FIXME:`. - To talk about the whole project, please use the tracking issue for the project #10597 (It also contains a timeline, discussions and more information) changelog: Add a new "Writing tests" chapter to the book r? `@flip1995`
I believe this PR has been split into sub PRs, which have been partially reviewed. I'll close this PR to clean up our backlog a bit. You're welcome to open a new PR or comment here to have this one reopened. Thank you for the time, you put into this update :D |
This PR fixes #9311 by flattening the chapter structure and enriching the Clippy book documentation on how to work on lints.
Below is the checklist for all the chapters that should be edited/written:
EarlyLintPass
&LateLintPass
LateLintPass
LateLintPass
LateLintPass
HirId
inLateLintPass
LateLintPass
EarlyLintPass
If you added a new lint, here's a checklist for things that will be
checked during review or continuous integration.
.stderr
file)cargo test
passes locallycargo dev update_lints
cargo dev fmt
changelog: Update Clippy book