Skip to content

Commit 665feb4

Browse files
committed
New RFC: proc-macro-attribute-recursion
1 parent 4140615 commit 665feb4

File tree

1 file changed

+80
-0
lines changed

1 file changed

+80
-0
lines changed
Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
- Feature Name: proc_macro_attribute_recursion
2+
- Start Date: 24.01.2019
3+
- RFC PR: (leave this empty)
4+
- Rust Issue: (leave this empty)
5+
6+
# Summary
7+
[summary]: #summary
8+
9+
Expand `proc_macro_attributes` recursively.
10+
11+
# Motivation
12+
[motivation]: #motivation
13+
14+
Currently, procedural macros have no way to expand macros at all. [RFC #2320](https://github.com/rust-lang/rfcs/pull/2320) aims to rectify this, but despite being reworked a lot still suffers from some complexity.
15+
16+
This proc_macro author wants something workable now instead of waiting for that RFC while leaving the doors open for an eventual implementation. Also making this small part available allows us to collect experience with macro expansion in proc_macros at very modest cost.
17+
18+
# Guide-level explanation
19+
[guide-level-explanation]: #guide-level-explanation
20+
21+
`proc_macro_attributes` can add other attributes in their output. The expander then expands all macros in the proc_macro output, and then checks again for any attributes, expanding them, too (possibly recursively):
22+
23+
Here's an example from [flamer](https://crates.io/crates/flamer):
24+
25+
```rust
26+
use flamer::flame;
27+
28+
macro_rules! macro_fun {
29+
() => {
30+
fn this_is_fun(x: u64) -> u64 {
31+
x + 1
32+
}
33+
}
34+
}
35+
36+
#[flame]
37+
mod fun {
38+
macro_fun!();
39+
}
40+
```
41+
42+
Flamer expands the `macro_fun!();` to `#[flame] macro_fun!();`. The expander then expands `macro_fun!()` yielding
43+
44+
```rust
45+
mod fun {
46+
#[flame]
47+
fn this_is_fun(x: u64) -> u64 {
48+
x + 1
49+
}
50+
}
51+
```
52+
53+
Because of the `#[flame]` attribute, this is fed back to flamer, which modifies the function resulting from the macro. Note that as in this example, the attribute needs not be placed at the same AST node (and in fact, flamer would place it only on macro invocation nodes).
54+
55+
`proc_macro` writers can implement their macros in terms of `proc_macro_attributes` (which is a very roundabout way to deal with macros, but at least it would work at all) to gain the same benefits.
56+
57+
This way, `proc_macro_attribute`s can be deemed *recursive* like macros-by-example. Note that the macro recursion limit must also be observed by the `proc_macro_attribute` implementations.
58+
59+
# Reference-level explanation
60+
[reference-level-explanation]: #reference-level-explanation
61+
62+
The expander is extended to search the expansion of `proc_macro` and `proc_macro_attributes` for other macro invocations. Those are then expanded until there are no more attributes or macro invocations left or the macro expansion limit is reached, whichever comes first.
63+
64+
Implementors will have to make sure to order the expansions within expanded output by their origin: macros which are in the `proc_macro_attribute`s' input need to be expanded before expanding macros that have been added by the `proc_macro_attribute`s themselves. This can easily be done by examining the `Span`s of the expansion and ordering them by `SyntaxContext`.
65+
66+
# Drawbacks
67+
[drawbacks]: #drawbacks
68+
69+
No drawbacks have been found so far.
70+
71+
# Rationale and alternatives
72+
[alternatives]: #alternatives
73+
74+
* leave things as they are, but this leaves proc_macro authors in the cold if they want to deal with macros in invocations
75+
* [RFC #2320](https://github.com/rust-lang/rfcs/pull/2320) has a more general solution but tackles more complexity. Note that this RFC is a part of #2320 broken out, so we can still implement the rest of it afterwards
76+
77+
# Unresolved questions
78+
[unresolved]: #unresolved-questions
79+
80+
None

0 commit comments

Comments
 (0)