Before this commit, given `x n : nat` the expression
```
to_bool (n <= x)
```
where `n` is a numeral <= 1024 was being elaborated as
```
@decidable.to_bool (@has_le.le.{0} nat nat.has_le n x) (nat.decidable_lt n' x)
```
where `n'` denotes the numeral `n-1`
Example:
```
to_bool (800 <= x)
```
was elaborated as
```
@decidable.to_bool (@has_le.le.{0} nat nat.has_le 800 x) (nat.decidable_lt 799 x)
```
Reason: `nat.lt` and `nat.le` were reducible. The module `type_context`
has support for solving "offset constraints" for small numerals.
These constraints include:
- `succ ?x =?= n` ===> `?x := n - 1`
For elaborating `to_bool (800 <= x)`, we need to synthesize
```
decidable (@has_le.le.{0} nat nat.has_le 800 x)
```
using type class resolution.
The instance `nat.decidable_lt` is tried before `nat.decidable_le`. For
this instance, we need to solve the unification problem.
```
decidable (@has_lt.lt.{0} nat nat.has_lt ?n ?x) =?= decidable (@has_le.le.{0} nat nat.has_le 800 x)
```
which reduces to:
```
nat.less_than_or_equal (succ ?n) ?x =?= nat.less_than_or_equal 800 x
```
because `nat.le` and `nat.lt` are marked as `[reducible]`.
This constraint reduces to
```
succ ?n =?= 800
```
which is solved using the offset constraint support as
```
?n := 799
```
The kernel does not have support for offset constraints, and may take
a considerable amount of time to check that `succ 799` is definitionally
equal to `800`. This is particularly expensive when trust level 0 is
used.
It was taking almost 1 minute to execute the leanchecker test before
this commit because we add the new predicates for checking which
characters can be used in a Lean identifier.
This commit fixes the problem by removing the annotation `[reducible]`
from `nat.lt` and `nat.le`. This performance issue may be triggered
by any reducible instance that may create offset constraints during
type class resolution.
cc @kha
45694ae44a