-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Properly handle SyntaxContext
of dummy spans in incr comp
#80654
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This is analogous to #76658, but for incremental compilation instead of crate metadata. |
@bors try @rust-timer queue |
Awaiting bors try build completion. |
⌛ Trying commit 84698d487ab2dfff21532a295f0e3f8d27051a8c with merge ac3a3578dcd48df9fc31b9f98a2e687e61b70965... |
☀️ Try build successful - checks-actions |
Queued ac3a3578dcd48df9fc31b9f98a2e687e61b70965 with parent bcd6975, future comparison URL. @rustbot label: +S-waiting-on-perf |
Finished benchmarking try commit (ac3a3578dcd48df9fc31b9f98a2e687e61b70965): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
r? @wesleywiser |
@bors r+ |
📌 Commit 84698d487ab2dfff21532a295f0e3f8d27051a8c has been approved by |
⌛ Testing commit 84698d487ab2dfff21532a295f0e3f8d27051a8c with merge 134ca574fc359f19ae3824c18b846c0f38e056de... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Fixes rust-lang#80336 Due to macro expansion, we may end up with spans with an invalid location and non-root `SyntaxContext`. This commits preserves the `SyntaxContext` of such spans in the incremental cache, and ensures that we always hash the `SyntaxContext` when computing the `Fingerprint` of a `Span` Previously, we would discard the `SyntaxContext` during serialization to the incremental cache, causing the span's `Fingerprint` to change across compilation sessions.
84698d4
to
482a67d
Compare
@bors r=wesleywiser |
📌 Commit 482a67d has been approved by |
☀️ Test successful - checks-actions |
Fixes #80336
Due to macro expansion, we may end up with spans with an invalid
location and non-root
SyntaxContext
. This commits preserves theSyntaxContext
of such spans in the incremental cache, and ensuresthat we always hash the
SyntaxContext
when computing theFingerprint
of a
Span
Previously, we would discard the
SyntaxContext
during serialization tothe incremental cache, causing the span's
Fingerprint
to change acrosscompilation sessions.