-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[Coverage] Avoid recording regions from macro expansions #74067
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
Conversation
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.
Looks reasonable to me. But I’m not too familiar with code coverage overall.
// We want to walk into initializers for bindings, and the expansions of | ||
// MacroExpansionDecls, which will be nested within MacroExpansionExprs in | ||
// local contexts. | ||
return isa<PatternBindingDecl>(D) || isa<MacroExpansionDecl>(D); |
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.
How do we report code coverage for the expansions of a macro? Or I don’t fully understand why we need to walk into MacroExpansionDecl
.
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.
We don't, the only reason we need to walk into the expansion is to get accurate counter information for the following code, e.g for #id(try throwingFn())
, we need to account for the fact that code after the macro may not run if an error was thrown
780aab4
to
77fca82
Compare
Saves having to pass it as a parameter to `emitSourceRegions`.
Ignore any regions recorded while inside a macro expansion, but account for any control flow that may have happened such that the exit count is correctly adjusted. This allows e.g throwing function calls to behave correctly within the expansion. rdar://129081384
These replace the body of the function, and as such shouldn't be profiled.
Make sure we walk macro expansion decls to handle cases where e.g a binding introduces control flow. This should be a pretty uncommon case since bindings introduced by macros aren't actually usable when expanded in local contexts, but handle it all the same.
@swift-ci please test |
Ignore any regions recorded while inside a macro expansion, but account for any control flow that may have happened such that the exit count is correctly adjusted. This allows e.g throwing function calls to behave correctly within the expansion.
Additionally, make sure we avoid profiling functions with function body macros.
rdar://129081384