[Merged by Bors] - feat: the doc-string linter#22095
[Merged by Bors] - feat: the doc-string linter#22095
Conversation
PR summary 5b889058dfImport changes exceeding 2%
Import changes for modified filesNo significant changes to the import graph Import changes for all files
Declarations diff
You can run this locally as follows## summary with just the declaration names:
./scripts/declarations_diff.sh <optional_commit>
## more verbose report:
./scripts/declarations_diff.sh long <optional_commit>The doc-module for Increase in tech debt: (relative, absolute) = (2.00, 0.02)
Current commit 5b889058df You can run this locally as
|
|
If we do a better job at tracking where the exceptions are, the warning can be logged "at" the right positions in the string and highlight what they refer to. |
|
You can take a look at for a start at getting the warning where the issue is. The |
| if lines.any (·.startsWith " ") | ||
| -- For now, we skip cases where a line starts with "* " or "- " as these are probably markdown | ||
| -- code blocks. (We can later try to re-enable some linting there.) | ||
| && !lines.any (fun l ↦ l.startsWith "* " || l.startsWith "- ") then |
There was a problem hiding this comment.
How about including also ``` as an allowed start for exceptions?
Overall, I am still not sold on this check, as I find that it would require a more thorough parsing of markdown to really be effective.
grunweg
left a comment
There was a problem hiding this comment.
I just took a look: I think the implementation looks good, just minor comments.
I don't think the empty doc-strings need to block this from landing (as they are pre-existing). One could add an "empty doc-string linter" which complains about these specifically (the current error is not great), and also searches for e.g. doc-strings which are just TODO or TODO!. That can happen in a follow-up, though.
|
(Let me add: I think this is basically ready to be maintainer merged, with the question of these doc-strings being the biggest open item.) |
Co-authored-by: grunweg <[email protected]>
…unity/mathlib4 into adomani/docstring_linter
adomani
left a comment
There was a problem hiding this comment.
Michael, thank you so much for the review!
|
With respect to "empty" docstrings, I think that we can test whether a trimmed docstring contains no space and emit a warning then, with a more meaningful comment, such as "A doc-string that has at most one word is probably not a good docstring!" or something like this. I would leave this for later, though. |
grunweg
left a comment
There was a problem hiding this comment.
Thanks; I like your changes. Just two more nits.
Note to maintainers: this PR adds three manual linter exceptions, to declarations with an essentially empty doc-string. These were pre-existing; I don't think this PR should be blocked on that.
maintainer delegate
|
🚀 Pull request has been placed on the maintainer queue by grunweg. |
|
bors d+ |
|
✌️ adomani can now approve this pull request. To approve and merge a pull request, simply reply with |
|
bors merge |
The `docString` linter checks that doc-strings begin with * `/-- <Text>` or * `/--⏎<Text>` and that `<Text>` does not begin with a space or a line break. Similarly for the characters preceding `-/` at the end of a doc-string. Discussed in [Zulip](https://leanprover.zulipchat.com/#narrow/channel/287929-mathlib4/topic/Style.20.3Abicycle.3A.20.3A.20indenting.20second.20lines.20in.20doc-strings)
|
Pull request successfully merged into master. Build succeeded: |
The
docStringlinter checks that doc-strings begin with/-- <Text>or/--⏎<Text>and that
<Text>does not begin with a space or a line break. Similarly for the characters preceding-/at the end of a doc-string.Discussed in Zulip