Uh oh!
There was an error while loading. Please reload this page.
Adds a ProcMacro form of syntax extension - #36154
Conversation
There was a problem hiding this comment.
This is the call site span of the macro invocation that expanded into the TokResult, right?
bors
commented
Sep 3, 2016
☔ 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
commented
Sep 21, 2016
@jseyfried r? I think I addressed all your earlier comments |
There was a problem hiding this comment.
This match could be the trailing expression statement if each arm had type Expansion.
There was a problem hiding this comment.
e.g. this could be Some(items) => Expansion::Item(items),
There was a problem hiding this comment.
I believe this method is unused.
There was a problem hiding this comment.
These four lines could just be _ => extension, (unless the explicitness is intentional, that is).
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.
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.
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).
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
commented
Sep 22, 2016
@jseyfried changes made |
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
jseyfried
commented
Sep 22, 2016
@nrc r=me with that last simplification. |
nrc
commented
Sep 22, 2016
@bors: r=@jseyfried |
bors
commented
Sep 22, 2016
📌 Commit 3863834 has been approved by |
bors
commented
Sep 22, 2016
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
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