Age | Commit message (Collapse) | Author |
|
|
|
In Core Erlang and later passes, compiler-generated code can be
indicated in two different ways: by negative line numbers and by
a 'compiler_generated' annotation.
Simplify the code and improve coverage by turning negative line
numbers positive and adding a 'compiler_generated' annotation in
the v3_core pass. That means that Core Erlang and latter passes
do not have deal with negative line numbers.
|
|
|
|
opt_guard_try/1 assumed that it was only operating on guards, and
implicitly assumed that any function call was to BIFs without
any side effects.
|
|
In:
case not Expr of ...
we don't have the information to ascertain that Expr is a boolean
expression. Therefore, add the catch-all clause unconditionally.
|
|
The second clause in opt_case_in_let_2/3 attempts to do the same
optimization as opt_bool_case_redundant/1; it will never succeed.
|
|
Also correct the comment in bsm_ensure_no_partition_2/5, and while at
it correct typos in the comment for bsm_nonempty/2.
|
|
|
|
The compiler (sys_core_fold) tries to avoid constructing tuples
in case expressions. The following code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
{_,_} -> error
end.
will be rewritten so that no tuple is built. If a clause
requires a tuple to be built as in this code:
c(A, B) ->
case {A,B} of
{ok,X} -> X;
V -> V %The tuple will be built here
end.
the tuple will be built in the clause(s) in which it is needed.
If the value returned from the case is not used as in this code:
c(A, B) ->
case {A,B} of
V -> V %Warning: a term is constructed, but never used
end,
ok.
there will be an incorrect warning. Basically, what happens is
that the code is reduced to:
c(A, B) ->
{A,B}, %Warning: a term is constructed, but never used
ok.
and the optimizer sees that the {A,B} tuple can't possibly be used.
Eliminate the warning by adding a 'compiler_generated' annotation
to the tuple.
Reported-by: Kostis Sagonas
|
|
|
|
|
|
The erl_expand_records compiler pass translates the
following code:
h(X) when X#r1.a =:= 1 -> ok.
to (essentially):
h({r1,V1,V2}=X) when element(2, X) =:= 1 -> ok.
Since the guard can only be executed when the pattern matching
has succeeded, we know that the second element in the tuple X
must have been bound to V2. Thus we can eliminate the call
to element/2 like this:
h({r1,V1,V2}=X) when V1 =:= 1 -> ok.
|
|
* bg/compiler-suppress-result-ignored:
compiler tests: Eliminate "result of expression is ignored" warnings
Silence warnings for expressions that are assigned to "_"
OTP-8602 bg/compiler-suppress-result-ignored
It is now possible to suppress the warning in code such as
"list_to_integer(S), ok" by assigning the ignored value "_" like this: "_ =
list_to_integer(S), ok".
|
|
There is currently no zero-cost way to silence the warning
"the result of the expression is ignored", which is issued
for code such as:
list_to_integer(S),
ok
Such code can be useful for assertions or input validation.
Teach the compiler to silence the warning for expressions
that are explicitly assigned to to the "_" variable,
such as:
_ = list_to_integer(S),
ok
Implement it by having the v3_core pass annotate calls in
Core Erlang like this:
let <_> = ( call 'erlang':'list_to_integer'(S) -| ['result_not_wanted'] )
in 'ok'
and modifiy sys_core_fold to suppress the warning for any call
having the annotation.
We deliberately do not make it possible to silence the warnings
for expressions like:
{build,an,unnecessary,term}, ok
or
is_list(L), ok
because we don't know of any real-world scenarios in which that would
be useful.
|
|
|