-
Notifications
You must be signed in to change notification settings - Fork 14.1k
coverage: Store signature/body spans and branch spans in the expansion tree #149471
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
base: main
Are you sure you want to change the base?
Conversation
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
|
rustbot has assigned @jdonszelmann. Use |
|
Preexisting, but are there tests for the signature coming from a macro def, but the body from the invocation site? Or where the outer block is also part of the macro and the statements inside are from the call site? I see the code "handling" it, but not sure what the effects are |
Instrumentation of macro expansions has pretty poor test coverage overall, but it was easy enough to add a new test for those specific cases. The other changes in this PR don't seem to affect the new tests, which is reassuring. |
coverage: Store signature/body spans and branch spans in the expansion tree In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction. There should be no change to compiler output.
coverage: Store signature/body spans and branch spans in the expansion tree In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction. There should be no change to compiler output.
In order to support coverage instrumentation of expansion regions, we need to reduce the amount of code that assumes we're only instrumenting a flat function body. Moving more data into expansion tree nodes is an incremental step in that direction.
There should be no change to compiler output.