-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Add address field to SourceLocation struct #347
Add address field to SourceLocation struct #347
Conversation
Becasue address is used to determine if a line has been covered, this commit's changes add address to the key used for maps of TracerData. The gimli object used to describe line and path can be associated with multiple addresses which resulted in scenarios where lines that _were_ covered were missed in the reports (because a TracerData associated with line and path, but not the expected address, got to the map first). In this commit, a test was added to the `tests/data/matches` crate to illustrate a scenario that shows a line that was previously uncovered in reporting, is now covered.
For some context on what I mean about the potential for multiple addresses associated with
|
Just poking around a little, after these changes it looks like the |
So the GitHub pr view in the app is kinda bad so I can't see what you branched off. But have you tried the latest stuff I committed in develop which also fixed the coverage for method calls and the futures test? It sounds like we might have done the same thing albeit in different ways |
I'll have a proper look when I'm next at my pc 😊 |
I branched off current |
Ah that's because I'm a muppet who forgets to push his changes! So I took a slightly different approach and stored the location the same way but made a list of traces with all the addresses as the value. I did that because I wrote some test to see how the |
Ohh haha, okay! I'm happy a fix made it in :) |
The test for matches is still useful 😄 if you want to submit that as another PR |
Oh haha, yeah I can for sure!
…On Sun, Feb 16, 2020 at 3:32 PM xd009642 ***@***.***> wrote:
The test for matches is still useful 😄 if you want to submit that as
another PR
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
<#347?email_source=notifications&email_token=ABKZDXSD2LNQC2SQGOPRTCTRDHEHJA5CNFSM4KWAFOX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEL4V7CI#issuecomment-586768265>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKZDXRMN4TFTWCZJGIEKBLRDHEHJANCNFSM4KWAFOXQ>
.
|
👋 Hello! I took a stab at a fix for an issue I've seen in my own crates, thanks for taking a look 😄
Because address is used to determine if a line has been covered, this
commit's changes add address to the key used for maps of
TracerData
.The
gimli
object used to describe line and path can be associated with multiple addresseswhich resulted in scenarios where lines that were covered were missed
in the reports (because a
TracerData
associated with line and path, butnot the expected address, got to the map first).
In this commit, a test was added to the
tests/data/matches
crate to illustrate ascenario that shows a line that was previously uncovered in reporting,
is now covered.
I was personally motivated by the
match
scenario the test crate changes describe, but I'm curious whether these changes result in any wins for coverage in issues like #136 or #262