| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Now I've fixed the type-checker, but it fails while running.
|
|
|
|
|
| |
Getting warmer. The unit tests for element_type now work, and the larger
test too seems to get further.
|
|
|
|
| |
Inline nth_type and nth_type_name.
|
|
|
|
|
| |
Make nth_type non-recursive in advance of hoisting the call into the
caller.
|
|
|
|
|
|
|
|
|
|
| |
Make it explicit that I don't currently intend to further replace type
ingredients inside replacements.
That might well make sense, but I've not thought up any use cases or
tests for it, and it seems excessive at the moment. And when I find bugs
I keep wondering if the repeated replace might be the problem. No
longer.
|
| |
|
|
|
|
|
| |
Also exercise the breaking part in a couple of the unit tests for
replace_type_ingredient. Now we need to fix all three.
|
|
|
|
|
|
| |
Fix the pending test while trying to fix the warning about 'merge'.
Warning still present.
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminated a few holes, gained more clarity on the shape of others.
Maybe I was sleep-deprived, but this was really hard until I wrote a few
unit tests directly on replace_type_ingredient.
Still one flaw remaining: the type-checker isn't smart enough to handle
'merge' for all the new cases. Tests pass since we don't use those
features outside C++ tests yet.
|
| |
|
|
|
|
|
|
|
|
| |
If you don't want a field of a container to be included in its hash, use
the /ignore-for-hash property.
This property only works for containers, not exclusive-containers or
arrays. Mu will warn if you misuse it.
|
|
|
|
| |
I've been gradually Greenspunning reagents. Just go all the way.
|
| |
|
| |
|
|
|
|
|
|
| |
This is smart enough to only look at data and ignores internal
book-keeping like addresses, refcounts and floating-point details.
Though the last is not ideal yet.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since it needs specialized non-overflowing types like unsigned long
long, my plan is to eventually write it in straight machine code using
Mu primitives to make that a slightly nicer process. Hopefully we'll
need to deal with machine types only for a tiny set of crucial
primitives and it won't be too painful to drop down to machine code for
them.
|
|
|
|
|
|
|
|
| |
Thanks Nicolas Léveillé for running up against this bug:
https://news.ycombinator.com/item?id=11094837
(Also noticed and fixed several subsidiary issues. This whole aspect
doesn't seem fully baked yet.)
|
|
|
|
|
| |
Also a bugfix: don't cause future parse errors when these checks are
triggered.
|
|
|
|
|
|
|
|
|
| |
The rule is: every 'local' variable in a recipe must have a fixed size.
Arrays can only be directly used in a recipe if their type includes a
size. But we haven't been warning about this, and attempts to use array
variables could cause silent memory corruption.
(Hopefully this is the last hole in our type system.)
|
|
|
|
|
|
|
| |
The rule is: a container type's size must be fixed. Arrays can violate
this rule if the array length isn't included in the type. But we haven't
been warning about this, and 'new' has been silently turning array
elements to be empty.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks chriscool and achikin for reporting this bug.
|
|\
| |
| | |
move enumerate, tangle dependencies to mu.cc
|
|/ |
|
| |
|
| |
|
|
|
|
| |
More tweaks to the trace after all my debugging.
|
| |
|
|
|
|
|
| |
Very cool that these passed without trouble after the previous change.
This is on the right track.
|
|
|
|
|
|
|
|
| |
The old approach of ad hoc boosts and penalties based on various
features was repeatedly running into exceptions and bugs. New
organization: multiple tiered scores interleaved with tie-breaks. The
moment one tier yields one or more candidates, we stop scanning further
tiers. Just break ties and return.
|
| |
|
|
|
|
| |
More tweaking of traces as I debug recipe specialization.
|
| |
|
| |
|
|
|
|
|
| |
Turns out we don't need to threshold non-shape-shifting and
shape-shifting variants at different levels to keep all tests passing.
|
|
|
|
|
|
|
|
|
|
| |
Thanks Caleb Couch for finding this. These tests were breaking only when
some other code somewhere has already triggered the specialization of
'append' for numbers.
How to test this? Perhaps the right fix is to warn when character
variants are used with literals. Or only when there's also a generic
variant that could conceivably be specialized for numbers.
|
|
|
|
|
|
| |
Just this conversion isn't in itself a violation of the type system --
as long as there's no way to convert back. Except there is with 'merge'.
Next step is to type-check 'merge'.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|