TMI: Appetite for destructors
May. 17th, 2012 10:54 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Yesterday
Finishing up porting resource tests to use destructors. I got behavior I couldn't understand with one test, resource-cycle, so I'll ignore that for now and move on to resource-generic.Aside from having to prefix every field reference with self., the porting itself is pretty straightforward. (As I'd expect, since a class with a destructor is a pretty straightforward generalization of a resource.)
Random thought: I love seeing an internal compiler error -- it's much better than a program segfaulting -- because I know it's absolutely a bug no matter what, and that I can get a backtrace that will probably be helpful. In this case it was a non-exhaustive match in type_use::type_uses_for. Yet another reason why I despise alt check (Rust's non-exhaustive pattern-matching construct, like an incomplete case in Haskell) -- when I'm extending the compiler with new variants for a data type, I get less help from the compiler than I should otherwise.
Next, of course, I had to add the case for dtors in the monomorphizing code in trans, since (as its name suggests) the class/resource in resource-generic is generic. And then there was another alt check failure in the very same function. I'd love to expunge alt check from the language (though, of course, that would be subject to our usual consensus-based process). Maybe not everybody's blood pressure rises when they see a "nonexhaustive match failure" error instead of a domain-specific error message, but mine does.
Then I got an internal compiler error because I passed none instead of the actual type substs to trans_fn from trans_class_dtor. It only showed up this time because this is the first example with a generic class w/ a dtor, naturally.
Today
Now, there's an invalid GEP value in trans_rec_field_inner -- I think I might be passing the ValueRef for the dtor instead of for the class itself somewhere? But it's bug triage day. Triaged a bunch of bugs. Fixed a bunch of FIXMEs, and spammed the bug database with reports for 11 of them that I couldn't fix easily. There was some happy refactoring in there somewhere, plus the pleasure of finding a comment that says "fix this when we start supporting [blah]", realizing [blah] is now supported, updating it to use [blah], and having it just work. (In this case, passing C-style enums -- that is, algebraic data types where all the constructors are nullary -- to native C functions.)I've been sick this entire week so far, and while I only took a half-day off, I haven't felt like I've been operating at 100%, or even 60%, really. Plus, I'm in-between one four-day-weekend trip and one week-long vacation, so it's really a bad time for me to be out of it, since vacations always disrupt work. I guess that's the point of vacations. I guess, also, the one good thing about being sick is that today I worked from home all day (given that the uncontrollable coughing might worry my co-workers) and it reminded me of how much I hate working in isolation. Which, in turn, tells me I made a good decision by choosing to move to San Jose at the end of this month, so I can work from the Mountain View office (where most of the Rust team works from) every day.
Even though this may not have been a very productive week, I did learn about gdb --args, and so it wasn't a total loss.
Times when I have to remember extra hard to redact my debug statements before checking in code: when I'm feeling inarticulate and just use #debug("meow") to denote which alt pattern matched.