You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Scoverage fails to provide coverage for objects that use macro annotations. This example is based upon real life usage with the ZIO accessible macro with the ZIO 1.x module pattern. Methods that are added by the developer do not have code coverage created for them although they should as only macro generated code should be ignored without the object body. It is highly probable that this also affects other macros using macro annotations. The killer is that code written and tested by the developer is silently excluded from code coverage which can hide bugs/code without coverage.
This project contains two objects representing services, that are equivalent, except that one has the manually generated code and the other uses the accessible macro
The cause
Within the plugin.scala code in Scoverage there is some code that ignores macro expanded code, regardless of whether the code has original line positions available for parts of the macro expanded code:
def process(tree: Tree): Tree = {
tree match {
...
// ignore macro expanded code, do not send to super as we don't want any children to be instrumented
case t
if t.attachments.all
.toString()
.contains("MacroExpansionAttachment") =>
t
Ideally this can recursively inspect the macro expanded code and instrument the parts of the tree that have pos different from the macro pos. I modified the code as an experiment, and it worked to a degree, but the output reports don't work correctly. A proper fix is required
Summary
Scoverage fails to provide coverage for objects that use macro annotations. This example is based upon real life usage with the ZIO accessible macro with the ZIO 1.x module pattern. Methods that are added by the developer do not have code coverage created for them although they should as only macro generated code should be ignored without the object body. It is highly probable that this also affects other macros using macro annotations. The killer is that code written and tested by the developer is silently excluded from code coverage which can hide bugs/code without coverage.
This project contains two objects representing services, that are equivalent, except that one has the manually generated code and the other uses the accessible macro
The cause
Within the plugin.scala code in Scoverage there is some code that ignores macro expanded code, regardless of whether the code has original line positions available for parts of the macro expanded code:
Ideally this can recursively inspect the macro expanded code and instrument the parts of the tree that have pos different from the macro pos. I modified the code as an experiment, and it worked to a degree, but the output reports don't work correctly. A proper fix is required
How to recreate
A project recreating the issue can be found here
https://github.com/ollyw/scoverage-macro-issue-repoducer
The text was updated successfully, but these errors were encountered: