groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Hoffmann <>
Subject Re: Groovy 2.5.4 generates dead code
Date Sun, 23 Dec 2018 18:47:29 GMT
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 ;)


> On 23. Dec 2018, at 01:24, Evgeny Mandrikov <> 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 < <>>
> 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

View raw message