The possibility for a library writer to write his own compiler plugins is an awesome feature. It’s already used by a lot of libraries, notably
gl-rs (which by the way may dive straight in AST), etc.
However the public API that plugins are using is very… dirty, to say the least, and doesn’t seem to be a blocker for 1.0.
This leads me to a few questions:
Is it possible to make changes in the Rust language in a backward-compatible way while being sure not to break existing plugins? Let’s say that post-1.0 you want to add a new language construct in Rust in a backward-compatible way. As far as I know, doing so will modify the AST structs that plugins are supposed to generate, which means that technically it would not really be possible to modify the language in a backward-compatible way at all.
Let’s say that you make breaking changes in the plugins API in Rust 1.0. Does this justify the release of Rust 2.0 instead of 1.1?
Right now (pre-1.0), does modifying the plugins API require an RFC? @eddyb suggested that the
syntax::ext::build::AstBuildertrait should be totally removed, and that only
quote_*!macros should be used, which I think is a good idea and would solve question #1. However quotes macros would need to be extended because there are several things not possible right now with them. Do these changes require an RFC?
The situation of plugins is a bit ambiguous, and I think that it wouldn’t harm if it was clarified.