Adds a ProcMacro form of syntax extension
#36154
Conversation
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
This is the call site span of the macro invocation that expanded into the TokResult, right?
|
☔ The latest upstream changes (presumably #35957) made this pull request unmergeable. Please resolve the merge conflicts. |
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC rust-lang#1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too. Supports both attribute-like and function-like macros.
nrc
force-pushed
the
proc-macro-init
branch
from
56405da to
973eae2
Compare
|
@jseyfried r? I think I addressed all your earlier comments |
src/libsyntax/ext/expand.rs
Outdated
There was a problem hiding this comment.
This match could be the trailing expression statement if each arm had type Expansion.
src/libsyntax/ext/expand.rs
Outdated
There was a problem hiding this comment.
e.g. this could be Some(items) => Expansion::Item(items),
src/libsyntax/parse/lexer/mod.rs
Outdated
src/libsyntax/parse/lexer/mod.rs
Outdated
There was a problem hiding this comment.
I believe this method is unused.
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
I believe this is unused.
src/librustc_plugin/registry.rs
Outdated
There was a problem hiding this comment.
These four lines could just be _ => extension, (unless the explicitness is intentional, that is).
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
Since this arm always returns, macros will only be able to expand into one impl item (same with trait items) -- not sure if this is intentional.
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
parse_item() will return None if the next token does not begin an item. For example, if a procedural macro returned + in an item position, it would silently expand into nothing here.
ext::tt::macro_rules::ParserAnyMacro solves this problem with ensure_complete_parse.
In general, I think it would be a good idea to follow the semantics of ParserAnyMacro more closely or even merge ParserAnyMacro and TokResult (moving the ChangeSpan fold into expand.rs), at least until we clean up the semantics of the parser.parse_* methods used here.
src/libsyntax/ext/base.rs
Outdated
There was a problem hiding this comment.
Something like ensure_complete_parse is also needed here so that valid[expression] } followed by arbitrary tokens is not allowed (c.f. my comment about ParserAnyMacro).
src/libsyntax/ext/expand.rs
Outdated
There was a problem hiding this comment.
It might be a good idea to change the spans here instead of in each method of TokResult -- e.g. kind.make_from(result).fold_with(&mut ChangeSpan { span: span }).
nrc
force-pushed
the
proc-macro-init
branch
from
973eae2 to
d956d7e
Compare
|
@jseyfried changes made |
src/libsyntax/ext/expand.rs
Outdated
There was a problem hiding this comment.
One last simplification that I didn't notice earlier -- I believe this whole match can be replaced with:
kind.make_from(result).unwrap_or_else(|| {
let msg = format!("macro could not be expanded into {} position", kind.name());
self.cx.span_err(&msg);
kind.dummy(attr.span)
})There was a problem hiding this comment.
ah nice, I was hoping there was a way to get rid of this whole match
|
@nrc r=me with that last simplification. |
nrc
force-pushed
the
proc-macro-init
branch
from
d956d7e to
3863834
Compare
|
@bors: r=@jseyfried |
|
📌 Commit 3863834 has been approved by |
Adds a `ProcMacro` form of syntax extension This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too. Supports both attribute-like and function-like macros. Note that RFC #1566 has not been accepted yet, but I think there is consensus that we want to head in vaguely that direction and so this PR will be useful in any case. It is also fairly easy to undo and does not break any existing programs. This is related to #35957 in that I hope it can be used in the implementation of macros 1.1, however, there is no direct overlap and is more of a complement than a competing proposal. There is still a fair bit of work to do before the two can be combined. r? @jseyfried cc @alexcrichton, @cgswords, @eddyb, @aturon
3 participants
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Note that RFC #1566 has not been accepted yet, but I think there is consensus that we want to head in vaguely that direction and so this PR will be useful in any case. It is also fairly easy to undo and does not break any existing programs.
This is related to #35957 in that I hope it can be used in the implementation of macros 1.1, however, there is no direct overlap and is more of a complement than a competing proposal. There is still a fair bit of work to do before the two can be combined.
r? @jseyfried
cc @alexcrichton, @cgswords, @eddyb, @aturon