r? @dswij

(rust-highfive has picked a reviewer for you, use r? to override)

I started out trying to get a proc macro to work, but then I found Alexey Kladow's blog post about self-modifying code and I thought this might be just the right application for the technique.

This one looks interesting, and my reviewing queue is currently relatively small. I would take over the review. (If you want to keep it @dswij, feel free to say so)

r? @xFrednet

@llogiq could you maybe link the blog post? Your comment reminded me of a post, I've read before. Also, as a side node, I sometimes find it confusing, when to use the double dashes after cargo clippy and when not. Therefore, I think it would be cool, if the --explain comment would also be accepted by cargo-clippy and then passed to clippy-driver. But that can also be done in a followup PR

Updated my previus comment with the link.

Sure, go ahead!

@xFrednet I'm fine with merging this & doing a follow-up for cargo-clippy later.

I noted that -E is already used for "error".

Couldn't docs.rs be generated during the metadata collection lint alongside lints.json? Just so you don't have to reinvent the wheel to get the docs.

Couldn't docs.rs be generated during the metadata collection lint alongside lints.json?

collect-metadata is only run during deployment and not even in bors CI. However, collect-metadata could use this file to generate the documentation instead of doing it itself.

This would be a really cool thing to have -- especially if we can somehow add this feature to rust-analyzer. Thank you for your work!

So, I see two ways to improve on this:

• I'll move the docs creation to cargo-dev so it's included with update_lints and re-use our current infrastructure.
• I'll change the generation to emit a file per lint and a single file to include_str! all of those doc files. This way we won't get too many merge conflicts from docs.

This version should deal with the merge conflicts arising from doc changes.

I didn't get to changing the code to use cargo dev update_lints yet. Using the metadata collector would not be optimal, because we don't run it in CI. On the other hand, extending update_lints to also parse the doc comments would duplicate some machinery. Oh well.

Hmmm...I should not name the files ".md" when they don't contain markdown...

With the following force-push, I removed the final newline from the md files as well as # -ignored code lines.

@dswij r?

Sorry, for the late replay, I moved last week and life is currently still a bit chaotic. Reviewing this is on my todo list for this weekend. If @dswij want's to take over that would also be fine for me

Hey @rust-lang/clippy, this PR adds the --explain comment to cargo-clippy. For this, it stores the lint description in a text file inside src/docs/<lint_name>.txt. The documentation files are automatically checked and updated by cargo dev update_lints. This seems to work quite well and looks good to me. Does anyone have any concerns regarding this?

I need to rebase to make the tests work.

We discussed wanting this three meetings ago, and I agreed to implement it. I don't think there were any objections during that meeting.

Re the implementation: Splitting the files and using include_str! to pull them together was done to reduce merge conflicts. Merging this will fail unless it's rebased on a sufficiently late version (i.e. no docs changes in between), so please ping me before r+ing it.

We discussed wanting this three meetings ago, and I agreed to implement it. I don't think there were any objections during that meeting.

I just wanted to make sure now that we had an actual implementation to play around with. It looks like everyone is cool with this :)

This looks good to me, you can r=me after a rebase and lint update Thank you for the implementation, happy to finally have this in Clippy

@bors r=xFredNet

Commit ad72aee has been approved by xFredNet

It is now in the queue for this repository.

Testing commit ad72aee with merge 30e4532...

Thank you for the review, @xFrednet.