-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[WIP] Treat crates specially when expanding #50101
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
Conversation
@@ -286,6 +287,10 @@ pub fn token_to_string(tok: &Token) -> String { | |||
} | |||
} | |||
|
|||
pub fn crate_to_string(krate: &ast::Crate) -> String { |
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.
print_crate
requires more stuff to work and prints the crate as if it's going to be compiled from the printed source, adding stuff like #![no_std]
and the std
prelude injection.
Question: do we want to show the prelude injections and stuff that print_crate()
adds to its output?
@@ -0,0 +1,23 @@ | |||
// Copyright 2018 The Rust Project Developers. See the COPYRIGHT |
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 file is from #50092, should disappear when that's merged
ExpansionKind::OptExpr => | ||
Expansion::OptExpr(items.next().map(Annotatable::expect_expr)), | ||
ExpansionKind::Pat | ExpansionKind::Ty => | ||
panic!("patterns and types aren't annotatable"), |
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.
these changes are from #50092
cc @alexcrichton for the absolute paths thing (see OP) |
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 |
I'd personally probably recommend against this, I'd find it hard to imagine at least us ever stabilizing such functionality :( |
There's a lot of interest in being able to transform/walk an entire crate, so if we're not going to allow proc-macros to do it we should start thinking about something else. |
@alexcrichton if you prefer I can pivot this to forbid or feature-gate proc-macro attribute invocations on the crate. |
Is this in reference to macro attributes on the crate level or the special handling of the crate expansion?
Proc-macro attributes on the crate is, from my perspective, the only use that would even need this change. If proc-macro attributes on the crate are not supported, then what other need is there for the crate token expansion working?
If @alexcrichton's comment was related to the specific implementation, then we still have the other option: Keep the crate token expansion as it is (or change it slightly), but also make sure that the crate can be parsed back from the tokens. Currently the big issue is that while a crate can be tokenized - there is no token stream that can be turned back into a crate. |
I meant that instead of fixing crate expansion I would either rewrite this PR to or open a new one that forbids proc macro attribute invocations on the crate, or feature-gate the current usage so proc macro attributes can be stabilized without having to address this stuff first. Otherwise, yeah @alexcrichton your comment was rather vague. I assumed you meant you don't see proc macro attribute invocations on the crate ever being stabilized. |
Er sorry yeah, let me clarify. Right now for "Macros 1.2" were very unlikely to stabilize attribute invocations on modules. It's a weird question of what does Something like entire crate expansion also has huge repercussions on hygiene as well as whether it's feasible/quick. Entire crate expansion runs a risk of being extremely slow (we have to serialize back and forth with the procedural macro) and highly non-incremental (it's a complete black box to the compiler). I'd imagine that we're very far away from stabilizing this functionality, if at all. In that sense I'd personally be wary of landing this functionality in the compiler, even on nightly. I think it'd be best to take other avenues of attack for use cases that would otherwise require entire-crate expansion. |
@alexcrichton It's already allowed but it's very buggy (#41430). So, feature-gate or forbid? |
I don't personally feel too strongly, although if it were exclusively up to me I'd err on the side of forbidding this rather than feature-gating a fixed implementaiton. |
@petrochenkov what is your opinion on this? (see above discussion) |
Closing this PR as this appears to need more discussion. |
Oh, this is closed now. |
Give the base compilation unit of Rust source code the special treatment it deserves during macro expansion.
Pretty-prints crates as they should appear, doesn't pretend they're just modules without names (which breaks
syn
).I think this should also require proc-macro-attributes on the crate to be invoked with absolute paths which should alleviate resolution issues without doing anything too crazy.
TODO:
I branched this from #50092, will rebase when that one is merged so only relevant commits appear (if that isn't fixed automatically)
closes #41430
r? @petrochenkov
cc @Rantanen @jseyfried