Properly handle cross-crate SyntaxContext::root and ExpnId::root
#85708
Labels
A-macros
Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
A-metadata
Area: Crate metadata
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
Aaron1011
added a commit
to Aaron1011/rust
that referenced
this issue
May 29, 2021
As described in issue rust-lang#85708, we currently do not properly decode `SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a result, when we decode a span from a foreign crate with `SyntaxContext::root()`, we end up up considering it to have the edition of the *current* crate, instead of the foreign crate where it was originally created. A full fix for this issue will be a fairly significant undertaking. Fortunately, it's possible to implement a partial fix, which gives us the correct edition-dependent behavior for `:pat` matchers when the macro is loaded from another crate. Since we have the edition of the macro's defining crate available, we can 'recover' from seeing a `SyntaxContext::root()` and use the edition of the macro's defining crate. Any solution to issue rust-lang#85708 must reproduce the behavior of this targeted fix - properly preserving a foreign `SyntaxContext::root()` means (among other things) preserving its edition, which by definition is the edition of the foreign crate itself. Therefore, this fix moves us closer to the correct overall solution, and does not expose any new incorrect behavior to macros.
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this issue
May 30, 2021
…petrochenkov Use correct edition when parsing `:pat` matchers As described in issue rust-lang#85708, we currently do not properly decode `SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a result, when we decode a span from a foreign crate with `SyntaxContext::root()`, we end up up considering it to have the edition of the *current* crate, instead of the foreign crate where it was originally created. A full fix for this issue will be a fairly significant undertaking. Fortunately, it's possible to implement a partial fix, which gives us the correct edition-dependent behavior for `:pat` matchers when the macro is loaded from another crate. Since we have the edition of the macro's defining crate available, we can 'recover' from seeing a `SyntaxContext::root()` and use the edition of the macro's defining crate. Any solution to issue rust-lang#85708 must reproduce the behavior of this targeted fix - properly preserving a foreign `SyntaxContext::root()` means (among other things) preserving its edition, which by definition is the edition of the foreign crate itself. Therefore, this fix moves us closer to the correct overall solution, and does not expose any new incorrect behavior to macros.
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this issue
May 30, 2021
…petrochenkov Use correct edition when parsing `:pat` matchers As described in issue rust-lang#85708, we currently do not properly decode `SyntaxContext::root()` and `ExpnId::root()` from foreign crates. As a result, when we decode a span from a foreign crate with `SyntaxContext::root()`, we end up up considering it to have the edition of the *current* crate, instead of the foreign crate where it was originally created. A full fix for this issue will be a fairly significant undertaking. Fortunately, it's possible to implement a partial fix, which gives us the correct edition-dependent behavior for `:pat` matchers when the macro is loaded from another crate. Since we have the edition of the macro's defining crate available, we can 'recover' from seeing a `SyntaxContext::root()` and use the edition of the macro's defining crate. Any solution to issue rust-lang#85708 must reproduce the behavior of this targeted fix - properly preserving a foreign `SyntaxContext::root()` means (among other things) preserving its edition, which by definition is the edition of the foreign crate itself. Therefore, this fix moves us closer to the correct overall solution, and does not expose any new incorrect behavior to macros.
jyn514
added
A-metadata
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I've started a discussion on Zulip (https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Cross.20crate-hygiene.20roots) - there are some unresolved questions about how we want the general solution ('correct' cross-crate decoding of and ) to work. However, it should be possible to make a hack that just fixes the problems for macros: when we're checking the span of a token for a foreign macro, fall back to the edition of that foreign crate if the is .
Originally posted by @Aaron1011 in #84429 (comment)
The text was updated successfully, but these errors were encountered: