tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
[personal profile] tim
For Rust 0.5, which was released two weeks ago, we had a meeting a couple of months ago to set priorities. I can't find the wiki page that resulted from that meeting (I did find a note consisting of our suggested candidate goals, not the list of goals we actually came up with). But I do remember the two issues in the issue tracker that were supposed to be my priorities: pattern reform and labeled break and continue.

Back in November (or something), I decided that the best way to address pattern reform would be to make `let` and `match` share the same codegen path. I thought this would be easy, but it wasn't. Over a month later, I was still working on it. I gave up in frustration when we were getting close to the 0.5 release and I decided to work on blockers instead. So that meant I didn't finish pattern reform.

I sort of finished labeled break and continue, but there's still a bug open on labeled break not working from inside a `for` loop. I don't consider this a huge failure on my part. We implemented labeled break and continue for a very specific reason, which doesn't seem to require labeled break from inside a `for` anyway. From a "no arbitrary restrictions" language-design point of view, it would be good if it worked, but I don't see it as urgent. (The reason why it's hard is that Rust effectively implements `for` loops by desugaring into a call to a higher-order function. So a `break` out of a `for` loop actually jumps to a different stack frame -- hence, involves a `return` -- as opposed to a `break` out of a `while` or `loop` (infinite loop), which is really just a `goto`. The back-end has special cases to handle the unlabeled-`break` case, but I didn't understand the code well enough to extend it to labeled `break`s.) (Also, don't take the word "desugaring" there too literally, since the Rust compiler -- surprisingly for me as an ex-GHC-hacker -- preserves the AST in almost the same shape all the way down to codegen, keeping many higher-level constructs intact.)

Going back to pattern reform, one of the things that was hard about the refactoring I was doing was the need to account for where "cleanups" get introduced. At least right now, Rust uses a combination of automatic reference counting, and "owned" and "borrowed" pointers that don't require reference counting, to manage memory. There is a GC, but it's a last resort. So the codegen has a lot of very fiddly code that inserts "cleanups" that free up memory when the refcount of a shared pointer goes to zero or when an owned pointer's lifetime ends. If you get this code wrong, you get memory leaks, dangling pointers, or both, as I discovered many times. The codegen pass contains any number of undocumented invariants about where the cleanups have to go and when it's safe to cancel them or leave them out. Every time I thought I understood how it worked, I would discover one more case where I didn't understand. There's been some talk of getting rid of reference counting, but in the meantime I'm kind of disappointed in myself that I wasn't more aggressive about pursuing answers (either by reading code or trying to ask questions of the people who wrote it).

I've been wanting to spend some of my time extensively documenting trans (and the rest of the Rust compiler), but that's hard to do without understanding the code in the first place! Lack of documentation shuts out new contributors, especially new contributors who don't feel socially comfortable just jumping into IRC and asking questions. If *I* often feel uncomfortable asking questions about code, as someone who's been working on the Rust project for almost two years and knows everyone else on the core team, what would it be like for an outsider, especially one who isn't a middle-class white English-speaking guy like most of us on the core team?

So that's a summary of my last few months. For the new year, at least as of yet, my calendar seems to be wide open!
Anonymous( )Anonymous This account has disabled anonymous posting.
OpenID( )OpenID You can comment on this post while signed in with an account from many other sites, once you have confirmed your email address. Sign in using OpenID.
User (will be screened if not on Access List)
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.


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

April 2017

23456 78
910 1112131415

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags