-
Notifications
You must be signed in to change notification settings - Fork 13.4k
coverage of async function bodies should match non-async #84323
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
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ | |
2| |// structure of this test. | ||
3| | | ||
4| 2|#[derive(Clone, Debug, PartialEq, Eq, PartialOrd, Ord)] | ||
^0 ^0 ^0 ^0 ^1 ^1 ^0^0 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note that this fix also resolves the mystery (by removing them) of the double counters with some derived traits. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, I have to take this back. After reviewing the implementation of |
||
^0 ^0 ^0 ^1 ^0 | ||
------------------ | ||
| Unexecuted instantiation: <partial_eq::Version as core::cmp::PartialEq>::ne | ||
------------------ | ||
|
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.
It doesn't look like the
SyntaxContext
is adjusted in any other places (e.g. inbcb_to_initial_coverage_spans
). Is there something special about async desugarings that makes this necessary? What happens if the body of a function is generated from a macro (and therefore has a non-rootSyntaxContext
)?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.
See
function_source_span()
, which does adjust theSyntaxtContext
for all other spans.All of the function body spans are extrapolated to their
rustc_span::source_map::original_sp
.They are assumed to then be in the context of the body.
The bug, fixed by this PR, was that I assumed the body would always be in the root. Now all contexts are normalized to
root
.This allows me to use
Span::to()
, which, otherwise, doesn't always return the expected result, if the contexts are different (even though they are in the same source).The end result (in tests and in many practical use cases) provide the evidence that this approach works, except for the bug fixed by this PR, which is now obvious.
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 taking a closer look at this though, and trying an alternative that may be relevant to the concern you raised.
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 just uploaded a modified solution (see the new commit). This still forces all spans (fn_sig, body, and the MIR sources) to the same ctxt, so
Span::to()
should still work, but it does not force everything to the root ctxt anymore. Instead, thebody_span
's ctxt is now the common ctxt.In the previous commit, I normalized the
body_span
's ctxt to the root, but that would have changed the behavior ororiginal_sp
, when using thebody_span
as the enclosing span. That was the wrong change, and I'm glad to have had the opportunity to review this.