Hi all, we could add a general "unreachable code filter”. At least simple CFG based unreachability should be doable. But as always I prefer to fix the root cause ;)
Cheers, -marc > On 23. Dec 2018, at 01:24, Evgeny Mandrikov <mandri...@gmail.com> wrote: > > 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 > <mailto: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 >
