b639d102d1
The expression tree elaborator computes a "maxType" that every leaf term can be coerced to, but the elaborator was not ensuring that the entire expression tree would have maxType as its type. This led to unexpected errors in examples such as ```lean example (a : Nat) (b : Int) : a = id (a * b^2) := sorry ``` where it would say it could not synthesize an `HMul Int Int Nat` instance (the `Nat` would propagate from the `a` on the LHS of the equality). The issue in this case is that `HPow` uses default instances, so while the expression tree elaborator decides that `a * b^2` should be referring to an `Int`, the actual elaborated type is temporarily a metavariable. Then, when the binrel elaborator is looking at both sides of the equality, it decides that `Nat` will work and coercions don't need to be inserted. The fix is to unify the type of the resulting elaborated expression with the computed maxType. One wrinkle is that `hasUncomparable` being false is a valid test only if there are no leaf terms with unknown types (if they become known, it could change `hasUncomparable` to true), so this unification is only performed if the leaf terms all have known types. Fixes issue described by Floris van Doorn on [Zulip](https://leanprover.zulipchat.com/#narrow/stream/287929-mathlib4/topic/elaboration.20issue.20involving.20powers.20and.20sums/near/439243587). |
||
|---|---|---|
| .. | ||
| bench | ||
| compiler | ||
| elabissues | ||
| ir | ||
| lean | ||
| pkg | ||
| playground | ||
| plugin | ||
| simpperf | ||
| .gitignore | ||
| common.sh | ||
| lean-toolchain | ||