TMI: Sleepy Monday

[tim]

When I left off, I was wondering why my memory leak had turned into an LLVM assertion failure. Fortunately, I didn't need to hack LLVM to make its error message more useful, at least not this time. Mental static analysis did the job: I looked at my code for translating class destructors again, and realized that the code that was monomorphizing destructors (making specialized copies in the case where the containing class has type parameters) was re-using the same instance for destructors that had different type parameters. In particular, that meant if you had a class foo<T>, and one call site instantiated it at int and the other one instantiated it at str, and the int int one happened to get visited first, the str call site would call the int destructor when the object needed to be freed, and then the str field (if there was one) would never get freed, causing a memory leak. Or at least, I assume this was causing the memory leak I saw before; I'm not sure why the assertion failure didn't trip before seeing a runtime error before. Fixing that code definitely fixed the assertion failure, and it turned out the memory leak went away too -- hopefully because of the same fix.

The context for all of this was turning resources in core::comm into classes, and my change just now allowed me to compile the code with one resource changed into a class. The other one didn't quite work as in the original version because there was a separate bug preventing classes nested inside functions from being referred to in the same scope. This was a pretty simple resolve bug (all my fault, and visible on inspection). But when I thought I fixed that bug, I got the opposite problem: an error about a duplicate definition of a class that was defined at the *top* level, and only once. Which makes no sense. I'll have to visit it tomorrow.

I also worked on issue 2242, which manifested for the reporter (two months ago) as an LLVM error message, but now seems to manifest as a type error. However, the type error isn't correct, since it complains about multiple impls of the same iface in scope when the two impls are actually the same: a direct import, and a re-export through another module, of the same impl. I'm trying to fix that.

Finally, I looked at the Rust team's POPL submission in progress (no link for that!), about how regions and safe references work in Rust. Hopefully I'm going to work on the section that introduces the features of Rust's type system that are relevant to the paper; the main content and formalism aren't things I've been elbow-deep in, but I like to think I'm good at giving background and motivation, so.