Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 indent will still be removed with this change.
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 removes the single space
///[here]text
, strip_prefix does not remove multiple elementsThere 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.
Arf indeed, thought it was stripping as long as it found the character. But then it creates an unbalance in case you have no whitespace character at the beginning of all lines (for whatever reason) and you then have a block.
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.
Yeah though this is exactly how the procedural macro did it as well. I think this (there being no space) is a non-issue overall but if this was already fixed in your PR I think that's a better way of doing it, afaik both rustfmt and clippy never catch this likely typo.
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.
Which procedural macro?
Also, I think it's about handling the fact that most of the time, you write code after a whitespace (
/// bla
instead of///bla
). It's handled in rustdoc by finding out what's the minimum indent and then stripping according to that. Hum, might be worth to do that actually. Gonna update my PR.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.
In the prior PR,
declare_clippy_lint
was turned from a procedural macro into a declarative macro. It had the same logic before as this PR hasThere 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 this solution better, as when copying the code block from the Clippy documentation, you don't have the leading
in every line.
I don't think the non-leading whitespace in documentation is a concern, as ... we should just not do this in our documentation 😅
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.
Ah - didn't realize it'd leave a leading space. The issue was about it being unintentional, and hard to spot, rather than a style 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.
I don't think this is worth the effort/code. This is just to generate the Clippy documentation from the lint documentation in the Clippy code base. This code doesn't have to handle all possible doc writing styles people come up with, like
rustdoc
does.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.
Yeah we can't reuse the
fn
s rustdoc uses here unlike for our lints since we only get them as strings, but I think it's fine to assume our docs are reasonably formatted