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.
