88b746dd48
This PR adjusts the results of `inferInstanceAs` and the `def` `deriving` handler to conform to recently strengthened restrictions on reducibility. This change ensures that when deriving or inferring an instance for a semireducible type definition, the definition's RHS is not leaked when the instance is reduced at lower than semireducible transparency. More specifically, given the "source type" and "target type" (the given and expected type for `inferInstanceAs`, the right-hand side and applied left-hand side of the `def` for `deriving`), we synthesize an instance for the source type and then unfold and rewrap its components (fields, nested instances) as necessary to make them compatible with the target type. The individual steps are represented by the following options, which all default to enabled and can be disabled to help with porting: - `backward.inferInstanceAs.wrap`: master switch for instance adjustment in both `inferInstanceAs` and the default `deriving` handler - `backward.inferInstanceAs.wrap.reuseSubInstances`: reuse existing instances for the target type for sub-instance fields to avoid non-defeq instance diamonds - `backward.inferInstanceAs.wrap.instances`: wrap non-reducible instances in auxiliary definitions - `backward.inferInstanceAs.wrap.data`: wrap data fields in auxiliary definitions (proof fields are always wrapped) This PR is an extension and rewrite of prior work in Mathlib: https://github.com/leanprover-community/mathlib4/pull/36420 Last(?) part of fix for #9077 🤖 Prepared with Claude Code # Breaking changes Proofs that relied on the prior "defeq abuse" of these instance or that depended on their specific structure may need adjustments. As `inferInstanceAs A` now needs to know the source and target types exactly before it can continue, it cannot be used anymore as a synonym for `(inferInstance : A)`, use the latter instead when source and target type are identical.
67 lines
1.8 KiB
Text
67 lines
1.8 KiB
Text
axiom Std.HashMap : Type
|
|
axiom Std.HashMap.insert : Std.HashMap → Std.HashMap
|
|
axiom Std.HashMap.get? : Std.HashMap → Int → Option Unit
|
|
|
|
structure St where
|
|
m : Unit
|
|
map : Std.HashMap
|
|
|
|
opaque P : St → Prop
|
|
|
|
noncomputable
|
|
def go1 (ss : Int) (st0 : St) : Bool :=
|
|
let st1 := { st0 with map := st0.map.insert }
|
|
match st1.map.get? ss with
|
|
| some _ =>
|
|
have : P st1 := sorry
|
|
have : P st1 := sorry
|
|
go1 ss st1
|
|
| none => true
|
|
termination_by st0
|
|
decreasing_by sorry
|
|
|
|
/--
|
|
info: go1.induct (ss : Int) (motive : St → Prop)
|
|
(case1 :
|
|
∀ (x : St),
|
|
have st1 := { m := x.m, map := x.map.insert };
|
|
∀ (val : Unit), st1.map.get? ss = some val → P st1 → P st1 → motive st1 → motive x)
|
|
(case2 :
|
|
∀ (x : St),
|
|
have st1 := { m := x.m, map := x.map.insert };
|
|
st1.map.get? ss = none → motive x)
|
|
(st0 : St) : motive st0
|
|
---
|
|
warning: declaration uses `sorry`
|
|
-/
|
|
#guard_msgs in
|
|
#check go1.induct
|
|
|
|
|
|
-- the above was the original bugreport, and a (spurious) mdata around the match
|
|
-- triggered a bug and looking through it solved it. But that would just hide it, and it
|
|
-- can be triggered like this:
|
|
|
|
noncomputable
|
|
def go2 (ss : Int) (st0 : St) : Bool :=
|
|
let st1 := { st0 with map := st0.map.insert }
|
|
id <| match st1.map.get? ss with -- the ss argument is needed
|
|
| some _ =>
|
|
have : P st1 := sorry -- both needed
|
|
have : P st1 := sorry -- both needed
|
|
go2 ss st1
|
|
| none => true
|
|
termination_by st0
|
|
decreasing_by sorry
|
|
|
|
/--
|
|
info: go2.induct : ∀ (motive : St → Prop),
|
|
(∀ (x : St),
|
|
have st1 := { m := x.m, map := x.map.insert };
|
|
motive st1 → motive x) →
|
|
∀ (st0 : St), motive st0
|
|
---
|
|
warning: declaration uses `sorry`
|
|
-/
|
|
#guard_msgs in
|
|
#check @go2.induct
|