@Kha I didn't find any workaround for the instance
```lean
instance coeFunTrans {α : Sort u} {β : Sort v} {γ : Sort w} (a : α) [CoeT α a β] [CoeFun β (coe a) γ] : CoeFun α a γ :=
```
`γ` is an output param. Thus, it is just a metavariable, and if we use
the default order, the subgoal `CoeFun ?β (coe ?a) ?γ` is really bad.
We need to go from left to right here.
The macOS CI build rarely, randomly fails with a "failed to lock file" message.
This commit will not fix this error, but at least should make it clearer whether
the file actually cannot be locked or is just missing.
/cc @leodemoura
@Kha Patterns with nested "choice" nodes produce counterintuitive
behavior, and hard to understand errors. They only work when we have
the exact same overloads at macro definition and application time.
Here is a funky example
```
syntax [myAdd] term "++":65 term:65 : term -- overloads "++"
/- The following `macro_rules` manages to eliminate "choice" node by using the
explicitly provided node kind. -/
macro_rules [myAdd] `($a ++ $b) => `($a + $b)
check (1:Nat) ++ 2 -- works as expected
syntax "FOO!" term : term
/- Before this commit, the following pattern was accepted,
and it contained a "choice" node for `++`. It is a `myAdd` or
`HasAppend.append`.
Now, this kind of pattern is rejected since it contains a nested
"choice" -/
macro_rules `(FOO! $a ++ $b) => `($a ++ $b)
/- Before this commit, the following command worked because
it contained a "choice" node similar to the one at macro definition
time. -/
check FOO! [1, 2] ++ [2, 3]
-- Now, we have 3 overloads for "++".
syntax [myAppend] term "++":65 term:65 : term
-- The `macro_rules` fails here.
```
This commit fixes this weird behavior by disallowing "choice" nodes in
patterns.
We can now write
```lean
syntax "case!" ident ":" term "with" term "," term : term
macro_rules
| `(case! $h : $c with $t, $e) => `(let $h := $c; cond $h $t $e)
```
Before the series of commits to change `let` syntax, the
quasiquotation `(let $h := $c; cond $h $t $e)
produced the weird error message "`;` expected" at ":=".
The problem was that $h was matching the now deleted "nonterminal"
```lean
def letIdDecl := parser! try (letIdLhs >> " := ") >> termParser
```
This was not a bug, but a side-effect on how the `let` syntax was
declared.
cc @kha
It avoids hidden nonterminals, and store the equation case as a
separate rule. It would be great if we could have 3 independent rules,
but this is not possible because `longestMatch` would return a choice
for terms as simple as `let x := v; ...` The problem is that it is
both a `letSimpleDecl` and a `letPatDecl`. We resolve the ambiguity at
the parsing level using `<|>`.
cc @Kha
@Kha this commit fix another example of weird error message I have
experienced in the last few days.
The macro
```lean
syntax "case!" ident ":" term "with" term "," term : term
macro_rules
| `(case! $h : $cond with $t, $e) =>
`((fun $h => cond $h $t $e) $cond)
```
is accepted, but as in `fun` binders, we get a weird error when
trying to elaborate an instance of the macro.
Example:
```lean
check case! h : 0 == 0 with h, not h
```
