-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Propagate spans and attributes from proc macro definitions #63761
Conversation
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
cc @Aaron1011 |
let edition = if sess.opts.debugging_opts.dual_proc_macros { | ||
self.host_lib.as_ref().unwrap().metadata.get_root().edition | ||
} else { | ||
self.root.edition |
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.
I'm not sure whether this dance is necessary.
Can these two "roots" have different editions?
I don't really understand how "dual proc macros" work.
cc @Zoxc
This comment has been minimized.
This comment has been minimized.
cc81a74
to
5c4e04e
Compare
macro_rules! quote { () => {} } | ||
#[allow_internal_unstable(proc_macro_def_site)] | ||
#[cfg_attr(not(bootstrap), rustc_builtin_macro)] | ||
pub macro quote ($($t:tt)*) { /* compiler built-in */ } |
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.
Ohhh right, this works now, without the risk of this quote
ending up defined anywhere other than the proc_macro
crate!
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.
r=me but maybe @alexcrichton or @dtolnay want to take a look as well
I won't pretend to fully understand what's happening here but what I do understand all seems quite reasonable! |
@bors r=eddyb |
📌 Commit 5c4e04e036ee8b4565ac9c8e24d4ca73abade656 has been approved by |
⌛ Testing commit 5c4e04e036ee8b4565ac9c8e24d4ca73abade656 with merge 8848c10c117204140db4f06c59687e44655dea92... |
💥 Test timed out |
☔ The latest upstream changes (presumably #63823) made this pull request unmergeable. Please resolve the merge conflicts. |
Previously in was implemented using a special hack in the metadata loader
Fix caching of loaded proc macros
…location Which is no longer dummy and is available from metadata now.
5c4e04e
to
c476b55
Compare
@bors r=eddyb |
📌 Commit c476b55 has been approved by |
Propagate spans and attributes from proc macro definitions Thanks to rust-lang#63269 we now have spans and attributes from proc macro definitions available in metadata. However, that PR didn't actually put them into use! This PR finishes that work. Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions. From those attributes only `deprecated` is both stable and supposed to be used in new code. (`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.) `Span::def_site` from the proc macro API now returns the correct location of the proc macro definition. Also, I made a mistake in rust-lang#63269 (comment), loaded proc macros didn't actually use the resolver cache. This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well. (Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
Propagate spans and attributes from proc macro definitions Thanks to rust-lang#63269 we now have spans and attributes from proc macro definitions available in metadata. However, that PR didn't actually put them into use! This PR finishes that work. Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions. From those attributes only `deprecated` is both stable and supposed to be used in new code. (`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.) `Span::def_site` from the proc macro API now returns the correct location of the proc macro definition. Also, I made a mistake in rust-lang#63269 (comment), loaded proc macros didn't actually use the resolver cache. This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well. (Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
Rollup of 4 pull requests Successful merges: - #62600 (libtest: add --show-output flag to print stdout of successful tests) - #63698 (Fixed floating point issue with asinh function) - #63761 (Propagate spans and attributes from proc macro definitions) - #63917 (Error when generator trait is not found) Failed merges: r? @ghost
Thanks to #63269 we now have spans and attributes from proc macro definitions available in metadata.
However, that PR didn't actually put them into use! This PR finishes that work.
Attributes
rustc_macro_transparency
,allow_internal_unstable
,allow_internal_unsafe
,local_inner_macros
,rustc_builtin_macro
,stable
,unstable
,rustc_deprecated
,deprecated
now have effect when applied to proc macro definition functions.From those attributes only
deprecated
is both stable and supposed to be used in new code.(
#![staged_api]
still cannot be used in proc macro crates for unrelated reasons though.)Span::def_site
from the proc macro API now returns the correct location of the proc macro definition.Also, I made a mistake in #63269 (comment), loaded proc macros didn't actually use the resolver cache.
This PR fixes the caching issue, now proc macros go through the
Resolver::macro_map
cache as well.(Also, the first commit turns
proc_macro::quote
into a regular built-in macro to reduce the number of places whereSyntaxExtension
s need to be manually created.)