Fix indentation of website code snippets #13571
Conversation
rustbot
added
the
S-waiting-on-review
| @@ -102,7 +102,9 @@ pub fn sanitize_explanation(raw_docs: &str) -> String { | |||
| // Remove tags and hidden code: | |||
| let mut explanation = String::with_capacity(128); | |||
| let mut in_code = false; | |||
| for line in raw_docs.lines().map(str::trim) { | |||
| for line in raw_docs.lines() { | |||
| let line = line.strip_prefix(' ').unwrap_or(line); | |||
There was a problem hiding this comment.
The indent will still be removed with this change.
There was a problem hiding this comment.
It removes the single space ///[here]text, strip_prefix does not remove multiple elements
There was a problem hiding this comment.
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.
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.
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.
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 has
There was a problem hiding this comment.
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.
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.
Hum, might be worth to do that actually. Gonna update my PR.
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.
Yeah we can't reuse the fns 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
|
Funnily enough, we worked on the same problem. I opened #13596 to fix it. However, I think this PR is not fixing since it still trims the indent if there is some. EDIT: As discussed above, this solution seems to be the best out of the two. |
|
Would approve a way to either catch/fix wrongly formatted lints. It's a reasonable thing to ignore though. @bors r+ |
|
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
Fixes #13568
Follow up to #13359, I didn't catch that it swapped the
strip_prefixout for atrimbut they aren't interchangeable herechangelog: none