tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (working)
[personal profile] tim
I have not been writing this week, obviously, because I've been mired in a maze of twisty little issues, all different, and haven't felt I've had anything interesting to say about them. That is absurd, of course, because my entire goal in this blog is to write everything about everything I do, whether it's interesting or not! But that goal can still get a bit intimidating.

Also, it's seemed that the chances of pulling something from our incoming branch that actually builds are getting monotonically lower; plus the 0.3 release, which happened today (yay!) meant that the tree was closed and some things couldn't be fixed immediately. (Don't worry, folks-who-just-want-to-use-Rust who are reading this -- you can always download either the shiny new release, or the master branch on git, and know you'll have something that will build. If your platform is supported. Most likely.)

Anyway, if I can get a build to work, I'm going to check in a fix for issue 2804, which was a lot of fun. First because it was satisfying for me to reduce a rather large test case down to five lines that showed off the same bug. Second because the source of the error ended up being a nasty hack that I'd already noticed was something that should probably go away. The hack had to do with node IDs. Because we never rebuild the AST in rustc once the parser constructs it for a particular crate, every AST node has a unique ID. Well, supposedly unique. The IDs are keys into various hash tables that get passed from pass to pass, transmitting various additional semantic information about the crate. For certain kinds of expressions that may be applications of overloaded operators (so, things like a + b and in this case, c[d] -- because you can overload the indexing brackets), the parser was allocating an extra node ID, to be used for storing extra typechecking information. There was an invariant that this extra ID, the "callee id", was always x - 1 if a particular node had node ID x. But not all code was respecting this invariant, as it's not an invariant the compiler could check. In this case, the macro expansion code was allocating new node IDs for arguments in an expanded expression without bothering to check whether it needed to allocate a callee ID as well.

Once I realized the problem the fix was easy (if a bit tedious): change all expressions to have a callee_id field. Before, expressions looked a bit like:

type expr = {id: int, s: span, node: expr_}

where expr_ is the data type that actually defines expressions. The id field has the node ID, and the s field contains the source line and column number (for error message printing).

I changed it to:

type expr = {id: int, callee_id: int, s: span, node: expr_}

and now the callee_id is just there, instead of being computed from the ID. Of course, I had to change all the code that constructs an expr, but that's a good thing! Now, the compiler does more work for us and there's less for us to think about, which is the point, after all.

I appear to have a working build (something I haven't had in over a day, which is a long time in my world), so off to check it in.


tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
Tim Chevalier

October 2017

8910 11121314
15 161718192021

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags