| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
Turns out we don't need a primitive to return an empty value of
arbitrary type. Just create it on the heap using 'new'.
But this uncovered *yet* another bug, sigh. When I specialize generic
functions I was running all transforms on the generated functions after
specialization completed. But there's one transform that includes code
from elsewhere. If such code included type-ingredients -- kaboom. Now
fixed and there's a test, so I've got that going for me which is nice.
|
| |
|
|
|
|
|
| |
Now that we no longer have non-shared addresses, we can just always
track refcounts for all addresses.
Phew!
|
| | |
|
| |
|
|
|
|
| |
On reflection I think I'd rather add a duplicate test that's closer to
how I discovered the problem, without the masking bug in type-matching
that was masking the simpler test in the previous commit.
|
| |
|
|
| |
Thanks Caleb Couch for finding and reporting this.
|
| |
|
|
|
| |
Show more thorough information about instructions in the trace, but keep
the original form in error messages.
|
| |
|
|
|
|
|
|
| |
As outlined at the end of 2797. This worked out surprisingly well. Now
the snapshotting code touches fewer layers, and it's much better
behaved, with less need for special-case logic, particularly inside
run_interactive(). 30% slower, but should hopefully not cause any more
bugs.
|
| |
|
|
|
|
|
|
|
|
| |
This way when you pass one end to a function or routine, you can
implicitly give it the right to either read or write the channel, but
not both.
The cost: code gets more convoluted, names get more convoluted. You can
see this in particular in the test for buffer-lines. Let's see how it
goes..
|
| |
|
|
|
|
|
| |
Simplify 2790 by simply not computing any type->value inside
parse_type_tree. It now only generates names, and it turns out the
consumers handle the absence of values anyway. Now parse_type_tree no
longer pollutes the Type_ordinal table with type ingredients.
|
| |
|
|
|
|
|
|
| |
The issue alluded to in the previous 2789 is now fixed. I'm not happy
with my solution, though. I pollute Type_ordinal with type ingredients
in parse_type_tree and simply ignore such entries later on. I'd much
rather avoid the pollution in the first place, but I'm not sure how to
do that..
|
| |
|