[
https://issues.apache.org/jira/browse/GROOVY-11263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804476#comment-17804476
]
ASF GitHub Bot commented on GROOVY-11263:
-----------------------------------------
eric-milles commented on PR #2023:
URL: https://github.com/apache/groovy/pull/2023#issuecomment-1881861904
> dead code analysis, as its name shown, it just traverses AST and does not
change the AST, so no tranforming [sic] changes involved.
This was understood. The point is that if you add a compiler error you may
fail code that previously compiled. A compiler warning allows the user to be
notified but continue using code unchanged. Also, you scan the AST at a
specific point in time. If later AST transformations occur that address the
dead code scenarios, you have false positive.
I'm just trying to have you describe your reasoning for when to do the
analysis. Even the class generator does a bit of instruction re-ordering that
may or may not introduce dead code paths. It seems the goal of this change is
to identify any dead statements explicitly represented in the source file. If
that is indeed the case, it would be good to state all of this in the original
problem description.
> Analyze dead code
> -----------------
>
> Key: GROOVY-11263
> URL: https://issues.apache.org/jira/browse/GROOVY-11263
> Project: Groovy
> Issue Type: New Feature
> Reporter: Daniel Sun
> Priority: Major
> Labels: breaking_change
> Fix For: 5.x
>
>
> As we all know, source code is meant for developers to read, and the less
> redundant code there is, the more developer-friendly it becomes, but Groovy
> allows dead code after {{throw}}, {{return}}, {{break}} and {{continue}}, e.g.
> {code:java}
> def m() {
> return
> def a = 1
> }
> {code}
> It's better to avoid such dead code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
