| Age | Commit message (Collapse) | Author |
|---|
|
Since '=:=' is cheaper than '==', the compiler tries to replace
'==' with '=:=' if the result of comparison will be the same.
As an example:
V == {a,b}
can be rewritten to:
V =:= {a,b}
since the literal on the right side contains no numeric values
that '==' would compare differently to '=:='.
With the introduction of maps, we will need to take them into
account. Since the comparison of maps is planned to change in 18.0,
we will be very conservative and only do the optimization if
both keys and values are non-numeric.
|
|
We must not convert map patterns to map expressions.
|
|
In code such as:
case {a,Map} of
{a,#{}}=T ->
T
end
we must NOT rewrite a map pattern to a map expression like this:
case Map of
#{} ->
{a,#{}}
end
because the pattern '#{}' will match any map, but the expression
'#{}' will construct an empty map.
|
|
core_lib:is_var_used/2 would not consider a variable used in the
value of a map pattern such as:
case Map of
#{key := <<42:N>>} -> ok
end
Here the variable 'N' would not be considered used.
It was assumed that there was no need to check map patterns at
all, since maps currently don't support variables in keys.
|
|
* bjorn/compiler/map-in-record-bug/OTP-12402:
sys_core_fold: Correct optimization of 'case'
|
|
When optimizing boolean expressions, it is not always possible
to find a number of live registers for a GC BIF that both preserves
all source registers that will be tested and at the same time
does not include registers that are not initialized.
As currently implemented, we have incomplete information about
the register calculated from the free variables. Some registers
are marked as "reserved". Reserved registers means that we don't
know anything about them; they may or may not be initialized.
As a conservative correction (suitable for a maintenance release), we
will abort the optimization if we find any reserved registers when
calculating the number of live registers. We will not attempt to
improve the information about the registers in this commit.
By examining the coverage when running the existing compiler test
suite we find that the optimization is aborted 15 times (before
adding any new test cases). To put that in perspective, the
optimization is successfully applied 4927 times, and aborted for
other reasons 547 times.
Reported-by: Ulf Norell
Reported-by: Anthony Ramine
|
|
The optimization of a 'case' statement could lead to incorrect
code that would cause an exception at run-time.
Here is an example to show how the optimization went wrong. Start
with the following code:
f({r,#{key:=Val},X}=S) ->
case S of
{r,_,_} ->
setelement(3, Val, S)
end.
(The record operations have already been translated to the
corresponding tuple operations.) The first step in case_opt/3 is
to substitute S to obtain:
f({r,#{key:=Val},X}=S) ->
case {r,#{key:=Val},X} of
{r,_,_} ->
setelement(3, Val, S)
end.
After that substitution the 'case' can be simplified to:
f({r,#{key:=Val},_}=S) ->
case #{key:=Val} of
NewVar ->
setelement(3, Val, S)
end.
That is the result from case_opt/3. Now eval_case/2 notices
that since there is only one clause left in the 'case', the
'case' can eliminated:
f({r,#{key:=Val},_}=S) ->
NewVar = #{key:=Val},
setelement(3, Val, S).
Since the map construction may have a side effect, it was not
eliminated, but assigned to a variable that is never used.
The problem is that '#{key:=Val}' is fine as a pattern, but in a
construction of a new map, the '=>' operator must be used. So the
map construction will fail, generating an exception.
As a conservative correction for a maintenance release, we will
abort the 'case' optimization if the substitution into the 'case'
expression is anything but data items (tuples, conses, or
literals) or variables.
Reported-by: Dmitry Aleksandrov
|
|
A module containing two named funs bearing the same name and arity could be
miscompiled.
Reported-by: Sam Chapin
|
|
The fallback to latin-1 encoding would not work if the invalid
UTF-8 characters occurred in a skipped branch in an -ifdef/-ifndef.
|
|
|
|
* egil/maps-compiler-coverage:
compiler: Do not evaluate map expressions with bad keys
compiler: Throw 'nomatch' on matching with bad binary keys
compiler: Variable keys are not allowed in Maps
compiler: Strengthen Maps warnings tests
compiler: map_pair cannot be a type clause in v3_life
compiler: Remove redudant code in v3_codegen
compiler: Test deep map structure
compiler: Remove redundant clause in v3_codegen
compiler: Cover #{ [] => Var } in testcase
|
|
Map keys with large (non literal) binary keys must fail.
|
|
Even if a binary key is written as a literal the compiler may
choose to make an expression. Emit a warning in those cases
and saying the case will not match.
This is a limitation in current implementation.
|
|
Increases coverage.
|
|
The pass sys_core_fold did not correctly handle non-matching patterns in code
such as:
0 = case <<>> of
<<>> -> 0;
a -> 1
end.
Function case_opt_lit/3 is rewritten in two passes to first remove any
non-matching clause and only then potentially remove the related patterns
in each clause.
Reported-by: Ulf Norell
|
|
|
|
Coverage removed by literals.
|
|
* nox/maps-v3_core-lit_vars:
Properly collect variables in map expressions in v3_core
|
|
* bjorn/compiler/utf8-warning/OTP-11791:
Don't fail compilation for modules that contain invalid UTF-8
epp: Make it possible to specify a default encoding
|
|
The default encoding for Erlang modules is now UTF-8, and the
compilation would fail if a module contained byte sequences that
are not valid UTF-8 sequences.
In a large project with say many hundreds of Erlang modules
with names of developers such as "Björn" or "Håkan" encoded in
latin-1, that could mean that many hundreds of files would need
to be modified just to get started testing OTP 17.
As a temporary measure to ease the transition, automatically
fall back to the latin-1 encoding with a warning for any module
that contains invalid byte sequences and for which no encoding
has been specified.
The intention is to remove this workaround in OTP 18 or 19.
|
|
Reported-by: José Valim
|
|
Ex.
Instead of:
M~{~<K,V>}~
The format is now:
~{~<K,V>|M}~
This also removes a shift/reduce warning.
The changes in core_pp now requires compiler-5.0 to compile
because of is_map/1 guard, i.e. a need for a compiler with Maps know-how.
|
|
* nox/compiler/beam_bool-mixed-boolean:
Properly detect reused boolean values in beam_bool
|
|
Boolean case expressions with redundant clauses could make the compiler
crash:
case X == 0 of
false -> no;
false -> no;
true -> yes
end.
Reported-by: Ulf Norell
|
|
The following code could crash the compiler:
f(X = true) when X or true or X -> ok.
Reported-by: Ulf Norell
|
|
* nox/maps-beam_jump-put_map:
Properly collect labels in put_map instructions in beam_jump
|
|
* nox/maps-cerl_clauses:
Support maps in cerl_clauses:match/2
|
|
* nox/maps-beam_jump:
Properly check label use in get_map_elements in beam_jump
|
|
* nox/maps-v3_codegen-sort-nil-keys:
Properly sort map pairs in v3_codegen
|
|
* nox/maps-complex-mixed-values:
Properly order Kernel code for maps with mixed pairs
|
|
* nox/compiler/v3_core-comprehension-no-export:
Do not export variables from comprehension cases in v3_core
OTP-11770
|
|
* nox/compiler/beam_bool-not_boolean_expr:
Compile BIF calls and operator expressions to Core the same way
Do not try to optimize non-boolean guards
|
|
Reported-by: Ulf Norell
|
|
* nox/compiler/beam_bool-bad-protected:
Properly detect nonboolean protected expressions in beam_bool
|
|
* nox/compiler/live_opt-wait_timeout-nil:
Handle nil as a wait_timeout argument in beam_utils:live_opt/4
|
|
* nox/compiler/sys_core_fold-erlang-is_function-2:
Do not mark all calls to erlang:is_function/2 as safe
|
|
Code like the following snippet could make the compiler crash:
f() -> [X = a || false] ++ [X = a || false].
Reported-by: Ulf Norell
|
|
Expressions such as erlang:'or'(bar, true) can make beam_bool crash if it tries
to optimize them, as this code is not quite really written by users, no attempt
to rewrite them more efficiently should be done, for simplicity's sake.
Reported-by: Ulf Norell
|
|
Reported-by: Ulf Norell
|
|
Without this, sys_core_fold could crash on non-matching clauses using maps
patterns.
Reported-by: Ulf Norell
|
|
The Kernel instructions were not properly ordered when compiling maps with
complex values mixed in assoc and exact pairs.
Reported-by: Ulf Norell
|
|
Literal nil values aren't tagged tuple but the bare atom nil.
The function lists:sort/2 expects the passed function to return true if the first
element is less than or equal to the second, not strictly less than. The original
base clause is changed accordingly.
Reported-by: Ulf Norell
|
|
* nox/maps-fix-beam_bool-put_map:
Properly collect labels in put_map instructions in beam_bool
|
|
* nox/maps-expand-update:
Fix expansion of map update arguments
|
|
* nox/compiler/v3_core-mismatched-apply:
Do not emit blatantly illformed Core Erlang apply expressions
|
|
Reported-by: Ulf Norell
|
|
Silly code such as the following could make the compiler crash:
f() when erlang:float(self()); true -> ok.
Reported-by: Ulf Norell
|
|
Reported-by: Ulf Norell
|
|
Calls to erlang:is_function/2 where the second is not a literal nonnegative
integer can crash at runtime and thus can't be marked as safe.
|
|
Calls to erlang:is_record/3 where the second and third arguments are not
respectively a literal atom and a literal integer can't be transformed to guards
and thus are not safe.
Reported-by: Ulf Norell
|
