It fixes the issue by propagating the correct information to the
equation compiler.
The fix may be a little bit hackish, but it is comapatible with
the approach we are already using: store `m_is_meta` flag in the equation
macro.
Disclaimer: we may still have other instances of this bug, since
the information may still be propagated incorrectly in other places.
I will not refactor this code right now nor accept any PR that
changes the current design. I am busy in other parts of the code
base and do not have time to do the context switch required for
implementing this kind of change and/or review the PR and make sure I'm
happy with it.
@kha: I decided to implement this change before I start the
type_context modifications. The change did not affect the corelib and
test suite much. The only annoying problem is that `out` cannot be
used to name locals anymore.
The `induction h` tactic tries to clear hypothesis `h` after it is
applied. But, before this commit, `cases h` would only try to clear `h`
when performing non-dependent elimination. This was problematic when
writing tactic scripts for automating proofs.
The `no_confusion` construction is only generated for inductive
datatypes supported in the kernel.
Before this commit, given `h : T`, `cases h` could leak the internal encoding
used by the inductive compiler WHEN a nested and/or mutual inductive
datatype is used to index the inductive datatype `T`.
The new test exposes the problem.
The solution implemented in this commit uses inj_arrow lemmas
generated by the inductive compiler. We only use the lemmas
if the target is a proposition. If it is not, we sign an error.
The reason for this limitation is documented in the source code.
cc @jroesch @dselsam
Jared: the information leakage has been fixed. So, students will not be
confused by the internal encoding used in the inductive compiler.
I added the example I posted on slack as a new test.
Note that, the workaround I used has been removed.
`{s with ...}` is now `{..., ..s}`, which more clearly expresses that the
result type is not necessarily equal to the type of `s` (in absence of an
expected type and a structure name, we still default to the type of `s`).
Multiple fallback sources can be given: `{..., ..s, ..t}` will fall back to
searching a field in `s`, then in `t`. The last component can also be `..`,
which will replace any missing fields with a placeholder.
The old notation will be removed in the future.
Now, `cmp` is just a fixed helper function.
In the future, we will be able to use (more efficient) specialized
versions during code generation by defining simp rules.
This should match the meaning of "$?" in bash:
"3.7.5 Exit Status
The exit status of an executed command is the value returned by the waitpid system call or equivalent function. Exit statuses fall between 0 and 255."
Fixes#1868
The new test exposes the problem. Before this commit, the common
subexpressions at
```
def tst : tree → nat
| (tree.leaf v) := v
| (tree.node v l r) :=
match f v with
| tt := tst l + tst l - tst l -- <<< HERE
| ff := tst r
end
```
were not converted into a let-exprs.
