Aanyway, amidst all the arguing about whether macros are good, can I bring up a point?
Compiler must have good error recovery support. Rust currently does not fare that well.
IDEA keeps a lot of indexes and updates them automatically when dependencies change - it's something akin to perfect incremental compilation (except that IDEA doesn't do codegen). Rust has to parse everything every time.
Compiler plugins must be FAST. IDEA parses code immediately as you type it, so anything slower than 100-200ms is unacceptable.
All of these would obviously be extremely useful features for rustc. If you're implementing a fully incremental Rust frontend in Java, that's great work, but why not write it in Rust instead, with the intent of eventually integrating it into rustc? Then IDEA could eventually simply use APIs provided by librustc, without having to reimplement complex language features like macros, while preserving the performance that is expected of it. I'm sure this is easier said than done, but it would sure be nice to be able to take advantage of the same performance and ergonomics both when compiling on the command line and inside more loosely coupled editors, like vim.
edit: I see that IDEA has some scaffolding for this sort of task, but I don't think it would be that hard to implement an API strongly inspired by it in Rust ;p
Incremental compilation IDEA-style requires a lot of indexes that are updated in-step with the code. It becomes tricky to do it if you don’t have some kind of persistent daemon running all the time.
I’ve explored integration of rustc frontend into IDEA, but it’s probably not possible. Java Native Interface is just too ill-suited for that kind of thing.
Reimplementing the IDEA-inspired API in Rust is an interesting task and it will benefit other IDEs and various integrations with editors (that’s what Racer does really well already). But it’s another project entirely and has its own benefits and drawbacks.
My sincere apologies. I meant to offer cautionary guidance about a direction that I thought would be unproductive.
I do believe that Rust and people who use it would be better served by improving the performance of the rustc front-end, and having all IDEs use that front-end for their language services, instead of having every IDE re-implement the front-end of the language.
In Microsoft’s Visual Studio, the language services (“Intellisense”) used to be completely separate re-implementations of the language. This caused a great deal of inefficiency and inconsistency. They are finally fixing that (for C#) by converging on a single language front-end, called “Roslyn”, which both the compiler and the IDE use.
I would prefer to see Rust / IntelliJ avoid this same mistake. If the IDE is built on the same language front-end as rustc itself, then most changes to the language will be immediately accessible to IntelliJ (and any other IDE built in the same way). I think this is preferable to re-implementing the same thing, many times over.
Apparently my previous post was eaten. I just wanted to say I agree
with these sentiments and I think that rearchitecting rustc to better
support these sorts of use cases will be a priority post 1.0, though
it’s a long road.
The 1.0 release is about stabilising the language syntax and semantic and also the core standard library (not the core library). Macros especially programmatically ones will not be stabilized at this point but later (or so I think).
In this topic there is some vague talk about a frontend AST (and a compiler AST) and a rust specific trans IR. I thing having something like that would greatly help with advanced IDE features.
The AST could be used to crate a interface for IDEs* and the IR for a incremental compilation giving fast feedback for anything not checked by the IDE+AST interface.
*note that this is not that simple because the AST does not include everything e.g. no lifetime checks. Btw. such frontend AST also helps in stabilising programmatically macros.
Nerveless, regarding the the security concerns most big projects have custom build scripts, complicated makefiles and other code witch can do “anything ” when building the software.
Additionally I thing there should be some restrictions to syntax extension code, at last for this witch is used for programmatically macros. (maybe partially disableable by compiler parameters).
E.g. when having a frontend AST there should be no reason to define any unsafe blocks and use of non ”basic” libraries like IO might have to be explicitly enabled.
Also I thing that in the end a macro (independent of it’s kind) should never be able to change the AST outside of it’s somemacroname!(somebody) block because that would not only be confiding but also (from my point) unreasonable.
Btw. a good use case of a possible non made syntax extension for rust would be a OpenMP integration so dropping the support for syntax extensions is generally a bad idea.
EDIT:
I think that many thinks noted here (especially the later ones) have a low priority for now and for immediate post 1.0 development. So it’s more of a vague long term view.