This issue is similar to a bug where `isDefEqOffset` was exposing
`Nat.add` when processing `HAdd.hAdd`.
Fixes#561
The example at issue #561 is now working, but we may have other places
where raw literals are being accidentally exposed.
This makes sure we can properly quote e.g. `deriving` clauses and avoids
a suspicious `eraseMacroScopes` call (though not at `Elab.Syntax`, since
categories do not have to be declaration names)
Try to improve the performance issue described at #587.
The issue is that Mathlib contains thousands of theorems where the
associated key for the discrimination tree is just
`Key.other`. The indexing is not effective for them. This happens because
1- Lambda expressions are indexed using `Key.other`. The
discrimination tree mainly focus on the first-order structure.
2- It unfolds reducible constants when inserting and retrieving
entries. The motivation is that users expect simp theorems to fire
modulo reducible constants.
Then, we have many theorems such as
```lean
map ?g ∘ map ?f = map (?g ∘ ?f)
```
when we expand the function composition on the left-hand side, we get
```lean
fun (x : List ?α) => map ?g (map ?f x)
```
Which is indexed as `Key.other`.
We should not avoid the `Array`s in the discrimination tree nodes
If the index is working effectively, these arrays are all very small.
In this commit, we try to address the problem by using a different
approach. When processing the root of a pattern, we interrupt
reduction as soon as the we hit something that would be indexed
as `Key.other`. Note that, in Lean 3, the root of a pattern also
receives special treatment.
Make EOF handling in IO.FS.Handle consistent with EOF handling in
IO.FS.Handle.getLine. Previously returned error at EOF which ended up
causing segmentation fault. Remove the declaration of g_io_error_eof,
since it becomes redundant.
Closes#349
