Eliminate incorrect warning for useless building #4899
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In OTP 24, there will be a warning for the following code:
The warning is incorrect, because the built term will be matched to
the previous value of
X
. This commit eliminates the warning.To explain the bug, I will illustrate how the example program is transformed
by the Core Erlang passes. My illustrative examples will use Erlang instead
of Core Erlang.
The first transformation makes the match
X = Y ++ "."
explicit:The variable
X1
is only needed for the matching. It will beannotated with a
compiler_generated
annotation to ensure that nocompiler warnings will be generated if it would later turn out that it
would never be used.
Next constants are propagated and constant expressions are evaluated.
Since the fun is only used once, it will be eliminated and its body
inlined. Now we have:
The final optimization for this example is simplification of expressions
whose values are never used:
The
".."
string will never be used, so it will be replaced withok
.At the same time, a warning will be emitted.
The reason for the warning is that the
".."
string does not have acompiler_generated
annotation to indicate that it was introduced bythe compiler. The
X1
variable had acompiler_generated
annotation,but it was lost when
X1
was replaced with".."
.To eliminate the unwanted warning, the
compiler_generated
annotationmust be propagated from the variable to the substituted value.
Thanks to Jose Maria Perez Ramos (@Kuroneer) for noticing this bug and
suggesting a way to fix it.