| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
One more test.
|
|
|
|
|
|
|
| |
Now test-return-unavailable-value is passing,
but test-convert-return-with-duplicate-values is failing.
Time to think.
|
|
|
|
|
|
|
|
| |
2 new tests:
test-return-unavailable-value - currently failing
test-convert-return-with-duplicate-values - currently passing
I don't yet know how to make both pass.
|
| |
|
| |
|
|
|
|
|
| |
All tasks of https://github.com/akkartik/mu/issues/45#issuecomment-719990879
should now be complete.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Assignments to them will no longer work, and they can never be live variables.
https://github.com/akkartik/mu/issues/45#issuecomment-719990879, task 3.
|
| |
|
|
|
|
| |
https://github.com/akkartik/mu/issues/45#issuecomment-719990879, task 2.
|
| |
|
| |
|
| |
|
|
|
|
| |
apps/arith.mu compiling again.
|
| |
|
|
|
|
| |
Bugfix in computing the label a return should jump to.
|
|
|
|
|
|
| |
https://github.com/akkartik/mu/issues/45#issuecomment-719990879, task 1.
We don't have checking for it yet. Soon.
|
|
|
|
| |
Drop pending tests for the old plan of liveness analysis.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This isn't done, but an intermediate snapshot seems worth capturing.
Back in March (commit 6082), I made a plan to check writes to function
outputs using liveness analysis. I've been shying away from actually acting
on this plan ever since. In recent weeks I've had this gap bite me three
times.
Returning to the problem now, I think I don't actually need to compute
variable liveness. The compiler can, I think, do the same thing for output
registers whether their variables are alive or dead. The new rule is this:
Once a register gets a function output written to it, no local is popped
into it. Instead of popping outer locals to the register, we simply increment
the stack and keep going.
Since the function output will continue to live on the vars stack past
this point (see clean-up-block), any attempts to read shadowed variables
will throw an error as usual.
This rule is also now easy to explain to people, I think. "You wrote the
function output. Now the register can't be used for anything else."
It's really cool that this works (if it does). Another fruit from "Mu's
lovely property."
|
|
|
|
| |
Am I starting to have too much code duplication?
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Lots of copy-pasta.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Hacking on apps has created some urgency now for several additional safety
checks.
|
|
|
|
|
|
|
|
|
|
| |
Amazing how easy this was. And it does feel more intuitive. If I decide
at some point that I want to bind something to a name I don't usually want
to lose the entire line after that point.
It also sidesteps for now the thorny question of whether to permit organically
switching to a new line (rather than using the 'name value' hotkey), and
how that should work.
|
|
|
|
| |
More consistent spacing in sandbox render.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Starting to polish 'line-count' demo:
filename line-count
= filename open lines len
|