a00cf6330f
This PR adds a case to `Level.geq` that is present in the kernel's level `is_geq` procedure, making them consistent with one another. This came up during testing of `lean4lean`. Currently `Level.geq` differs from `level::is_geq` in the case of `max u v >= imax u v`. The elaborator function is overly pessimistic and yields `false` on this while the kernel function yields true. This comes up concretely in the `Trans` class: ```lean class Trans (r : α → β → Sort u) (s : β → γ → Sort v) (t : outParam (α → γ → Sort w)) where trans : r a b → s b c → t a c ``` The type of this class is `Sort (max (max (max (max (max (max 1 u) u_1) u_2) u_3) v) w)` (where `u_1 u_2 u_3` are the levels of `α β γ`), but if you try writing that type explicitly then the `class` command fails. Omitting the type leaves the `class` to infer the universe level (the command assumes the level is correct, and the kernel agrees it is), but including the type then the elaborator checks the level inequality with `Level.geq` and fails. --------- Co-authored-by: Kyle Miller <kmill31415@gmail.com> |
||
|---|---|---|
| .. | ||
| bench | ||
| compiler | ||
| elabissues | ||
| ir | ||
| lean | ||
| pkg | ||
| playground | ||
| plugin | ||
| simpperf | ||
| .gitignore | ||
| common.sh | ||
| lean-toolchain | ||