-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macros: stackless expansion #36214
macros: stackless expansion #36214
Conversation
6497f39
to
d0695b0
Compare
Hmm, this doesn't seem to be working. I tried it on my most-recursing macro, brainmunch. Having built master and this branch:
This branch is first, then master. I would have expected a more impressive time difference and a smaller memory footprint if the expansion is really stackless. Furthermore, I removed |
@durka If you don't get a stack overflow with a high recursion limit before this PR, then there's not much to see. |
@durka This PR doesn't change It would probably be a good idea to raise the default recursion limit or even remove it altogether, but that's for a separate PR. Note that if we remove the recursion limit altogether, I think we should limit the total memory usage or total number of expansions so that if there really is unbounded recursion, the user will still get a nice error message (not a hang or an out of memory error). I'd be happy to help if you want to do this. To test this branch, you can set the recursion limit to something that can't be reached in a reasonable amount of time and space, like This PR doesn't improve performance (I actually measured ~5% regression, but that will be made up by a later PR) nor does it improve memory usage -- after this PR, the heap will have all the information that used to be on the stack and more. |
Ah I see, I got too excited. |
Further investigation: I lengthened the test case to stack overflow on master after 1m27s, and it finished compiling on this branch after 5 minutes. Intentionally lowering the recursion limit produces comparable time-to-error for both branches. |
☔ The latest upstream changes (presumably #35957) made this pull request unmergeable. Please resolve the merge conflicts. |
a9fa986
to
99c896f
Compare
syntax_pos::DUMMY_SP => PathBuf::new(), | ||
_ => PathBuf::from(fld.cx.parse_sess.codemap().span_to_filename(inner)), | ||
}; | ||
fld.cx.directory.pop(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem right - in the dummy span case you're popping an empty PathBuf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
☔ The latest upstream changes (presumably #36240) made this pull request unmergeable. Please resolve the merge conflicts. |
…ack` with a single field `directory: PathBuf`.
r=me with that boilerplate factored away |
@bors r=nrc |
📌 Commit 400a4f2 has been approved by |
💔 Test failed - auto-win-msvc-64-cargotest |
3f9b910
to
dc01d96
Compare
@bors r=nrc |
📌 Commit dc01d96 has been approved by |
dc01d96
to
323ee43
Compare
323ee43
to
9ac91fa
Compare
@bors r=nrc |
📌 Commit 9ac91fa has been approved by |
@DanielJCampbell This refactoring might help with expansion visualization / stepwise expansion -- feel free to ping me on IRC if you'd like to discuss. |
Yeah, I will do that - I have a working solution but it's based on Rust from 6 weeks ago, looks like plenty has changed since then. |
After this PR, macro expansion cannot overflow the stack unless the expanded crate is too deep to fold.
Everything but the stackless placeholder expansion commit is also groundwork for macro modularization.
cc #35896
r? @nrc or @eddyb