On Tuesday, February 19, 2019 at 5:14:43 PM UTC+1, Sergey Zhemzhitsky wrote: > > > I heard multiple times that Scala code requires "better granularity at a > level of expressions" > > Basically I believe that all these expressions will occur in the bytecode > one way or another and the only issue is to distinguish them somehow. >
While all the expressions appear in the bytecode (not counting cases when for example ECJ performs dead code elimination) and so appear as part of instructions and branches counters in JaCoCo, mapping them to source (i.e./e.g. which exact part of one-line-expression was executed) without additional information from compiler (e.g. recall absence of column numbers in bytecode) is extremely hard task and I would say unsolvable in general case - as a rough analogy you can treat compiler as "hash function in black box" for source code. Consider following very basic case: return !x for which AFAIR javac generates exactly the same bytecode as for return !x ? 1 : 0 which happens to be exactly the same bytecode as generated by ECJ for return x ? 0 : 1 This also demonstrates complexity of implementation of filters in JaCoCo. Coverage tools that perform instrumentation at source level, able to provide better precision by addition of more probes (and increased overhead for performance) to identify parts of expressions - this is their way of "getting help from compiler". And I guess that statement about "better granularity" comes from the fact that in Scala long one-liner expressions are more frequent language construction than in Java. But maybe this is completely unrelated story if you satisfied with lines counter in JaCoCo. > > Have you ever tried them on real projects? > > I'd like to use all the power of jacoco for scala analysis on my current > project (~27K SLOC of scala) and would like to improve code coverage > reports for instructions and branches (with lines coverage thankfully > everything is ok) > > > IMO filters in sbt-jacoco are extremely weak ... To me seems that > one-liners are pretty common case in Scala. > > Well, it seems so. Then those filters can be treated as just a starting > point (having in mind these corner cases and testing them carefully). > > > AFAIK Scala compiler has option to switch-off generation of line numbers. > > That's true. But in that case only coverage of scala classes will be > affected (imo even then coverage will be better than now and to my mind not > so may people switches lines generation off on the daily basis) > Feel free to use these starting point(s) to experiment/test/validate implementation of filters for Scala using your custom build of JaCoCo for your codebase. And we'd be glad to hear about results/observations. Good luck. Evgeny -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/05ed59f7-7578-49a8-a9a8-b1fa35c5ae96%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
