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>
This is a mildly scaring change, as it may horribly break things down
the line if we have ever relied on that information... However, the
value constructors inside each module are meant to reflect the own
module public API, and shouldn't be populated with Prelude stuff. Not
only does that mean this information is duplicated for all modules
(possibly significantly slowing things down), but it may also cause
weird scoping issues (e.g. one accessing a Prelude's constructor
through some random module).
Hence why I am isolating this change in this single commit, so it's
easier to troubleshoot if that ends up causing weird issues.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
We were mixing module names and package names in a very weird way but it was somehow working. However, the generated ASTs would vastly differ from what we would typically get from running those tests on a standard project -- which defies a bit the purpose of those tests.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Turns out the snapshot test would randomly fail because the expected
tokens are a HashSet, which is unordered by construction. So, using
the auto-derived `Debug` instance to compare it with snapshot would
only succeed if the tokens happened to be in the same order in the
HashSet, which only happens by accident.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Somehow, we allow traces with no continuation after and currently
default to a Todo. That todo is completely invisible from a user
standpoint and return a generic `a`.
So it is pretty easy for someone to think their program is okay,
compiles, and have no issues, while simply crashing at runtime because
of an invisible todo.
Hence, I've changed that to default to `Void` instead, which is more
sensible as a default for an empty trace.
Also, I've made the parser fail with one puts a colon for label, but
doesn't add any value to display.
Fixes#1113.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
Has somewhat always been bothering me that it says 'compiling Aiken', which means kind of nothing in this context.
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>
Also, show it actually for UnknownTypeConstructor, and not
UnknownVariable. There's currently an error that wrongly assign an
'UnknownVariable' in place where it should be an
'UnknownTypeConstructor'. Fix coming in the next commit.
Signed-off-by: KtorZ <matthias.benkort@gmail.com>
The clones are cheap enough here that we likely don't need to worry about the cost of cloning; and this removes a significant foot-gun where you can wipe out the logs/labels by accessing the other field.
This refactors things so that eval_phase_two can expose logs even when the script succeeds.
It also enriches traces to be either Logs or Labels, so that we can tell the difference between the two when inspecting the traces.
This is likely even better than what was done for property testing. We
shall revise that one perhaps one day.
Signed-off-by: KtorZ <5680256+KtorZ@users.noreply.github.com>
Going for a terminal plot, for now, as this was the original idea and it is immediately visual. All benchmark points can also be obtained as JSON when redirecting the output, like for tests. So all-in-all, we provide a flexible output which should be useful. Whether it is the best we can do, time (and people/users) will tell.
Signed-off-by: KtorZ <5680256+KtorZ@users.noreply.github.com>
The idea is to get a good sample of measures from running benchmarks
with various sizes, so one can get an idea of how well a function
performs at various sizes.
Given that size can be made arbitrarily large, and that we currently
report all benchmarks, I installed a fibonacci heuristic to gather
data points from 0 to the max size using an increasing stepping.
Defined as a trait as I already anticipate we might need different
sizing strategy, likely driven by the user via a command-line option;
but for now, this will do.
Signed-off-by: KtorZ <5680256+KtorZ@users.noreply.github.com>
Matthias Benkort