The translation-to-LLVM pass in rustc, affectionately known as 'trans', has grown to over 9000 lines and is overdue for a refactor. A few days ago, I volunteered to take this on, and we've been discussing how and when to go about it.
It's been suggested that we start by splitting trans into two pieces. The first would be, more or less, all the trans_X() functions where 'X' is recognizably something in the AST, and the second would be everything else: support functions, glue, LLVM type constructors, and such. Eventually, the second piece could be split further, if we want. Marijn has pointed out that when we do this, we'll encounter a lot of repeated code in the first piece that could be abstracted out into common utility stuff that can go into the second. That's one reason why we're doing this: to make opportunities for that kind of abstraction more obvious. Right now, it's hard to see them because trans is so big. Eventually, I could see the second piece evolving into the "LLVM combinator library" that we've often wished we had. It's also been suggested that it would be be nice to come up with a better abstraction for block contexts and other kinds of contexts that right now have to be threaded through most of the functions in trans. I'm open to suggestions for what to do about that. I think that sums up the current thinking on 'how'. Comments, questions, concerns? As for the 'when' part, since a lot of people work on trans, we'll need to pick a flag day by which work-in-progress should be in. Suggestions? Lindsey _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
