[Merged by Bors] - feat: the longFile linter#15610
Conversation
PR summary c01109e5bbImport 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 |
|
What I feel is really missing for this linter is a test. However, I do not know how to test it, since |
|
Two quick thoughts (I can review properly next week):
|
|
Michael, thank you for the review! I expanded the docs and comment to the text-based linters, mentioning the syntax one. I also added the $ printf '%s|%s\n' "$(
{ grep 'ERR_NUM_LIN' scripts/style-exceptions.txt
grep '^set_option linter.longFile [0-9]*' $(git ls-files '*.lean') ; } | wc -l
)" "large files"
66|large filesand it matches the number that the Zulip post has. |
grunweg
left a comment
There was a problem hiding this comment.
Thanks for rewriting this linter! I took the liberty to propose some wording changes directly - feel free to revert any you dislike. I have one minor comment - apart from that, this looks good to go.
|
(Long-term, it would be nicest to have this PR remove the text-based linter instead, and import this linter in Mathlib.Init instead. We'll see in which order things land.) |
Not recognising one is more confusing than any other behaviour. In practice, after #15610 none of these should be needed in practice.
|
bors merge |
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines (1500 by default). A value of `0` silences the linter entirely. This PR also modifies the `TextBased` `fileTooLong` linter: now it only lints files that do not contain `set_option linter.style.longFile `, and removes the exceptions that are now covered by the "longFile" linter. The `TextBased` longFile linter stays (for now), though it is going to be removed soon. Co-authored-by: Michael Rothgang <rothgami@math.hu-berlin.de>
|
Build failed (retrying...): |
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines (1500 by default). A value of `0` silences the linter entirely. This PR also modifies the `TextBased` `fileTooLong` linter: now it only lints files that do not contain `set_option linter.style.longFile `, and removes the exceptions that are now covered by the "longFile" linter. The `TextBased` longFile linter stays (for now), though it is going to be removed soon. Co-authored-by: Michael Rothgang <rothgami@math.hu-berlin.de>
|
Pull request successfully merged into master. Build succeeded: |
Not recognising one is more confusing than any other behaviour. In practice, after #15610 none of these should be needed in practice.
This file has been recording exceptions to the text-based style linters in `lint-style.py` and `Linter/TextBased`. The length of this file is meant to reach zero - and now, it indeed has. 🎉 Some of the linter errors were easy to fix (and just required sustained effort), such as some misformatted author lines or missing module documentation. The main remaining entries were exceptions for the "long file linter", which has been rewritten as a syntax linter (in #15610 and #16299). Exceptions are now tracked as `set_option linter.style.longFile <number>` instead, obviating the need for this file. This implies the need for a file with transient style exceptions is gone. All of the remaining text-based linters should not be introduced in new code. For *permanent* exceptions, the file `nolints-style.txt` continues to exist; that file must (intentionally) be updated by hand. [zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/RFC.3A.20remove.20.60scripts.2Fstyle-exceptions.2Etxt.60)
This file has been recording exceptions to the text-based style linters in `lint-style.py` and `Linter/TextBased`. The length of this file is meant to reach zero - and now, it indeed has. 🎉 Some of the linter errors were easy to fix (and just required sustained effort), such as some misformatted author lines or missing module documentation. The main remaining entries were exceptions for the "long file linter", which has been rewritten as a syntax linter (in #15610 and #16299). Exceptions are now tracked as `set_option linter.style.longFile <number>` instead, obviating the need for this file. This implies the need for a file with transient style exceptions is gone. All of the remaining text-based linters should not be introduced in new code. For *permanent* exceptions, the file `nolints-style.txt` continues to exist; that file must (intentionally) be updated by hand. [zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/RFC.3A.20remove.20.60scripts.2Fstyle-exceptions.2Etxt.60)
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines (1500 by default). A value of `0` silences the linter entirely. This PR also modifies the `TextBased` `fileTooLong` linter: now it only lints files that do not contain `set_option linter.style.longFile `, and removes the exceptions that are now covered by the "longFile" linter. The `TextBased` longFile linter stays (for now), though it is going to be removed soon. Co-authored-by: Michael Rothgang <rothgami@math.hu-berlin.de>
This file has been recording exceptions to the text-based style linters in `lint-style.py` and `Linter/TextBased`. The length of this file is meant to reach zero - and now, it indeed has. 🎉 Some of the linter errors were easy to fix (and just required sustained effort), such as some misformatted author lines or missing module documentation. The main remaining entries were exceptions for the "long file linter", which has been rewritten as a syntax linter (in #15610 and #16299). Exceptions are now tracked as `set_option linter.style.longFile <number>` instead, obviating the need for this file. This implies the need for a file with transient style exceptions is gone. All of the remaining text-based linters should not be introduced in new code. For *permanent* exceptions, the file `nolints-style.txt` continues to exist; that file must (intentionally) be updated by hand. [zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/RFC.3A.20remove.20.60scripts.2Fstyle-exceptions.2Etxt.60)
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines (1500 by default). A value of `0` silences the linter entirely. This PR also modifies the `TextBased` `fileTooLong` linter: now it only lints files that do not contain `set_option linter.style.longFile `, and removes the exceptions that are now covered by the "longFile" linter. The `TextBased` longFile linter stays (for now), though it is going to be removed soon. Co-authored-by: Michael Rothgang <rothgami@math.hu-berlin.de>
This file has been recording exceptions to the text-based style linters in `lint-style.py` and `Linter/TextBased`. The length of this file is meant to reach zero - and now, it indeed has. 🎉 Some of the linter errors were easy to fix (and just required sustained effort), such as some misformatted author lines or missing module documentation. The main remaining entries were exceptions for the "long file linter", which has been rewritten as a syntax linter (in #15610 and #16299). Exceptions are now tracked as `set_option linter.style.longFile <number>` instead, obviating the need for this file. This implies the need for a file with transient style exceptions is gone. All of the remaining text-based linters should not be introduced in new code. For *permanent* exceptions, the file `nolints-style.txt` continues to exist; that file must (intentionally) be updated by hand. [zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/RFC.3A.20remove.20.60scripts.2Fstyle-exceptions.2Etxt.60)
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines (1500 by default). A value of `0` silences the linter entirely. This PR also modifies the `TextBased` `fileTooLong` linter: now it only lints files that do not contain `set_option linter.style.longFile `, and removes the exceptions that are now covered by the "longFile" linter. The `TextBased` longFile linter stays (for now), though it is going to be removed soon. Co-authored-by: Michael Rothgang <rothgami@math.hu-berlin.de>
This file has been recording exceptions to the text-based style linters in `lint-style.py` and `Linter/TextBased`. The length of this file is meant to reach zero - and now, it indeed has. 🎉 Some of the linter errors were easy to fix (and just required sustained effort), such as some misformatted author lines or missing module documentation. The main remaining entries were exceptions for the "long file linter", which has been rewritten as a syntax linter (in #15610 and #16299). Exceptions are now tracked as `set_option linter.style.longFile <number>` instead, obviating the need for this file. This implies the need for a file with transient style exceptions is gone. All of the remaining text-based linters should not be introduced in new code. For *permanent* exceptions, the file `nolints-style.txt` continues to exist; that file must (intentionally) be updated by hand. [zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/RFC.3A.20remove.20.60scripts.2Fstyle-exceptions.2Etxt.60)
The "longFile" linter is a syntax linter. It emits a warning on files which are longer than a certain number of lines
(1500 by default). A value of
0silences the linter entirely.This PR also modifies the
TextBasedfileTooLonglinter: now it only lints files that do not containset_option linter.style.longFile, and removes the exceptions that are now covered by the "longFile" linter.The
TextBasedlongFile linter stays (for now), though it is going to be removed soon.Once #15845 lands, the text-based linter can be removed.
I tried setting the default option for the linter to 0 and then modifying it in the lakefile to be 1500 for Mathlib, but I could not get it to work.