-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Using self
inside an include! no longer works
#15549
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
Comments
cc @jbclements, I believe this is "well, that's hygiene" |
“Hygiene” is a lofty goal, but something that makes things horrible to use and often useless. I frequently want to be able to turn hygiene off on macros. With hygiene, |
I’ve worked around this in rust-http in what was probably a better approach anyway: chris-morgan/rust-http@67e1188. On second thoughts, I think I’ll just close this and contemplate writing an RFC to kill |
Whoa, whoa, not trying to tick anyone off. A hygienic system doesn't preclude capturing macros like include!(), they're just not the default. The hygiene system is designed to pass the current context into macro invocations so that they can "pretend" that they come from the place where they were used. It sounds like an include!() macro is the place where you might want to use this. On the flip side, it sounds like you did find a better approach. |
Re-reading what I wrote, I should apologize for giving the impression that capturing macros are a simple matter of flipping a switch; I think the right thing here would be to define a hygiene_stomp!() macro that rewrites all contexts to be that of the macro use, after it's expanded. This wouldn't solve all such problems, but it would restore include!(). |
finally, I would note here that one issue is simply the inability to put macros in method position; if you had this, then the binding of self could just go in the included file, and everything would be fine(*) again (*) until we get hygiene for items.... |
Add a few more `db.unwind_if_cancelled()` calls Judging from a profile sent by a friend, the borrowck query took up a significant amount of time in their project which might be the cause for some unresponsiveness as nothing in the mir stack currently unwinds on cancellation
I presume this is fallout of #15537.
a.rs
:b.rs
:This used to work (rust-http depends on it with its codegen approach). Now:
The text was updated successfully, but these errors were encountered: