Hi guys, First of all please excuse me for the delay with reply.
On Wed, Nov 21, 2018 at 5:27 PM Remi Forax <fo...@univ-mlv.fr> wrote: > So you have several ways to fix the issue, > - ask Evgeny (in CC) that jacoco should recognize the nop ... athrow > sequence and do not report it. > Generally speaking unfortunately sequence of NOPs followed by ATHROW can appear in non-dead bytecode (reachable). For example Kotlin likes to insert NOPs in non-dead bytecode (reachable) and, while I don't have exact example, potentially they can be followed by ATHROW. So just recognition of sequence seems fragile to me. While we aware of this infamous sequence and can think about implementation of reachability analysis ( CC Marc R. Hoffmann ), class files that do not come directly from compiler will likely lead to not-so-nice results (case of post-processing by ASM), because of mapping of coverage back on source files. This limits need / ROI of this reachability analysis, thus > - fix the groovy compiler to not generate dead code > IMO fix of compiler is ideal option with benefits of everyone, e.g. in this case class files produced by Groovy compiler will be at least smaller ;) Andreas, do you think this is feasible? BTW I'm not aware of cases where javac or kotlinc generate unreachable code. Regards, Evgeny
