[Merged by Bors] - feat: port Data.List.Lex#672
Conversation
mcdoll
left a comment
There was a problem hiding this comment.
I have the feeling that the naming of instances will be all over the place, but don't see that we have very good rules for that at the moment.
| ["docBlame", "List.Lex.isOrderConnected.aux"], | ||
| ["docBlame", "List.Lex.isTrichotomous.aux"], | ||
| ["docBlame", "List.Lex.isAsymm.aux"], |
There was a problem hiding this comment.
Maybe instead of using nolints, just add a one-line docstring saying that it is a helper definition for the respective instance? Or do these not show up in the docs at all?
There was a problem hiding this comment.
You can't add the doc strings at all. Mario fixed this in Lean core, but it hasn't trickled down yet. These will be removed from this file after the fact.
There was a problem hiding this comment.
More the point. These aren't actually defs, they're lemmas but the linter gets confused because of the let rec.
scripts/nolints.json
Outdated
| ["defLemma", "List.Lex.isTrichotomous.aux"], | ||
| ["defLemma", "List.Lex.isAsymm.aux"], | ||
| ["docBlame", "AddGroupWithOne"], |
There was a problem hiding this comment.
It would be better if these were explicit @[nolint] attributes (with a link to the lean4 PR that will make them obsolete.
@[nolint] is for cases where there is a reason to ignore the linter. scripts/nolints.json is for embarrassing historical accidents.
|
bors merge |
mathlib3 SHA: 39af7d3bf61a98e928812dbc3e16f4ea8b795ca3 Porting notes: 1. There was a mathport "failed to parenthesize" error, but it was easily worked around, see the first commit for details. 2. I had to use `aux` declarations when constructing things recursively inside the field of a structure. I asked about this on [Zulip](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/recursive.20definitions.20in.20instance.20fields) and also [here](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/recursive.20definition.20in.20structure.20fields), but so far there doesn't seem to be a better way. In any case, it compiles so it should be fine. Otherwise, this port was very smooth. 3. Because of the `aux where` (which is really `let rec aux`) this caused the `defLemma` linter to fire, which is being handled in [lean4#1866](leanprover/lean4#1866), so for now we just add these declarations to `nolints.json`; see [Zulip](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/recursive.20definitions.20in.20instance.20fields) Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
|
Pull request successfully merged into master. Build succeeded: |
Regenerated from the [port status wiki page](https://github.com/leanprover-community/mathlib/wiki/mathlib4-port-status). Relates to the following PRs: * leanprover-community/mathlib4#643 * leanprover-community/mathlib4#646 * leanprover-community/mathlib4#648 * leanprover-community/mathlib4#649 * leanprover-community/mathlib4#651 * leanprover-community/mathlib4#655 * leanprover-community/mathlib4#656 * leanprover-community/mathlib4#657 * leanprover-community/mathlib4#661 * leanprover-community/mathlib4#670 * leanprover-community/mathlib4#671 * leanprover-community/mathlib4#672 * leanprover-community/mathlib4#686
Regenerated from the [port status wiki page](https://github.com/leanprover-community/mathlib/wiki/mathlib4-port-status). Relates to the following PRs: * `algebra.char_zero.defs`: leanprover-community/mathlib4#661 * `algebra.group.order_synonym`: leanprover-community/mathlib4#651 * `algebra.hierarchy_design`: leanprover-community/mathlib4#657 * `algebra.quotient`: leanprover-community/mathlib4#643 * `algebra.ring.defs`: leanprover-community/mathlib4#655 * `algebra.ring.order_synonym`: leanprover-community/mathlib4#671 * `control.equiv_functor`: leanprover-community/mathlib4#649 * `data.dlist.basic`: leanprover-community/mathlib4#616 * `data.int.cast.basic`: leanprover-community/mathlib4#670 * `data.lazy_list`: leanprover-community/mathlib4#686 * `data.list.lex`: leanprover-community/mathlib4#672 * `data.option.n_ary`: leanprover-community/mathlib4#656 * `data.sigma.lex`: leanprover-community/mathlib4#646 * `group_theory.eckmann_hilton`: leanprover-community/mathlib4#626 * `logic.equiv.basic`: leanprover-community/mathlib4#631 * `order.iterate`: leanprover-community/mathlib4#648
Regenerated from the [port status wiki page](https://github.com/leanprover-community/mathlib/wiki/mathlib4-port-status). Relates to the following PRs: * `algebra.char_zero.defs`: leanprover-community/mathlib4#661 * `algebra.group.inj_surj`: leanprover-community/mathlib4#707 * `algebra.group.order_synonym`: leanprover-community/mathlib4#651 * `algebra.group.units`: leanprover-community/mathlib4#549 * `algebra.hierarchy_design`: leanprover-community/mathlib4#657 * `algebra.quotient`: leanprover-community/mathlib4#643 * `algebra.ring.defs`: leanprover-community/mathlib4#655 * `algebra.ring.order_synonym`: leanprover-community/mathlib4#671 * `control.equiv_functor`: leanprover-community/mathlib4#649 * `data.dlist.basic`: leanprover-community/mathlib4#616 * `data.int.cast.basic`: leanprover-community/mathlib4#670 * `data.lazy_list`: leanprover-community/mathlib4#686 * `data.list.lex`: leanprover-community/mathlib4#672 * `data.option.n_ary`: leanprover-community/mathlib4#656 * `data.sigma.lex`: leanprover-community/mathlib4#646 * `data.ulift`: leanprover-community/mathlib4#703 * `group_theory.eckmann_hilton`: leanprover-community/mathlib4#626 * `logic.equiv.basic`: leanprover-community/mathlib4#631 * `order.iterate`: leanprover-community/mathlib4#648
Regenerated from the [port status wiki page](https://github.com/leanprover-community/mathlib/wiki/mathlib4-port-status). Relates to the following PRs: * `algebra.char_zero.defs`: leanprover-community/mathlib4#661 * `algebra.group.inj_surj`: leanprover-community/mathlib4#707 * `algebra.group.order_synonym`: leanprover-community/mathlib4#651 * `algebra.group.units`: leanprover-community/mathlib4#549 * `algebra.hierarchy_design`: leanprover-community/mathlib4#657 * `algebra.opposites`: leanprover-community/mathlib4#644 * `algebra.quotient`: leanprover-community/mathlib4#643 * `algebra.ring.defs`: leanprover-community/mathlib4#655 * `algebra.ring.order_synonym`: leanprover-community/mathlib4#671 * `control.equiv_functor`: leanprover-community/mathlib4#649 * `data.dlist.basic`: leanprover-community/mathlib4#616 * `data.int.cast.basic`: leanprover-community/mathlib4#670 * `data.lazy_list`: leanprover-community/mathlib4#686 * `data.list.lex`: leanprover-community/mathlib4#672 * `data.option.n_ary`: leanprover-community/mathlib4#656 * `data.sigma.lex`: leanprover-community/mathlib4#646 * `data.ulift`: leanprover-community/mathlib4#703 * `group_theory.eckmann_hilton`: leanprover-community/mathlib4#626 * `logic.equiv.basic`: leanprover-community/mathlib4#631 * `order.iterate`: leanprover-community/mathlib4#648
mathlib3 SHA: 39af7d3bf61a98e928812dbc3e16f4ea8b795ca3
Porting notes:
auxdeclarations when constructing things recursively inside the field of a structure. I asked about this on Zulip and also here, but so far there doesn't seem to be a better way. In any case, it compiles so it should be fine. Otherwise, this port was very smooth.aux where(which is reallylet rec aux) this caused thedefLemmalinter to fire, which is being handled in lean4#1866, so for now we just add these declarations tonolints.json; see Zulip