Extended expand.rs to support alternate expansion behaviours (eg. stepwise expansion) #34811
Conversation
|
r? @nrc |
| @@ -43,6 +44,9 @@ trait MacroGenerable: Sized { | |||
| fn fold_with<F: Folder>(self, folder: &mut F) -> Self; | |||
| fn visit_with<V: Visitor>(&self, visitor: &mut V); | |||
|
|
|||
| // Recursively expand this node/list of nodes using the appropriate closure in the Expander. | |||
There was a problem hiding this comment.
Could you explain precisely when the closure is called.
DanielJCampbell
force-pushed
the
Expander
branch
from
07b3ac3 to
866da14
Compare
|
Updated with the suggested changes - definitely looks tidier with the macros gone. |
|
@bors: r+ |
|
📌 Commit 866da14 has been approved by |
|
⌛ Testing commit 866da14 with merge 68303be... |
|
@bors: retry force clean
|
|
@DanielJCampbell I ask because I'm not sure how this will interact with macro modularization, which we're planning on prototyping in the next couple of weeks. |
|
@jseyfried, @nrc |
|
@bors: r- |
|
@danc: I was discussing with @jseyfried on irc. He suggested a simpler approach would be to add a Separately, there seems to be a limitation with either approach which is that after the first round of expansion, the expander will no longer be able to name macros which are in any module other than the crate root. This is because of the way the expander tracks modularisation of modules. I think we just live with that. It should fix itself once we re-jig macro name resolution. We can talk more on irc on Monday. |
|
☔ The latest upstream changes (presumably #34860) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@bors r-`` |
|
@bors r=nrc |
|
📌 Commit 866da14 has been approved by |
|
@bors r- |
|
💥 Test timed out |
|
Unfortunately this now looks like it has some rebase conflicts, @DanielJCampbell could you rebase so we can re-r+? |
DanielJCampbell
force-pushed
the
Expander
branch
from
866da14 to
d4358af
Compare
DanielJCampbell
force-pushed
the
Expander
branch
from
157b5fc to
f112589
Compare
| krate); | ||
| let ret = syntax::ext::expand::expand_crate(&mut ecx, | ||
| syntax_exts, | ||
| krate); |
There was a problem hiding this comment.
nit: these arguments can be on one line.
DanielJCampbell
force-pushed
the
Expander
branch
from
f112589 to
d3c426b
Compare
|
Fixed nits |
| c.module.items = items.into(); | ||
| for (name, extension) in user_exts { | ||
| expander.cx.syntax_env.insert(name, extension); | ||
| } |
There was a problem hiding this comment.
One last thing -- user-defined extensions should be inserted before calling expander.load_macros(&items) so that macros imported from extern crates continue to shadow user-defined extensions (#[plugin]s). Otherwise, we might break code for no good reason.
There was a problem hiding this comment.
Ok, I'll also add a comment to that effect, since that seems worth a warning.
DanielJCampbell
force-pushed
the
Expander
branch
from
d3c426b to
035e8c5
Compare
|
@DanielJCampbell looks good! Could you squash the two commits? @nrc r=me unless you have other comments. |
|
lgtm |
DanielJCampbell
force-pushed
the
Expander
branch
from
035e8c5 to
2fefe00
Compare
|
Squashed the commits together. |
|
@bors r+ |
|
📌 Commit 2fefe00 has been approved by |
Extended expand.rs to support alternate expansion behaviours (eg. stepwise expansion) r? nrc
|
💔 Test failed - auto-win-msvc-64-opt-rustbuild |
|
Looks like I missed the tests, I'll fix that up shortly. |
DanielJCampbell
force-pushed
the
Expander
branch
from
2fefe00 to
1ec88d6
Compare
Added single_step & keep_macs flags and functionality to expander
DanielJCampbell
force-pushed
the
Expander
branch
from
1ec88d6 to
61c7569
Compare
|
@bors r+ |
|
📌 Commit 61c7569 has been approved by |
Extended expand.rs to support alternate expansion behaviours (eg. stepwise expansion) r? nrc
r? nrc