## Before
```
× Type-checking
╰─▶ Unknown module field 'ValidityRaneg' in module 'aiken/transaction'
```
## After
```
× Type-checking
╰─▶ Unknown import 'ValidityRaneg' from module 'aiken/transaction'
╭─[../stdlib/validators/tmp.ak:2:1]
2 │ use aiken/interval.{Interval, IntervalBound, IntervalBoundType}
3 │ use aiken/transaction.{ScriptContext, ValidityRaneg}
· ─────────────
4 │
╰────
help: Did you mean to import 'ValidityRange'?
```
## Before
```
× Checking
╰─▶ Unexpected labeled argument
t
╭─[/Users/mati/Devel/OpenSource/time_lock_aiken/validators/time_lock.ak:13:1]
13 │ let now = when context.transaction.validity_range.lower_bound.bound_type is {
14 │ Finite { t } -> t
· ─
15 │ NegativeInfinity -> 0
╰────
```
## After
```
× Type-checking
╰─▶ Unexpected labeled argument 't'
╭─[../stdlib/validators/tmp.ak:10:1]
10 │ let now = when context.transaction.validity_range.lower_bound.bound_type is {
11 │ interval.Finite { t } -> t
· ─
12 │ interval.NegativeInfinity -> 0
╰────
help: The constructor 'Finite' does not have any labeled field. Its fields
must therefore be matched only by position.
Perhaps, try the following:
╰─▶ interval.Finite(t)
```
## Before
```
× Checking
╰─▶ Unknown variable
Finite
╭─[../stdlib/validators/tmp.ak:10:1]
10 │ let now = when context.transaction.validity_range.lower_bound.bound_type is {
11 │ Finite { t } -> t
· ────────────
12 │ NegativeInfinity -> 0
╰────
```
## After
```
× Type-checking
╰─▶ Unknown data-type constructor 'Finite'
╭─[../stdlib/validators/tmp.ak:10:1]
10 │ let now = when context.transaction.validity_range.lower_bound.bound_type is {
11 │ Finite { t } -> t
· ────────────
12 │ NegativeInfinity -> 0
╰────
help: Did you forget to import it?
Data-type constructors are not automatically imported, even if their type is
imported. So, if a module `aiken/pet` defines the following type:
┍━ aiken/pet.ak ━━━━━━━━
│ pub type Pet {
│ Cat
│ Dog
│ }
You must import its constructors explicitly to use them, or prefix them
with the module's name.
┍━ foo.ak ━━━━━━━━
│ use aiken/pet.{Pet, Dog}
│
│ fn foo(pet : Pet) {
│ when pet is {
│ pet.Cat -> // ...
│ Dog -> // ...
│ }
│ }
```
I am not entirely sure what the intent was for that keyword, but
nothing really matched between the parser, the formatter and the uplc
code gen. I don't think there's any need for a keyword here, trace is
already readily available from the builtins.
Before:
```
❯ aiken check
Error:
× No such file or directory (os error 2)
```
After:
```
❯ aiken check
Error:
× Missing 'aiken.toml' manifest in /Users/ktorz/Documents/Projects/aiken-lang/aiken
help: Try running `aiken new <REPOSITORY/PROJECT>` to initialise a project with an example manifest.
```
Co-authored-by: KtorZ <matthias.benkort@gmail.com>
This is the most intuitive thing I could come up with: since the
problem is mainly due to the order in which we try declaring the
aliases, then it suffices to simply try as much as we can, and retry
on failure until there's no more failure.
Note that it's important to detect cycles if we do such thing (which
we can by noticing that a given iteration didn't make any progress).
It works pretty well in the end and even allow us to define a new kind
of type error should there be a cyclic definition.
It's best to keep builtin as-close-as possible to their standard name
because they're hard to document. We can then leverage the prelude and
the standard lib for convenient names.
This is because there's no proper way to catch panics in Rust, which
makes it hard to know _which_ test did cause the panic when this
happen. The stack trace gives little detail about this, but we can
print this information before it happens -- making it easier to
identify the culprit.
- [x] Display function arguments using a newline-multiline strategy
when the signature gets too long. For example:
```
union_with
( left left: AssocList<key, value>
, right right: AssocList<key, value>
, with with: fn(key, value, value) -> value
) -> AssocList<key, value>
```
- [x] Show type-aliases as type-aliases in signatures; provided
they've been specified as type annotations. Otherwise, fallback to
the inferred type.
- [x] Do not show argument names in signatures, but show labels when
they're present. This reflects more the original intent behind
labels (which are meant as public-facing documentation).
Was introduced as a work-around to get some debugging info out of scripts, but tests do now provide the same capability with a better output and, do so automatically.
- Update generics syntax
- Add required args to default validator function
This allows running a successful aiken build from
files generated by aiken new.
Pretty useful for debbugging. Though, on second-thoughts, this is
something we may want to review later and maybe have that done by
default for tests.
At the moment, we expects tests to unify to `bool`, and treat `false`
values as failing tests. Yet, on failures, this gives little
information about what's wrong with the test.
It'd be nice to either have better way to assert in tests, or, to
simply accept non-bool tests, and show whatever the test evaluates
to as a debug output.
KtorZ