Zulip Chat Archive
Stream: mathlib4
Topic: Weekly linting log
github mathlib4 bot (Oct 13 2025 at 05:57):
Mathlib's nightly-testing branch (a778305ec3a679802f7dcfa64e2b903d4679ee21) regression run completed.
Warnings: 6
Warning counts
Kevin Buzzard (Oct 13 2025 at 06:00):
What's the first warning?
Edward van de Meent (Oct 13 2025 at 16:38):
the warnings are:
'have ha₂ : ∀ x ∈ spectrum ℝ a, x ≠ 0 :=
by
rw [StarOrderedRing.isStrictlyPositive_iff_spectrum_pos (R := ℝ) a] at ha
grind; grind' can be replaced with 'grind'
and
'have ha₂ : ∀ x ∈ spectrum ℝ a, x ≠ 0 :=
by
rw [StarOrderedRing.isStrictlyPositive_iff_spectrum_pos (R := ℝ) a] at ha
grind; grind' can be replaced with 'grind'
Edward van de Meent (Oct 13 2025 at 16:39):
(dug through the logs)
Alex Meiburg (Oct 13 2025 at 16:40):
At https://github.com/leanprover-community/mathlib4-nightly-testing/blob/e7c30293bf22c84e003230699e8da7bd46c010ef/Mathlib/Analysis/SpecialFunctions/ContinuousFunctionalCalculus/ExpLog.lean#L158, lines 142 and 158, the have := ... grind can be replaces with just a grind [log_smul] and grind [log_pow], it seems
Chris Henson (Oct 13 2025 at 16:55):
How is this linter intended to interact with <;>? Currently if you have a proof that does ... <;> have := ...; grind, each branch will lint individually. Is this intended? (I think it is fine to do this, just curious.)
Kim Morrison (Oct 14 2025 at 04:47):
Chris Henson said:
How is this linter intended to interact with
<;>? Currently if you have a proof that does... <;> have := ...; grind, each branch will lint individually. Is this intended? (I think it is fine to do this, just curious.)
This is relevant for the
'simp only [Set.mem_toFinset]; grind' can be replaced with 'grind'
table row above.
Kim Morrison (Oct 14 2025 at 04:50):
Besides this one, the others are cleaned up in #30528.
github mathlib4 bot (Oct 20 2025 at 05:40):
Mathlib's nightly-testing branch (9e574589c15b3b233d3223f1b35871a798cc2748) regression run completed.
Warnings: 2
Warning counts
github mathlib4 bot (Oct 27 2025 at 05:44):
Mathlib's nightly-testing branch (88d330e19d35d91b0e5b0f6415a6939d00648f20) regression run completed.
Warnings: 4
Warning counts
Kim Morrison (Oct 28 2025 at 05:08):
2nd and 4th done in #30992. The 3rd one is incorrect. The 1st was discussed above: it only applies in one branch of a <;>.
Anne Baanen (Oct 28 2025 at 10:10):
I wanted to extend #29964 (don't warn if a tactic under a try combinator fails) to fix the 1st one, but it is more subtle than that. We'd have to correlate the TacticInfo across <;> branches, which I don't immediately see how to do...
Anne Baanen (Oct 28 2025 at 10:12):
My suspicion is that the 3rd one has to do with an instance cache not being reset somewhere, but I don't have time to investigate this in detail.
Damiano Testa (Oct 28 2025 at 12:20):
I think that the unreachable tactic stores the ranges of the tactics and then removes the ranges whenever something is used. This means that if a tactic is "shared", it counts as used if it is used at least once.
Maybe this machinery could do something similar? I have not actually inspected carefully how it works, though, so maybe this is already happening/unhelpful.
Kim Morrison (Oct 29 2025 at 02:55):
It's one spurious report in a not-that-important linter, let's not sink time into this.
A much cheaper solution would be to remove the <;> and write out both branches!
Chris Henson (Oct 29 2025 at 04:03):
Kim Morrison said:
A much cheaper solution would be to remove the
<;>and write out both branches!
FWIW I enabled the mergeWithGrind linter for CSlib, taking this approach for <;> false positives. Same as here, I think it was one proof to change, but I actually appreciated it identifying a proof where only one branch needed extra theorems passed to grind. Arguably writing out the branches in extreme cases of this is better for readability (and potentially performance I'd guess).
Kim Morrison (Oct 29 2025 at 11:06):
Yeah, <;> where quite different things happen, that happen to be compressible into a single tactic call, has always seemed to me like the obfuscatory side of golfing.
github mathlib4 bot (Nov 10 2025 at 05:44):
Mathlib's nightly-testing branch (d6b7d986955032cac54ae3d348326c295d51adfd) regression run completed.
Warnings: 24
Warning counts
Kim Morrison (Nov 13 2025 at 06:29):
Mostly dealt with in #31578.
github mathlib4 bot (Nov 17 2025 at 05:46):
Mathlib's nightly-testing branch (6a739275610fda3b4c420565ec194b100d14b81b) regression run completed.
Warnings: 7
Warning counts
github mathlib4 bot (Nov 24 2025 at 05:45):
Mathlib's nightly-testing branch (5e87abc94ce4317581dbb90a82be193457516dbe) regression run completed.
Warnings: 10
Warning counts
github mathlib4 bot (Dec 01 2025 at 05:50):
Mathlib's nightly-testing branch (dc19f2a67ff55a2078ba23a4c1740a5eb0d50e41) regression run completed.
Warnings: 21
Warning counts
github mathlib4 bot (Dec 08 2025 at 05:44):
Mathlib's nightly-testing branch (b7d2fa97710d4c43ddee0c0dfb1b4595bbc767e5) regression run completed.
Warnings: 20
Warning counts
Kim Morrison (Dec 11 2025 at 03:35):
Mostly dealt with in #32713
github mathlib4 bot (Dec 15 2025 at 05:52):
Mathlib's nightly-testing branch (3ea6690c3470d61c7d4fd71e7efd6336a6d05ffd) regression run completed.
Warnings: 13
Warning counts
Kim Morrison (Dec 15 2025 at 09:37):
Mostly dealt with in #32893.
Chris Henson (Dec 15 2025 at 09:44):
Probably too messy to be worth detecting automatically, but do you know if any of these are the same proof requiring changes over time? When we were running this linter for every day in CSLib's nightly testing I recall seeing a bit of this.
Kim Morrison (Dec 15 2025 at 09:50):
I'm sorry, I don't understand what you mean by "the same proof requiring changes over time".
Chris Henson (Dec 15 2025 at 09:54):
I've had the experience that between different nightlies/releases this linter will suggest removing a line that later needs to be added back.
Kim Morrison (Dec 15 2025 at 10:03):
Interesting. I haven't seen that; if you see it again please let me know!
Violeta Hernández (Dec 15 2025 at 11:19):
How do you run this linter on another repository?
Chris Henson (Dec 15 2025 at 11:37):
The linter set is linter.weeklyLintSet, which currently just has linter.tacticAnalysis.mergeWithGrind. As I learned by experience, you don't want to set this by default for performance reasons, as it does make grind run in duplicate. For CSLib we set up something similar to Mathlib's .github/workflows/weekly-lints.yml which once a week adds the option to the lakefile and then builds.
Last updated: Dec 20 2025 at 21:32 UTC