groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Hoffmann <hoffm...@mountainminds.com>
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 ;)

Cheers,
-marc


> On 23. Dec 2018, at 01:24, Evgeny Mandrikov <mandrikov@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 <forax@univ-mlv.fr <mailto:forax@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
> 


Mime
View raw message