-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
Add Span::mixed_site
, Span::resolved_at
, and Span::located_at
behind hygiene
feature
#228
Conversation
src/lib.rs
Outdated
/// The span located at the invocation of the procedural macro, but with | ||
/// local variables, labels, and `$crate` resolved at the definition site | ||
/// of the macro. | ||
/// | ||
/// `macro_rules` behaves like this in terms of hygiene. |
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 is a rephrasing of the proc_macro::Span::mixed_site() documentation, but I was unable to get $crate
to work in a proc macro -- it just errors with "expected identifier, found $
". Do you know if that is expected to work, or is that referring only to macro_rules
?
Would it be possible to avoid the need to opt-in with a feature? Perhaps these APIs could be unconditionally defined on appropriate rustc versions and beyond? |
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.
Agreed with Alex; there shouldn't be a feature gate on these.
Additionally, it would be better to expose resolved_at and located_at unconditionally and have it return the span associated with the name resolution behavior (as opposed to the line/column information, which is cosmetic) when the compiler doesn't support the underlying API. This way they can be adopted more readily by downstream code.
Fixes dtolnay#210 This was stabilized in Rust in rust-lang/rust#68716
On compilers prior to 1.45 where this is not stable, these fall back to returning the span associated with resolution behavior, since the source location is only cosmetic. This is a reversal of the previous fallback implementation, which preserved source location because it does not track resolution location. The differnce is only observable with `span_locations` enabled. These methods were stabilized in Rust in rust-lang/rust#69041
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.
Thanks, looks good.
I merged this with fc5678f to account for the possibility that any of the hygiene stabilizations are reverted before 1.45 ships. We can stabilize in proc-macro2 after the rustc release goes out.
This adds support for hygiene-related APIs recently stabilized for Rust 1.45 (currently nightly).
mixed_site
was stabilized in StabilizeSpan::mixed_site
rust-lang/rust#68716.resolved_at
andlocated_at
were stabilized in proc_macro: StabilizeSpan::resolved_at
andSpan::located_at
rust-lang/rust#69041The Cargo feature is named following the overarching
proc_macro_hygiene
language feature also about to be stabilized, which itself doesn't add any API surface forproc_macro2
.Closes #210