TMI: It's always in the last place you look

[tim]

I keep putting off this dependency graph project. I thought that faster compile times (and less mental context-switching for me) would be enough motivation, but I guess not; I keep wanting to bite off smaller chunks of work to deal with. Smaller chunks seems safer.

I finished fixing #3099 today, which was because the name resolution pass wasn't checking for multiple items with the same name. So you could declare two functions in the same scope, both called a, and one of them would just be silently ignored. That's not good, so I fixed resolve to error out in that case. This was only non-straightforward because we have several different namespaces (modules, types, values, and implementations) and you can re-declare the same name in a different namespace, just not in the same one (which is what "namespace" usually means). So I had to make sure not to error out when the names were in different namespaces, but otherwise, the machinery was already all there to fix this. Also, I was in the pleasant situation of already having done most of the work for this last week, and the first time I tried running the tests today was the first time it actually worked. That's always nice.

I wanted to pick off my bugs that were milestoned 0.4 (though our policy for assigning milestones to bugs is... a bit ad hoc) and so I fixed #2825, which was dead easy. It's still a little weird to me that we check for multiple or no constructors in the parser (mind you, it was my idea), but this code is probably going away soon anyway in favor of max/min classes soon anyway.

I also worked on #2935, after an entreaty from Paul, and I think I have a fix. This was a bug where the most obvious answer was really the right one: we weren't auto-dereferencing at all on trait method calls, and probably never were. But before I could notice that, I had to go through all the non-obvious possibilities first. (I may be wrong about this -- the answer is pending running tests.) To explain a little bit more, suppose you write:

type t = {a: int};

/* ... */
let x: @t = {a: 5};
log(error, x.a);
log(error, (*x).a);

The first log expression is syntactic sugar for the second one: on certain kinds of field accesses, the compiler effectively "auto-dereferences" x. Method calls are field accesses too, syntactically, so the same thing should happen; but the code generator wasn't doing that for trait method calls, so there was a mismatch between the caller's and callee's expectations that ended, predictably, in a segfault.

Still not working on #2936, and I only broke the build once today, so clearly I should be working harder. :P