| Age | Commit message (Collapse) | Author |
|---|
|
* bjorn/compiler/applying-binary-crash/OTP-11672:
beam_bsm: Eliminate emulator crash when a binary is called
beam_validator: Validate the "fun" argument for a call_fun/1 instruction
|
|
* bjorn/compiler/optimizations/OTP-11584:
sys_core_fold: Prevent case expressions from being evaluated twice
sys_core_fold_SUITE: For cleanliness, move id/1 to the end
|
|
We must not do the delayed binary creation optimization if the
code attempts to call the matched out binary. Calling a matchstate
will crash the run-time system.
Reported-by: Loïc Hoguin
|
|
The fun argument for a call_fun/1 instruction was not validated.
|
|
* bjorn/eep37/OTP-11537:
Issue a warning when a named fun is constructed but not used
|
|
In e12b7d5331c58b41db06cadfa4af75b78b62a2b1, a bug was introduced
that would cause case expressions to be evaluated more than once
if there were aliases in the pattern. Example:
X = Y = io:put_chars("some chars"),
{X,Y}
That would be rewritten to code similar to (but in Core Erlang):
X = io:put_chars("some chars"),
X = io:put_chars("some chars"),
{X,Y}
Make sure that we only evalute the expression once by doing a
transformation similar to (but in Core Erlang):
NewVar = io:put_chars("some chars"),
X = NewVar,
Y = NewVar,
{X,Y}
Reported-by: José Valim
Reported-by: Anthony Ramine
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Simplify compiler internals and parsing of core format.
|
|
Simplify compiler internals for kernel passes.
|
|
|
|
|
|
|
|
|
|
|
|
Make map update expressions safe, i.e. (foo())#{ k1 := 1 }
|
|
The instruction get_map_element has a faillabel so you may not
use the instruction within a allocate/deallocate block.
|
|
|
|
|
|
|
|
|
|
With the => and := operators for updating maps, this optimization is
no longer valid.
|
|
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.
|
|
|
|
Update erlang lint and syntax expand for #{ K := V }
|
|
To add a type-testing guard BIF, the following steps are needed:
* The BIF itself is added to bif.tab (note that it should be declared
using "ubif", not "bif"), and its implementation to erl_bif_op.c.
* erl_internal must be modified in 3 places: The type test must be
recognized as guard BIF, as a type test, and it must be auto-imported.
* There must be an instruction that implements the same type test as
the BIF (it will be used in guards). beam_utils:bif_to_test/3 must
be updated to recognize the new guard BIF.
|
|
All pairs in a Map needs to be in strict ascending key order.
|
|
|
|
If a literal key already is present in a Map update the latter should be used.
Warn for previous duplicates in the Map.
|
|
|
|
|
|
Can now handle {list [reg()]} elements in instructions.
|
|
To make it possible to build the entire OTP system, also define
dummys for the instructions in ops.tab.
|
|
|
|
|
|
Code such as:
bar(X) ->
case {X+1} of
1 -> ok
end.
would crash the beam_except pass of the compiler.
The reason for the crash is that the '+' operator would add a line/1
instruction that the beam_except pass was not prepared to handle.
Reported-by: Erik Søe Sørensen
|
|
re needs unicode option
|
|
* bjorn/compiler/optimizations/OTP-11584:
Generalize optimizations of case statements
Ignore warnings when running sys_core_fold after inlining
|
|
* bjorn/fix-line-number-in-bs-exception/OTP-11572:
compiler: Correct line number in exception from binary construction
|
|
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.
|
|
Case expressions such as:
case {Expr1,Expr} of
{V1,V2} -> ...
end
are already optimized to not actually build the tuple. Generalize
the optimization to avoid building any kind of composite term,
such as:
case {ok,[A,B]} of
{ok,[X,Y]} -> ...
end
We don't expect programmers to write such code directly, but
inlining can produce such code.
We need to be careful about the warnings we produce. If the case
expression is a literal, it is expected that no warnings should be
produced for clauses that don't match. We must make sure that we
continue to suppress those warnings.
|
|
Reported-by: Stanislav Seletskiy
|
