Compiler Plugin Info for Talk


#1

Hi All!

This is a cross-post from internals (I think internals might not have been the most appropriate place to post).

I’ve spent a fair amount of time writing compiler plugins and using libsyntax directly (haven’t been using aster much because it’s prone to breaking, but will run through it) for a bunch of codegen scenarios and am working on a talk for the Brisbane Meetup on Rust codegen in general. I’ll also dig through syntex, which serde uses for codegen on the stable channel.

I know the compiler APIs are in motion, so I’m not sure how worthwhile it is getting too bogged down in details, but any sources I could dig through (like this PR) to help get a sense of where compiler plugins are heading would be really helpful!


#2

While not directly related I just wanted to say that I used syntex for generating serializing code (as part of serde as you write) but in the end I decided to actually remove it because it adds quite a bit of extra time (~1 min maybe) which is a bit annoying when you have a project that builds in ~50 sec from clean.

So while annoying to do manual serializing code to me it’s worth it (for now at least)


#3

Yeh, that’s true. I don’t think it’s difficult to implement Serialize or Deserialize manually, and you get more control, but need to make sure all possible serialised values can be properly deserialised yourself and that changes to your structure are also made to the serialisation.

The main issue I have with aster (and syntex) in practice is that it has a broad surface to cover, which means any small change to libsyntax tanks them completely. But since I only use a small subset of libsyntax my stuff rarely breaks.

I’d heard (second-hand) Mads Torgersen (one of the guys heading Microsoft’s Roslyn compiler platform) comment that it’ll be a long time before Rust’s compiler APIs could be stabilised based on the amount of work they did for Roslyn, so I think we’ll be wearing the costs of instability for a while yet :slight_smile:


#4

I think most of the attention has been on getting a stable form of procedural macros, rather than further improvements to the current system (which can’t be stabilized, because it exposes compiler internals). Nick Cameron (@nrc) has been the one driving this, his blog has a bunch of relevant posts and he’s opened several RFCs related to the subject.

However, this system will probably not be accepted, implemented, and stable before next year, so it may not be super relevant to your talk.


#5

Thanks @withoutboats! Looks like I’ve got some weekend reading ahead of me.