Age | Commit message (Collapse) | Author |
|
* 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
|
|
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
|
|
Not only variables are allowed as arguments, the name should reflect that.
Change cerl Map argument interface
* cerl:map_arg/1 is more suitable then cerl:map_val/1 in this case.
|
|
For updates of Map literals which may cause an error will be
determined in runtime, i.e. instructions are emitted for those
updates.
The changes in cerl now requires compiler-5.0 to compile because of
is_map/1 guard.
|
|
Reject all expressions that are known to fail.
Emit 'badarg' for those expressions.
Ex.
[]#{ a => 1}
Is not a valid map update expression.
|
|
|
|
|
|
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
|
|
* nox/compiler/sys_core_fold-redundant-clauses:
Properly handle redundant boolean clauses in sys_core_fold
|
|
b08ffc15e1d9ad105dd6385bbac41c97c09b48bc corrected a bug,
but violated the types by passing a c_apply() when a
c_let() was expected. That happened to work, but Dialyzer
was not amused.
|
|
* nox/compiler/v3_core-mismatched-apply:
Do not emit blatantly illformed apply expressions in core_inline
|
|
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
|
|
* nox/compiler/core_lint-call-guard:
Properly lint calls in Core Erlang guards
|
|
Reported-by: Ulf Norell
|
|
Code such as apply 'f'/1 () should not be emitted by the Core Erlang inliner.
Commit 1b8ad68361db59477013bf96e485d5293723ff42 added a test case
and correction in v3_core.
|
|
* 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
|
|
Previously, erlang:'or'(X, Y) and X or Y were not compiled to the same
Core code.
|
|
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
|
|
Not all calls to the erlang module are legal guards in Core Erlang.
|
|
* 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
|
|
* nox/compiler/sys_core_fold-erlang-is_record-3:
Do not mark all calls to erlang:is_record/3 as safe
|
|
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
|
|
(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
|
|
Reported-by: José Valim
|