TMI: Short day

[tim]

I ended up only working a half-day today, as life and its endless cavalcade of errands and paperwork intervened. (Life is what we do in between sessions of paperwork, I guess?) But one of the things that intervened was a doctor's appointment that will result in me becoming hella more productive... we'll hope.

I'm still working on the two outstanding bugs I worked on yesterday, one being the shape code for comparing resources. While my post yesterday was rather elliptical, the basic idea here is that Rust has some polymorphic -- very polymorphic -- operations, such as logging and comparison, that are baked into the runtime system, that does some dynamic magic to figure out how to compare arbitrary values to each other. I still don't have the comparison operations for classes-with-destructors working, but I think I actually got a better grip on the runtime system code in the meantime. I also figured out that valgrind has an option (--track-origins=yes) to tell you who created the uninitialized values it's complaining about, and surprisingly, in this case, the values were created in... code generated from Rust code. Knowing that was very helpful, and led me to guess an alignment bug: a class with a destructor has an 8-bit unsigned int field that's the "drop flag" (which the destructor sets on entry, preventing multiple destructor calls in the case of cyclic structures) and then a field that's a pointer to the class itself. My guess is the struct fields were getting 64-bit aligned, leaving three bytes of uninitialized junk that makes valgrind unhappy. I haven't confirmed this for sure, but did try changing the u8 field in trans to a uint instead (haven't tested it yet... I got distracted).

The other one is the ifaces refactor, which isn't as annoying, it's just a matter of chasing down the places that are wrong and fixing them. Thank $deity for a regression test suite.