Commit graph

8 commits

Author SHA1 Message Date
Joachim Breitner
316ff35afd
feat: deriving instances: use accessible names (#10271)
This PR changes the naming of the internal functions in deriving
instances like BEq to use accessible names. This is necessary to
reasonably easily prove things about these functions. For example after
`deriving BEq` for a type `T`, the implementation of `instBEqT` is in
`instBEqT.beq`.
2025-09-06 18:12:20 +00:00
Sebastian Ullrich
e74e9694fe
feat: revamp and unify visibility/exposure handling in deriving handlers (#10148)
Visibility is now handled implicitly for all deriving handlers by
adjusting section visibility according to the presence of private types
while removing exposition on presence of private constructors can be
opted in on a per-handler level via the new combinator
`withoutExposeFromCtors`.

Fixes #10062 #10063 #10064 #10065
2025-08-27 09:10:24 +00:00
Sebastian Ullrich
d07ec9a19f
chore: show @[expose] attribute in #print (#9722) 2025-08-05 15:59:49 +00:00
Sebastian Ullrich
467d905709
fix: more deriving handlers under the module system (#9647)
This PR fixes further deriving handlers to apply visibilities correctly
2025-07-31 15:00:58 +00:00
Sebastian Ullrich
b8e801ecad
fix: deriving BEq on public inductives with private ctors (#9630)
Make the instance public while the body becomes private
2025-07-30 14:57:17 +00:00
Kim Morrison
16bd7ea455
chore: deprecate List.iota (#6708)
This PR deprecates `List.iota`, which we make no essential use of. `iota
n` can be replaced with `(range' 1 n).reverse`. The verification lemmas
for `range'` already have better coverage than those for `iota`.
Any downstream projects using it (I am not aware of any) are encouraged
to adopt it.
2025-01-21 02:32:35 +00:00
Kyle Miller
94de4ae964
fix: make Repr deriving instance handle explicit type parameters (#5432)
The `Repr` deriving instance was assuming that all type parameters are
implicit. However, if the parameter came from a type index that was
promoted to be a parameter, then it is explicit. The result was that
some explicit constructor arguments were not being represented.

Reported [on
Zulip](https://leanprover.zulipchat.com/#narrow/stream/113489-new-members/topic/.23eval.20removes.20indexes.20inductive.20.20object.20descriptions/near/472301282).
2024-09-24 05:37:36 +00:00
Kyle Miller
a257767417
fix: make deriving handler for Repr be consistent about erasing types and proofs (#3944)
The deriving handler would use `_` for types and proofs for structures
but not for inductives.

Reported by Graham Leach-Krouse on
[Zulip](https://leanprover.zulipchat.com/#narrow/stream/113489-new-members/topic/Deriving.20Repr.20for.20an.20inductive.20with.20proof.20parameters/near/434181985).
2024-05-07 23:55:52 +00:00