-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Do not remove closures during ReplaceBodyWithLoop
pass
#72088
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
What happens if I have code like the following: fn foo() {
let x = |()| {};
} I think the closure still gets removed because it's in a |
Yes the closure would probably gets removed, but i guess its the intended behavior of the simplification pass? The problem in my case is a closure with an exported macro inside. I tried various other code layout (useless blocks, nested closures, etc) but was not able to reproduce the bug when applying this change. I think the real question is whether or not this simplification pass is needed at all? It looks like a weird hack and can imagine a lot of different bugs due to it. |
So i just tested your example with a macro inside, and indeed, you are right, i can reproduce the bug.
Sorry, I am not sure i fully understand why you mean. Could you explain a bit more? Or maybe provide pseudo-code / example? |
My point is that this won't fix #71820 if you have the following, since you're not looking at all places an expression could appear in a fn foo() {
let x = |()| {
#[macro_export] macro_rules! foo {}
};
} Yeah, so I would add an |
I can't speak to how rustdoc is using this. Perhaps someone else knows? I'd be surprised if leaving in closures caused anything to break, so I think this approach is fine. That said, you should mention why you're doing this in a comment, since this is very subtle. edit: Now that I think of it, there are probably more expressions that will introduce a new |
Just tried it, and yes, the bug also happens with async block. Basically, any AST node that can contain a macro and that is going to get removed (ie: not an |
So basically we need to make the AST visitor more robust. Specifically, it should only remove AST nodes that contain no nested items. Does this seem feasible? Unfortunately, |
282f47d
to
f2de13e
Compare
I've improved the implem based on your feedbacks @ecstatic-morse ! Thanks a lot. |
f2de13e
to
1941a43
Compare
I'm good with that. I'll take another look when CI is green. |
I'm still not sure why this issue happened only with macros but not other items. |
@petrochenkov I have very little intuition for how |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
@petrochenkov @ecstatic-morse My understanding is that the bug is triggered because we try to access the |
So keeping the closures, even in the
First Another idea i had, was to monkey patch the parent |
@marmeladema This is what I was hinting at with the comment above. The AST visitor approach will only work if you remove all expressions that don't have nested items. Currently, the AST visitor is only handling block expressions, which means you're missing stuff like the single-expression closure above. Monkey patching |
@marmeladema Ping from triage. The CI failure needs to be fixed. |
@crlf0710 its broken but i don't know what is the best way to fix yet. Should I move the PR to draft for the time being? |
@marmeladema Do you mind if I take this over? |
Be my guest 👍 For the record, there are some important refactor work going on right now like #72284 that might help fixing this. |
Sweet. I'll wait for that to land. |
#72284 seems unrelated to this PR. |
@marmeladema Seems like that PR landed. Is this still desirable? Or is there a different approach in the works? |
So #72284 was indeed unrelated, i got confused with another macro def map that exists during lowering .. sorry for the confusion. I haven't time to try any other approach, feel free to pick that up @ecstatic-morse you will probably be more efficient that me at solving that issue :) |
Superseded by #73103. |
Fixes #71820