| Age | Commit message (Collapse) | Author |
|---|
|
There is no need to always introduce a new variable to hold a map.
Maps are novars (constructs that don't export variables).
|
|
Compiling the following function:
f(V) when not (bar and V) -> true; %Line 4
f(_) -> false.
would produce the following warnings:
no_file: Warning: the call to is_boolean/1 has no effect
t.erl:4: Warning: the guard for this clause evaluates to 'false'
t.erl:4: Warning: use of operator '=:=' has no effect
Two of the warnings refer to calls to is_boolean/1 and '=:='/2 which
v3_core added when translating the code to Core Erlang. The only
relevant warning is:
t.erl:4: Warning: the guard for this clause evaluates to 'false'
Suppress the other two warning by marking the compiler-generated
calls with a 'compiler_generated' annotation.
|
|
|
|
|
|
Core Erlang annotations are supposed to be a list of terms. v3_core
could temporarily stuff a record in the 'anno' field of a Core Erlang
record. That will cause Dialyzer warnings if we would tighten the
type specs for annotations. (We want to tighten the warnings in order
to catch more real problems.)
Avoid abusing the annotation by wrapping the entire Core Erlang
record in a #isimple{} record.
Reported-by: Kostis Sagonas
|
|
In c34ad2d5, the compiler learned to silence some warnings for
expressions that were explicitly assigned to the '_' variable,
as in this example:
_ = list_to_integer(S),
ok
That commit intentionally only made it possible to silence warnings
for BIFs that could cause an exception. Warnings would still be
produced for:
_ = date(),
ok
because date/0 can never fail and thus making the call completely
useless. The reasoning was that such warnings can always be
eliminated by eliminating the offending code.
While that is true, there is the question about rules and their
consistency. It is surprising that '_' can be used to silence
some warnings, but has no effect on other warnings.
Therefore, we will teach the compiler to silence warnings for
the following constructs:
* Calls to safe BIFs such as date/0
* Expressions that will cause an exception such as 'X/0'
* Terms that are built but not used, such as '{x,X}'
|
|
When translating a function with map construction:
f(A) ->
B = b,
C = c,
#{A=>1,B=>2,C=>3}.
v3_core would break apart the map construction into three
parts because of the way the map instructions in BEAM work --
variable keys need to be in their own instruction.
In the example, constant propagation will turn two of the
keys to literal keys. But the initial breaking apart will
not be undone, so there will still be three map constructions:
'f'/1 =
fun (_cor0) ->
let <_cor3> = ~{::<_cor0,1>}~
in let <_cor4> = ~{::<'b',2>|_cor3}~
in ~{::<'c',3>|_cor4}~
It would be possible to complicate the sys_core_fold pass
to regroup map operations so that we would get:
'f'/1 =
fun (_cor0) ->
let <_cor3> = ~{::<_cor0,1>}~
in ~{::<'b',2>,::<'c',3>|_cor3}~
A simpler way that allows to simplify the translation is
to skip the grouping in v3_core and translate the function
to:
'f'/1 =
fun (_cor0) ->
~{::<_cor0,1>,::<'b',2>,::<'c',3>}~
We will then let v3_kernel do the grouping while translating
from Core Erlang to Kernel Erlang.
|
|
Maps have certain invariants that must be preserved:
(1) A map as a pattern must be represented as #c_map{} record,
never as a literal. The reason is that the pattern '#{}' will
match any map, not just the empty map. The literal '#{}' will
only match the empty map.
(2) In a map pattern, the key must be a literal, a variable, or
data (list or tuple). Keys that are binaries or maps *must* be
represented as literals.
(3) Maps in expressions should be represented as literals if possible.
Nothing is broken if this invariant is broken, but the generated
code will be less efficient.
To preserve invariant (1), cerl:update_c_map/3 must never collapse
a map to a literal. To preserve invariant (3), cerl:update_c_map/3
must collapse a map to a literal if possible.
To preserve both invariants, we need a way for cerl:update_c_map/3 to
know whether the map is used as a pattern or as an expression. The
simplest way is to have an 'is_pat' boolean in the #c_map{} record
which is set when a #c_map{} record is initially created.
We also need to update core_parse.yrl to establish the invariants
in the same way as v3_core, to ensure that compiling from a
.core file will work even if all optimizations on Core Erlang are
disabled.
|
|
The translation of list comprehension with a map pattern
with a big literal binary as key such as:
lc(L) ->
[V || #{<<2:301>> := V} <- L].
would generate Core Erlang code where an unbound variable
were referenced:
'lc'/1 =
fun (L) ->
letrec
'lc$^0'/1 = fun (_cor4) ->
case _cor4 of
<[~{~<_cor1,V>}~|_cor3]> when 'true' ->
let <_cor5> = apply 'lc$^0'/1(_cor3)
in [V|_cor5]
<[_cor2|_cor3]> when 'true' ->
apply 'lc$^0'/1(_cor3)
<[]> when 'true' ->
[]
end
in let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}#
in apply 'lc$^0'/1(L)
In the map pattern in the 'case' in the 'letrec', the key is the
variable '_cor1' which should be bound in the enclosing environment.
It is not.
There is binding of '_cor1', but in the wrong place (at the end of
the function). Because of the way v3_kernel translates letrecs,
the code *happens* to work.
The code will break if Core Erlang optimizations were strengthened
to more aggressively eliminate variable bindings that are not used,
or if the translation from Core Erlang to Kernel Erlang were changed.
Correct the translation so that '_cor1' is bound in the environment
enclosing the 'letrec':
'lc'/1 =
fun (L) ->
let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}#
in letrec
'lc$^0'/1 = fun (_cor4) ->
case _cor4 of
<[~{~<_cor1,V>}~|_cor3]> when 'true' ->
let <_cor5> = apply 'lc$^0'/1(_cor3)
in [V|_cor5]
<[_cor2|_cor3]> when 'true' ->
apply 'lc$^0'/1(_cor3)
<[]> when 'true' ->
[]
end
in apply 'lc$^0'/1(L)
Unfortunately I was not able to come up with a test case that
demonstrates the bug.
|
|
* maint:
Fix miscompilation when module contains multiple named funs
Fix locations of shadowing warnings in ms_transform
|
|
Commit 78ce8917d started to use get_anno/1 to extract the line
annotation from filter qualifiers in comprehensions, but this does not
respect the spec of this function and resuls in a dialyzer warning.
To make the code more type-friendly, introduce a get_qual_anno/1
function.
Kostis Sagonas suggested that the function should be implemented
similar to this to also ensure that the qualifiers are of the
appropriate form:
get_qual_anno({call,Line,_,_}) -> Line;
get_qual_anno({op,Line,_,_,_}) -> Line;
.
.
.
get_qual_anno({var,Line,_}) -> Line.
The problem is that it is difficult to know exacly which forms
that may occur and the function will need to be updated if new
abstract forms are added. Thus this implementation would complicate
maintanance without any real payoff.
Reported-by: Kostis Sagonas
|
|
A module containing two named funs bearing the same name and arity could be
miscompiled.
Reported-by: Sam Chapin
|
|
Matching of type:
#{K := V1} = #{K := V2} = M,
Will alias (coalesce) to
#{K := V1 = V2} = M.
|
|
|
|
Check for literals instead of variables when constructing chains.
|
|
Two patterns, binary_segment size and map_pair key, are expressions
even in matching. If only bound variables are used we are fine but
some expressions which appears as literals needs to be lifted.
Currently only Map key binaries will use this.
|
|
|
|
|
|
|
|
|
|
This ticket is about records in Erlang code, and when to check the
fields against the (optional) types given when defining records.
Dialyzer operates on the Erlang Core format, where there are no trace
of records. The fix implemented is a Real Hack:
Given the new option 'dialyzer' erl_expand_records marks the line
number of records in a way that is undone by v3_core, which in turn
inserts annotations that can be recognized by Dialyzer.
|
|
|
|
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.
|
|
Reported-by: José Valim
|
|
Core should not understand M#{}
Instead transform M#{} to
case _cor0 of
<_cor1>
when call 'erlang':'is_map'
(_cor0) ->
_cor1
( <_cor2> when 'true' ->
primop 'match_fail'
('badarg')
-| ['compiler_generated'] )
end
|
|
Reject all expressions that are known to fail.
Emit 'badarg' for those expressions.
Ex.
[]#{ a => 1}
Is not a valid map update expression.
|
|
|
|
* nox/compiler/v3_core-comprehension-no-export:
Do not export variables from comprehension cases in v3_core
OTP-11770
|
|
Code like the following snippet could make the compiler crash:
f() -> [X = a || false] ++ [X = a || false].
Reported-by: Ulf Norell
|
|
Previously, erlang:'or'(X, Y) and X or Y were not compiled to the same
Core code.
|
|
(fun f/1)() should be compiled to let X = 'f'/1 in apply X () to let the compiler
properly generate code that will fail with badarity at runtime.
Reported-by: Ulf Norell
|
|
* egil/compiler/maps-get_map_elements:
compiler: Strengthen Maps compile tests
compiler: Remove dead warning
erts: Fix erts_debug:disassemble/1
compiler: Transform list of Args to exact literal type
compiler: Test Maps aliasing
compiler: Use aliasing in map pair patterns
compiler: Check literal order in beam_validator
erts: Introduce new instructions for combined key fetches
compiler: Change map instructions for fetching values
|
|
|
|
Given that map comprehensions and generators and maybe && generators will be added
to the language in the future, v3_core:lc_tq and v3_core:bc_tq could use a rewrite
to avoid a complexity explosion, where there are as many related clauses as the
product of the number of types of generators and the number of types of
comprehensions.
The new code abstract over all generators at the same time, there is only one clause
for generators per type of comprehension, and all the filter code has been put
in a common function filter_tq.
It should also be noted that generator inputs are now compiled before the rest
of the qualifiers, reversing names of nested comprehensions.
|
|
* 'bjorn/lc-warnings/OTP-11626' (early part):
v3_core: Annotate list comprehensions to help out dialyzer
|
|
* hsv/using_lists_droplast:
lib/mnesia/test/ - Replace reverse(tl(reverse(L))) with lists:droplast/1
lib/ssh - Replace reverse(tl(reverse(L))) with lists:droplast/1
lib/wx - Replace reverse(tl(reverse(L))) with lists:droplast/1
Use lists:droplast/1 in orber/orber_interceptors.erl
Import and use lists:droplast/1 in v3_core/v3_kernel
OTP-11678
OTP-11677
|
|
|
|
|
|
Simplify compiler internals and parsing of core format.
|
|
Make map update expressions safe, i.e. (foo())#{ k1 := 1 }
|
|
The syntax is handled upto v3_kernel where it is reduced to
previous behaviour for construction and updates. Meaning,
the ':=' operator is handled exactly as '=>' operator.
|
|
|
|
To make it possible to build the entire OTP system, also define
dummys for the instructions in ops.tab.
|
|
Also imported lists:last/1, and removed the local definition.
|
|
Because 26940a8c0c lifted code in the 'after' clause of 'try' to
a new function, Dialyzer could produce false warnings for code such
as:
try
...
after
file:close(F)
end.
Mark the the call to the generated function as 'compiler_generated'
to silence the warning.
|
|
This adds optional names to fun expressions. A named fun expression
is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse.
If a fun expression has a name, it must be present and be the same in
every of its clauses. The function name shadows the environment of the
expression shadowing the environment and it is shadowed by the
environment of the clauses' arguments. An unused function name triggers
a warning unless it is prefixed by _, just as every variable.
Variable _ is allowed as a function name.
It is not an error to put a named function in a record field default
value.
When transforming to Core Erlang, the named fun Fun is changed into
the following expression:
letrec 'Fun'/Arity =
fun (Args) ->
let <Fun> = 'Fun'/Arity
in Case
in 'Fun'/Arity
where Args is the list of arguments of 'Fun'/Arity and Case the
Core Erlang expression corresponding to the clauses of Fun.
This transformation allows us to entirely skip any k_var to k_local
transformation in the fun's clauses bodies.
|
|
|
|
* nox/lift-after/OTP-11267:
Lift 'after' blocks to zeroary functions
|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
