If the type error is at an implicit argument, we annotate
application with `pp.explicit := true`
Given the type incorrect definition
```
def f {a b c : α} : a = c :=
Eq.trans (a := a) (b := b = c)
```
We now generate the error
```
error: application type mismatch
@Eq.trans α a (b = c)
argument
b = c
has type
Prop
but is expected to have type
α
```
@Kha Note that we only enable `pp.explicit := true` for the relevant
application. That is, we set `pp.explicit := false` for each children.
Unfortunately, there is a corner case.
```
set_option pp.explicit true
def f {a b c : α} : a = c :=
Eq.trans (a := a) (b := b = c)
```
produces the error
```
error: application type mismatch
@Eq.trans α a (b = c)
argument
@Eq α b c
has type
Prop
but is expected to have type
α
```
The reset `pp.explicit := false` overwrote the user option.
I think the simplest solution is the following
1- The delaborator saves the initial set of Options `Init`
2- When it finds a node annotated with a `pp` options, it only
consider the option if it is not set by `Init`.
What do you think?
In the new frontend,
```lean
@[macroInline] def or : Bool → Bool → Bool
| true, _ => true
| false, b => b
```
is compiled as
```lean
def or (x y : Bool) : Bool :=
or.match_1 _ x y (fun _ => true) (fun b => b)
```
Thus, the `[macroInline]` attribute does not guarantee that `y` is
evalutated only when `x` is `false`. The new definition does.
This issue was not exposed before because the compiler has an
optimization that float let-decls when they are used in a single
branch.
@Kha We have talked about removing `macroInline`, and defining
functions such as `or` as
```lean
@[inline] def or (x : Bool) (y : Unit -> Bool) : Bool :=
match x with
| true => true
| false => y ()
```
and define `x || y` as notation for `or x (fun _ => y)`.
I think this is the way to go for polymorphic operators such as `<|>`,
but I am not sure about `or`. New users will probably be puzzled by
it. In particular when they are writing proofs.
