lean4-htt/tests/elab/deriving_diamond_defeq.lean
Sebastian Ullrich 88b746dd48 feat: unfold and rewrap instances in inferInstanceAs and deriving
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.
2026-03-22 13:25:46 +01:00

103 lines
3.7 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

/-!
# Delta Deriving Diamond Fix Test
This test demonstrates a fix for a diamond problem in delta deriving.
## The Problem
When deriving an instance for a type alias like `def MyAlias := Underlying`, the
delta deriving handler:
1. Unfolds the alias to find the underlying type
2. Synthesizes instances for the underlying type
3. Creates a derived instance for the alias
The bug: instance-implicit class parameters in the derived instance TYPE were
using instances synthesized for the UNDERLYING type, not the ALIAS type.
This causes a diamond when:
- The alias has its own instance for a dependency class (e.g., from a CommSemiring)
- The underlying type also has an instance (e.g., WithTop.addMonoidWithOne)
- These are defeq but different expressions
- Instance search uses the alias's instance, but the derived instance uses the underlying's
## The Fix
After synthesis succeeds, for each instance-implicit class parameter:
1. Re-synthesize the instance for the TARGET type (the alias)
2. If it's defeq to what we synthesized for the underlying type, use the target's
3. This ensures the derived instance type matches what instance search expects
## This Test
We create two different instance EXPRESSIONS for `MyBase` that are DEFINITIONALLY EQUAL:
- `instBaseNat` for `Nat` with `value := 42`
- `instBaseMyAlias` for `MyAlias` with `value := 42` (same, so defeq)
Before the fix: `deriving instance MyHigher for MyAlias` would create:
`instMyHigherMyAlias : @MyHigher MyAlias instBaseNat`
Instance search for `MyHigher MyAlias` finds `instBaseMyAlias`, no match → fails
After the fix: `deriving instance MyHigher for MyAlias` creates:
`instMyHigherMyAlias : @MyHigher MyAlias instBaseMyAlias`
Instance search finds `instBaseMyAlias`, matches → succeeds
-/
-- A base class with a simple value
class MyBase (α : Type) where
value : Nat := 42 -- default value
-- A higher class that requires MyBase
class MyHigher (α : Type) [MyBase α] : Prop where
prop : True
-- Instance for Nat using default
instance instBaseNat : MyBase Nat := {} -- value = 42
-- A NON-reducible type alias (like `def ENat := WithTop `)
def MyAlias := Nat
-- Instance for MyAlias ALSO using default
-- This is a DIFFERENT expression than instBaseNat, but DEFEQ since both have value=42
-- (Like AddMonoidWithOne from CommSemiring vs WithTop.addMonoidWithOne)
instance instBaseMyAlias : MyBase MyAlias := {} -- value = 42
-- Verify they're defeq (would fail if values differed)
example : @MyBase.value Nat instBaseNat = @MyBase.value MyAlias instBaseMyAlias := rfl
-- Instance of MyHigher for Nat
instance instHigherNat : MyHigher Nat where
prop := trivial
-- Derive MyHigher for MyAlias
deriving instance MyHigher for MyAlias
-- Check the instance type - must use instBaseMyAlias (the target type's instance), not instBaseNat.
-- This would have failed prior to https://github.com/leanprover/lean4/pull/12339
/--
info: instMyHigherMyAlias : @MyHigher MyAlias instBaseMyAlias
-/
#guard_msgs in
set_option pp.all true in
#check @instMyHigherMyAlias
/--
info: @[implicit_reducible] def instMyHigherMyAlias : @MyHigher MyAlias instBaseMyAlias :=
instMyHigherMyAlias._proof_1
-/
#guard_msgs in
set_option pp.all true in
#print instMyHigherMyAlias
-- Instance search must succeed!
-- This worked on `master`, but would be broken by https://github.com/leanprover/lean4/pull/12179,
-- but is working again under 12179+12339.
-- This would fail before the fix because instance search uses instBaseMyAlias
-- but the derived instance had instBaseNat in its type
/--
info: inferInstance : MyHigher MyAlias
-/
#guard_msgs in
#check (inferInstance : MyHigher MyAlias)
-- Verify we can use the instance
example : (inferInstance : MyHigher MyAlias).prop = trivial := rfl