Make a current-state PRNG thing.
Remove old typechecking proof-of-concept
Minor notes and cleanup. Did a read-through from start to end and you know, it's not terrible.
Attempt to make generic inference work. It's uh... there's some weird fucking shit going on in there. I've updated what I have in the issue: https://todo.sr.ht/~icefox/garnetc/21
thiiiiiiink this gets rid of @ sigils for type parameters. Need to go through more tests and clean them up tho.
Oops we allow direct recursive types. https://todo.sr.ht/~icefox/garnetc/29
Type double-checker is now complete. Fixed the bug that are actual bugs, idk how to fix one of them so it's in https://todo.sr.ht/~icefox/garnetc/28
Oops I found lots of cases where the type checker fucks up~ I mean, I guess they were there anyway.
Now that I've done this flattened-HIR thing I don't need to worry about it.
Experiment with flattening our tree-based HIR into a vec of nodes. It's certainly possible, but doing it is at least as much of a pain in the ass as writing it was in the first place. And I doubt the benefit is that high, since we tend to allocate all our IR nodes at once anyway so locality is probably decentish. I'm sure the benefit is PRESENT, but doesn't matter right now. I just wanted to see what the API would look like and, as expected, there are some annoying wrinkles.
Revert commit 24722db3fc92 Rc'ing types instead of cloning does improve performance of passes and other tree-manip-stuff by roughly 10%, but is inconvenient enough that it's prolly not worth it. Interning them would work better and also be easier since it'd make all our types Copy. But that attempt also had a bit of nice code cleanup in it, so I've tried to preserve it.
turns out cloning the parser is expensive
play around with benchmarking and Rc in types vs. Box. The results are... not worth it, to say the least. Rc'ing vs Box'ing in types does indeed save a bit of time, about 10%, in various passes since we probably avoid a lot of copying of types. However, what takes the most time apart from executing rustc of course is actually the parser! Given my propensity for saying "parsing isn't slow, don't worry about it" to new PL devs, all I can say is... lol. lmao. But it's still 60k lines a second or whatever, so it's fine even if I expected it to be like 3x that. But attempting to profile garnetfmt (while commenting out anything it does besides parsing) results in `perf` saying that 93% of the time is spent in `__memmove_avx_unaligned_erms`. And if that isn't a sign from on high to shrug and get on with life then idk what is. XD If we wanna optimize types then really they should be interned and/or flattened into a vec instead of a tree, I suspect. Then the AST and HIR should be flattened into a vec as well, though honestly they tend to be allocated all together so I bet data locality is pretty ok anyway. But none of that matters compared to the parser! Well this was a weird Learning Experience, I guess.
Minor cleanup and a failing test I should make succeed.
set default run binary to garnetc
Make unsigned integers work. Our integer values are all stored as i128, so our own i128 type has been sacrificed on the altar of simplicity. But I'm willing to let that be the case for now.
Allow you to elide trailing {} rettype in function signatures. Took a little more finesse than expected but not too bad.
Add while loops.
Add a basic PRNG to the unit tests. Exposes lots of flaws tbqh, and we need unsigned numbers to make it really work properly. But it does work!
Add borrow checking test case