-
Notifications
You must be signed in to change notification settings - Fork 12.2k
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
use old ctx if has same expand environment during decode span #127279
base: master
Are you sure you want to change the base?
Conversation
Could you check if the issue reproduces with #119412? |
Unfortunately, this issue still exists |
Whether |
Yep, but I think this might be an omission point during decoding spans that come from the disk cache: sometimes it may not be necessary to generate a new This means the span_b_ctx -> SyntaxContextData {
opaque: span_a.opaque,
opaque_and_semitransparent: span_a.opaque_and_semitransparent,
// ....
} I'm not sure if it's completely correct, but it's more convincing than simply disabling the disk cache for ident spans. |
def_ident_span
from disk
I think the new fix is in the right direction. In outer_expn: ExpnId,
outer_transparency: Transparency,
parent: SyntaxContext, and these two fields are caches / precomputed values for some operations on the substantial fields /// This context, but with all transparent and semi-transparent expansions filtered away.
opaque: SyntaxContext,
/// This context, but with all transparent expansions filtered away.
opaque_and_semitransparent: SyntaxContext, The last field seems to also be ignored during decoding (with a reasonable explanation). /// Name of the crate to which `$crate` with this context would resolve.
dollar_crate_name: Symbol, So there are two possible strategies for encoding/decoding
|
As you can see, the fields The content of span which need to encode is: span_a_ctx -> SyntaxContextData {
opaque: span_a_ctx,
//~^ note that `span_a_data.opaque` and `span_a_ctx` have the same value
// ....
} And during the second compilation:
|
Fixes #112680
The root reason why #112680 failed with incremental compilation on the second attempt is the difference in
opaque
between the span of the fieldident
and the span in the incremental cache attcx.def_ident_span(field.did)
.ident
asspan_a
, which is generated byapply_mark_internal
. Its content is similar to:tcx.def_ident_span
asspan_b
, which is generated bydecode_syntax_context
. Its content is:Although they have the same
parent
(both refer to the root) andouter_expn
, I cannot find the specific connection between them. Therefore, I chose a solution that may not be the best: give up the incremental compile cache to ensure we can usespan_a
in this case.r? @petrochenkov Do you have any advice on this? Or perhaps this solution is acceptable?