| Age | Commit message (Collapse) | Author |
|---|
|
* richcarl/eliminate_lib_module/PR-1786/OTP-15072:
Fix minor issues
Eliminate call to ct:get_progname() in ts_erl_config
Use \n escape instead of integer 10
Move error formatting to erl_error.erl and delete lib.erl
Move extended parse functions in lib.erl to erl_eval.erl
Move lib:eval_str/1 into mod_esi.erl
Remove lib:progname/0
Eliminate call to lib:progname/1 in slave.erl
Add ct:get_progname/0
Remove lib:error_message/2
Remove lib:flush_receive/0
Remove lib:send/2 and lib:sendw/2
Move lib:nonl/1 into yecc.erl
|
|
Fix syntactic issues in EDoc comments across some libs
|
|
Introduce is_map_key/2 guard BIF
OTP-15037
|
|
See https://github.com/erszcz/docsh/issues/23 for an explanation
about how the files were found.
|
|
|
|
This reverts commit 202bb737e3deabfebee683266f4b7c42781eb521.
|
|
This reverts commit 345f7f527a4c26ef49cef0d81e2c8b71bf01ebc3.
|
|
|
|
|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
When an exception is handled, the stack will be scanned. Therefore
all Y registers must be initialized.
|
|
beam_utils:is_killed/3 could incorrectly indicate that a
register was killed.
The previous fix is 5da6b91ecab6c.
|
|
Rewrite a call of a literal external fun to a direct call
OTP-15044
|
|
Rewrite calls such as:
(fun erlang:abs/1)(-42)
to:
erlang:abs(-42)
While we are at it, also add rewriting of apply/2 with a fixed
number of arguments to a direct call of the fun. For example:
apply(F, [A,B])
would be rewritten to:
F(A, B)
https://bugs.erlang.org/browse/ERL-614
|
|
Help us find more compiler bugs.
|
|
sys_core_fold would crash when attempting to optimize this code:
t() when (#{})#{}->
c.
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
Rationale
Today all compound data types except for maps can be deconstructed in guards.
For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are
completely opaque to guards. This means matching on maps can't be
abstracted into macros, which is often done with repetitive guards. It
also means that maps have to be always selected whole from ETS tables,
even when only one field would be enough, which creates a potential
efficiency issue.
This PR introduces an `erlang:map_get/2` guard-safe function that allows
extracting a map field in guard. An alternative to this function would be
to introduce the syntax for extracting a value from a map that was planned
in the original EEP: `Map#{Key}`.
Even outside of guards, since this function is a guard-BIF it is more
efficient than using `maps:get/2` (since it does not need to set up the
stack), and more convenient from pattern matching on the map (compare:
`#{key := Value} = Map, Value` to `map_get(key, Map)`).
Performance considerations
A common concern against adding this function is the notion that "guards
have to be fast" and ideally execute in constant time. While there are
some counterexamples (`length/1`), what is more important is the fact
that adding those functions does not change in any way the time
complexity of pattern matching - it's already possible to match on map
fields today directly in patterns - adding this ability to guards will
niether slow down or speed up the execution, it will only make certain
programs more convenient to write.
This first version is very naive and does not perform any optimizations.
|
|
Deprecate erlang:get_stacktrace/1
|
|
Keys in map patterns are input variables, not pattern variables.
|
|
Those warnings don't make sense any more since erlang:get_stacktrace/0
is now deprecated.
|
|
|
|
|
|
1ee21858db7e strengenthed validatation of GC instructions, but
forgot the following instructions:
bs_start_match2/5
bs_get_binary2/7
bs_get_float2/7
bs_get_integer2/7
bs_get_utf8/5
bs_get_utf16/5
bs_get_utf32/5
bs_skip_utf8/4
bs_skip_utf16/4
bs_skip_utf32/4
|
|
Waiting messages for a process may be stored in a queue
outside of any heap or heap fragment belonging to the process.
This is an optimization added in a recent major release to
avoid garbage collection messages again and again if there
is a long message queue.
Until such message has been matched and accepted by
the remove_message/0 instruction, the message must not be
included in the root set for a garbage collection, as that
would corrupt the message. The loop_rec/2 instruction explicitly
turns off garbage collection of the process as long messages
are being matched.
However, if the compiler were to put references to a message
outside of the heap in an Y register (on the stack) and there
happened to be a GC when the process had been scheduled out,
the message would be corrupted and the runtime system would
crash sooner or later.
To ensure that doesn't happen, teach beam_validator to check
for references on the stack to messages outside of the heap.
|
|
Fix unsafe optimization of record test
|
|
beam_record would make an unsafe optimization for the
not_used_p/4 function added to beam_utils_SUITE in this
commit. The bug is in beam_utils, which would falsely
report that {x,4} was unused when it in fact was used.
The bug was in the function not_used/1. The purpose of
not_used/1 is to return a 'not_used' result unless the
actual result is 'used'. Unfortunately it was not
implemented in that way. It would let a 'transparent'
result slip through, which the caller in this case would
convert to 'killed' (because the register was killed on
all other paths).
Reported-by: Richard Carlsson
|
|
Compile external fun expressions to literals
OTP-15003
|
|
bjorng/bjorn/compiler/fix-atom-leak/ERL-563/OTP-14968
Stop the compiler from overflowing the atom table
|
|
The expressions fun M:F/A, when all elements are literals are also
treated as a literal. Since they have consistent representation and
don't depend on the code currently loaded in the VM, this is safe.
This can provide significant performance improvements in code using such
functions extensively - a full function call to erlang:make_fun/3 is
replaced by a single move instruction and no register shuffling or
saving registers to stack is necessary. Additionally, compound data
types that contain such external functions as elements can be treated as
literals too.
The commit also changes the representation of external funs to be a
valid Erlang syntax and adds support for literal external funs to core
Erlang.
|
|
Use integer variable names instead of atoms in v3_core, sys_core_fold,
and v3_kernel to avoid overflowing the atom table.
It is a deliberate design decision to calculate the first free integer
variable name (in sys_core_fold and v3_kernel) instead of somehow
passing it from one pass to another. I don't want that kind of
dependency between compiler passes. Also note that the next free
variable name is not easily available after running the inliner.
|
|
|
|
The way variables created by make_template() are used, it is necessary
that the names are unique in the entire function. This has not
happened to cause any problems in the past because all other compiler
passes created atom variable names, not integer variable names. If
other passes start to create integer variable names, this bug is
exposed.
|
|
During compilation, the bs_save2 and bs_restore2 instructions contain a match
context reference. That reference is the variable name that holds the match context.
beam_clean assumes that the reference always is an atom, which is not a safe assumption
since integers are legal variable names in Core Erlang.
|
|
When a generator in a list comprehension was given some
other term than a list, the wrong line could be pointed
out in the exception. Here is an example:
bad_generator() ->
[I || %%This line would be pointed out.
I <- not_a_list].
https://bugs.erlang.org/browse/ERL-572
|
|
A literal negative size in binary construction would cause a crash.
|
|
The missing support for renumbering labels in recv_mark
and recv_set did not seem to cause any problems, probably because
the insructions are introduced late and their labels would keep
their numbers. But it there will definitely be a problem if the
recv_mark and recv_set instructions would be introduced much earlier.
|
|
For unclear reasons, v3_kernel attempts to guarantee that #k_try{}
always has at least one return value, even if it will never be
used. I said "attempts", because the handler block that is executed
when an exception is caught does not have the same guarantee. That
means that if an exception is thrown, the return value will not
actually be set.
In practice, however, this is not a problem for the existing code
generator (v3_codegen). The generated code will still be safe.
If we are to rewrite the code generator to generate an SSA-based
intermediate format, this inconsistency *will* cause problems
when creating phi nodes.
While at it, also remove an unecessary creation of new variables
in generation of #k_try_enter{}.
|
|
|
|
Conflicts:
OTP_VERSION
|
|
* hasse/dialyzer/extra-range/OTP-14970:
ssl: Correct some specs
os_mon: Correct a spec
Fix broken spec in beam_asm
Dialyzer should not throw away spec information because of overspec
|
|
|
|
|
|
Refactor and fix minor bugs in beam_type
|
|
Fix beam_utils bugs that could cause problems in the future
|
|
Make sure to kill all dependencies when a register is killed. For example,
in the following code, when the type information for {x,0} is killed in
the last instruction, there will still be type information for {x,1} referring
to {x,0}:
{get_tuple_element,{x,0},0,{x,1}}.
{test,is_eq_exact,{f,5},[{x,1},{atom,tag}]}.
{get_tuple_element,{x,0},1,{x,2}}.
{get_tuple_element,{x,0},2,{x,0}}.
This does not seems to have caused any problems in the past, but it may
cause problems in the future with a register allocator that reuses register
more aggressively.
|
|
|
|
The function tdb_update/2 is problematic. It does not distinguish
between assigning a register with a new value and updating information
about a register that is used a as source in a test instruction.
That was not a problem in practice when there were very few types,
but bugs started to be noticed as more types were added. (For example,
when a register was overwritten with a new value, the type for the
old value stored in the same register could linger in some cases.)
Introduce separate functions tdb_store/3 and tdb_meet/3 for assigning
a new value to a register and for updating type information for a
register referenced as as source, respectively. Also stricten
verification of the types that gets stored into the type database.
|
|
In the following code:
{get_tuple_element,{x,0},0,{x,1}}.
{put_tuple,2,{x,1}}.
{put,{atom,badmap}}.
{put,{x,0}}.
{move,{x,1},{x,0}}.
beam_block would move the get_tuple_element/3 instruction and eliminate the
move/2 instruction:
{put_tuple,2,{x,1}}.
{put,{atom,badmap}}.
{put,{x,0}}.
{get_tuple_element,{x,0},0,{x,0}}.
That is not correct, since the result of the tuple building in {x,1} is
now ignored.
|
|
live_opt_block/4 could overestimate the number of live
registers for a GC BIF and trigger an assertion. This does not
seem to be a problem when generating code using v3_codegen,
but only when using a new experimental code generator, therefore
there is no need include this correction in maint.
|
