What types of Macros/Syntax Extensions/Compiler Plugins are there?
I am very confused by the many terms used for several macro-like things in the Rust ecosystem. Could someone clarify what macros/syntax extensions/compiler plugins there are as well as explain the relationship between those terms?
You are right: it is confusing. Especially, because most of those features are unstable and change fairly often. But I'll try to summarize the current situation (December 2016).
Let's start with the Syntax Extension: it's something that has to be "called" or annotated manually in order to have any effect. There are three kinds of syntax extensions, which differ in the way you annotate them:
function-like syntax extensions: these are probably the most common syntax extensions, also called "macros". The syntax for invoking them is
foo!(…)or (and this is pretty rare)foo! some_ident (…), wherefoois the macro's name. Note that the()parenthesis can be replaced by[]or{}. Function-like syntax extensions can be defined either as a "macro by example" or as a "procedural macro".attribute-like syntax extensions: these are invoked like
#[foo(…)]where the parenthesis are not necessary and, again,foois the name of the syntax extension. The item the attribute is belonging to can then be modified or extended by additional items (decorator).custom derives: most Rust-programmers have already used the
#[derive(…)]attribute. Of course,deriveitself can be seen as attribute-like syntax extension. But it can also be extended, which is then invoked like#[derive(Foo)], whereFoois the name of the custom derive.
Most of these syntax extensions are also "compiler plugins". The only exception are function-like syntax extensions which are defined via "macro by example" (meaning macro_rules! syntax). Macros by example can be defined in your source code without writing a compiler plugin whatsoever.
But there are also compiler plugins that aren't syntax extensions. Those types of compiler plugins are linters or other plugins which run some code at some stage of the compiling process. They don't need to be invoked manually: once loaded, the compiler will call them at certain points during compilation.
All compiler plugins need to be loaded – either via #![plugin(foo)] at the crate-root or with the -Zextra-plugins=too,bar command line parameter – before they can have any effect!
Compiler plugins are currently unstable, therefore you need a nightly-compiler to use them. But the "Macro 1.1"-RFC will probably be stabilized soon, which means that a small subsets of compiler plugins can then be used with the stable compiler.
Useful links:
- Defining and blanket implementing a common trait to avoid dependencies in Rust
- Migrating from BASIC to Rust, what do I do with On Gosub?
- Batch-update adjacent elements in a Vec in Rust (for performance)
- Diagonal matrix from vector
- How to define a const closure inside a generic struct
- Circular Reference Construction in Rust
- Failed to select a version for the requirement `rand = "^0.9.0"`
- Is Mutex/Lock required if runing on a single core CPU
- How do I choose a random value from an enum?
- Use a different cargo profile for CI
- How can I debug why a dependency is in my Cargo.lock?
- Use `write!` without bringing the Write trait into scope in Rust
- Polars Rust API creating a dataframe from a string variable / reading csv with options from a string
- expected associated type, found type parameter
- Format specifier for truncating string-like types
- Matching enum variant without specifying variants in Rust macro
- How do you create a column of a vector/list type in Polars using Rust
- How to create a Rust struct with string members?
- Schedule wakeup with WinAPI in Rust
- Projection matrix causes vertical offset
- Iterate over a generic iterable without having to clone
- Unauthorized access. 'Listen' claim(s) are required - Azure function using RUST (event hub)
- Rust: double linked list
- Is there a nicer way to implement Display for structs that own collections of things with Display?
- Swift catch with case let
- Why does Rust consider an owning closure to exist for 'static lifetime?
- Error: "linker 'cc' not found" when cross compiling a rust project from windows to linux using cargo
- Why am I getting "App state is not configured" in Ntex despite using App::state()?
- How do I inspect local variables or use the watch window with Rust code using VSCode and LLDB?
- How to share a HashMap state amongst Yew Rust components?