- In the morning, I found that the snapshot I'd finally started last night had built, but it didn't do me much good because there was another bug fix I'd made right after that that didn't make it into the snapshot, which stopped any progress on my main task (changing the standard library code to use classes with destructors instead of resources).
- I pushed a new snapshot, but it failed to build only on FreeBSD because of a random pretty-printing problem (we have tests that check that the pretty-printer generates output that can be parsed, but somehow a warning message was getting mixed in with the pretty-printer output and preventing one test from passing).
- After failing to achieve understanding of exactly what changed to cause this test to fail, I fixed the test to suppress the warning (by prefixing the name of an unused variable with "_" -- sadly, test cases often end up having unused variables, but we warn about them now...) and started a new snapshot going.
- That new snapshot is finished compiling on every platform but Mac. Right now I'm not sure if the Mac bot is wedged or just slow, and for whatever reason I only have ssh access to the linux machines and not the Mac, so I can't just kill processes or anything.
In the meantime, I decided it was finally time to set up two separate directories for working on Rust, so I can work on one bug while the code for a different bug is compiling. You'd think this would be easy, but with git, nothing is easy. I decided it was easier to just clone a new repo directly from github rather than trying to clone my working directory -- even though this way I'll have to pull each local branch I want to work on one-by-one -- and eventually this worked. I'm in mortal danger of getting confused about which copy of a file I'm working on now, though (I already changed a file in rust and recompiled in rust3) and I can't see any way to have multiple Aquamacs instances open. Again, the glamorous life...
After I wrote my post yesterday, I fixed this bug involving storing empty classes in a data structure, and I decided the easiest solution was to make the typechecker forbid classes that have no fields, since this doesn't really make sense (you can use an impl to define grouped methods with no state) and for consistency with record types (empty record types weren't allowed). I also experimented with pushing to our new incoming branch, part of a glorious new testing regime in which no one pushes directly to master and you don't have to run the whole test suite on your local machine -- instead, you push to incoming and a rotating volunteer merges commits that pass tests into master. So I pushed without running tests... which meant that some tests failed. But I experienced some confusion when I tried running tests locally and the tests that failed on the buildbots... didn't fail for me. Eventually I sorted it all out; turns out a few test cases were using classes with no fields. I'm still not sure why the tests didn't properly fail the first time I ran them.
The other thing I did today besides waiting was fix issue 2502, which was causing a vexingly but not singularly befuddling type error message:
error: mismatched types: expected `&self.[u8]` but found `&self.[u8]` (references with lifetime &self do not necessarily outlive references with lifetime &self)Expected X but found X! This error message has to do with lifetimes (aka regions) in Rust; a class has a self lifetime associated with it, which was getting used by a class in this test case. It turned out that as you might expect, the two selfs here actually referred to different things: the first to the class's own self lifetime, the second to some random lifetime that happens to be named "self". This was just because I never got the code for class constructors and destructors right at all when it came to lifetimes, because I didn't understand lifetimes -- and I still don't really, but I was able to figure out by looking at other code what the right change to make was to fix the bug.
Finally I picked up issue 2487, which happily seems to be a dup of a bug I already fixed (I love when that happens), but maddeningly, the test is failing the previously-mentioned pretty-printing test: the output of pretty-printing the code itself is different from the output of parsing the first pretty-printed code and then pretty-printed again. I think I found the bug, though, which is actually a bug I caused (and fixed) once before: the pretty-printer preserves comments, so the round-trip test will work, and a blank line by itself also counts as a comment. The pretty-printer has to call a function that prints whatever comments occur "up till the current span" periodically -- if it doesn't call it in some place where it should, a comment could get magically teleported to a different place, causing inconsistent output. I'm pretty sure that's what happened in this case, but I was just waiting for a compile to finish so I can verify that. Answers next time!
Oh, and I never got back to debugging that memory leak today, because I still don't have a snapshot after all day! Yeah, this was kind of a frustrating day. But that can happen, even in Australia.