Namely:
1. Fully evaluate & type-check the label, irrespective of the trace level. So that labels using other variables do not generate "unused identifier" warnings when compiling with different trace mode (and so that the success of a build doesn't depend on the trace level).
This was already done for trace arguments, but not for labels, somehow.
2. Move the requirement for compact trace label being String from errors down to warnings; following point (1), we shouldn't fail compilation for different trace levels. It seems more reasonable to simply raise a warning.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Wrongly suggesting args in lexicographical order instead of definition order... The tests were unfortunately only examplifying situations where the fields where also defined in lexicographical order... thus never really showing the issue. It came up in the real world, though. Whoopsie.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Without this fix, the parser wrongly turns the following:
```
{
let a = Void
a
}
let _ = True
True
```
into the following:
```
let a = Void
a
let _ = True
True
```
Which in this particular example looks benign. But now takes something
more _real-world_:
```
{
let scope, output <- for_each_2(scopes, other_outputs)
Void
}
let _ = True
True
```
This would lead to the the entire sequence that follows the
backpassed continuation to be added to the continuation; here
ultimately causing a type unification error (since for_each_2 is
expected to yield Void, not Bool).
This is utterly confusing.. and dangerous.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
While the feedback for human users is mostly the same, it does in fact
matter for the LSP since the quickfix will be different depending on
whether we look for a top-level identifier or if we look for a
constructor.
The typical case we see in the stdlib is the `VerificationKey` and
`Script` constructors for `Credential`, often being mixed with
their types counterparts in aiken/crypto!
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
1. A new option `show_json_schema` which, when enabled, will print the JSON schema of the command output if the target isn't an ANSI-capable terminal.
2. Some modifications to the help message and error handling for the new option `show_json_schema`.
This is now done to avoid flooding the help screen with an entire
JSON schema. Plus, it makes the schema more easily exportable as an
actual JSON schema.
rvcas