chore(CategoryTheory/Presentable): remove a backward.isDefEq set_option

[dennj]

See #42925

[github-actions]

PR summary b67a2995fe

Import changes for modified files

No significant changes to the import graph

Import changes for all files

Files	Import difference

---

Declarations diff (regex)

No declarations were harmed in the making of this PR! 🐙

You can run this locally as follows

## from your `mathlib4` directory:
git clone https://github.com/leanprover-community/mathlib-ci.git ../mathlib-ci

## summary with just the declaration names:
../mathlib-ci/scripts/pr_summary/declarations_diff.sh <optional_commit>

## more verbose report:
../mathlib-ci/scripts/pr_summary/declarations_diff.sh long <optional_commit>

The doc-module for scripts/pr_summary/declarations_diff.sh in the mathlib-ci repository contains some details about this script.

Declarations diff (Lean)

✅ Lean-aware diff — post-build, computed from the Lean environment (commit b67a299).

• +0 new declarations
• −0 removed declarations

No declaration differences.

---

Decrease in strong tech debt: (relative, absolute) = (1.00, 0.00)

Current number	Change	Type (strong)
2560	-1	backward.isDefEq.respectTransparency.types

No changes to weak technical debt.

Current commit b67a2995fe
Reference commit 9b397f578e

This script lives in the mathlib-ci repository. To run it locally, from your mathlib4 directory:

git clone https://github.com/leanprover-community/mathlib-ci.git ../mathlib-ci
../mathlib-ci/scripts/reporting/technical-debt-metrics.sh pr_summary

• The relative value is the weighted sum of the differences with weight given by the inverse of the current value of the statistic.
• The absolute value is the relative value divided by the total sum of the inverses of the current values (i.e. the weighted average of the differences).

[YaelDillies]

Which type is being abused here? Do you know?

[dennj]

Which type is being abused here? Do you know?

It's not ToType. The aesop call fails without the flag even for a generic f : ι → β, so it's the subtype ↥(Set.range f): aesop needs to unfold · ∈ Set.range f inside the type to close the goal, and the flag allows that. The explicit rintro proof doesn't touch the type, so the flag can go.

[YaelDillies]

Ideally we would like aesop to work here, even without the flag. Could you investigate what lemmas/annotations are missing to make it work?

[dennj]

Ideally we would like aesop to work here, even without the flag. Could you investigate what lemmas/annotations are missing to make it work?

Nothing is missing from aesop: the problem was the term ⟨f i, i, rfl⟩ itself. Its membership proof has type ∃ y, f y = f i and using it as f i ∈ Set.range f is exactly the defeq the flag re-allowed; since that sits inside the Subtype.mk, the Subtype.mk.injEq step aesop wants to use fails to typecheck without the flag. Writing ⟨f i, Set.mem_range_self i⟩ instead makes plain aesop work with no flag and no extra lemmas, so the diff is now just the set_option removal plus that one term fix.

[YaelDillies]

Thanks! 🚀

maintainer merge

[github-actions]

🚀 Pull request has been placed on the maintainer queue by YaelDillies.

[joelriou]

Thanks!

bors merge

[mathlib-bors]

Build failed:

• ci (staging) / Post-Build Step

Fix if necessary, and then someone with permission can run bors r+ or bors retry.