| Age | Commit message (Collapse) | Author |
|---|
|
Conflicts:
lib/diameter/autoconf/vxworks/sed.general
xcomp/README.md
|
|
|
|
* maint:
compiler: Warn if the size of a binary segment is invalid
|
|
* bjorn/compiler/illegal-size/OTP-10197:
compiler: Warn if the size of a binary segment is invalid
|
|
* maint:
Revert "Merge branch 'nox/compile-column-numbers' into maint"
|
|
Column numbers was merged without understanding all the whole
story. See mail on erlang-patches for details.
This reverts commit df8e67e203b83f95d1e098fec88ad5d0ad840069, reversing
changes made to 0c9d90f314f364e5b1301ec89d762baabc57c7aa.
|
|
The compiler would silently accept and Dialyzer would crash on
code like:
<<X:(2.5)>>
It is never acceptable for Dialyzer to crash. The compiler should
at least generate a warning for such code. It is tempting to let
the compiler generate an error, but that would mean that code like:
Sz = 42.0,
<<X:Sz>>.
would be possible to compile with optimizations disabled, but not
with optimizations enabled.
Dialyzer crashes because it calls cerl:bitstr_bitsize/1, which
crashes if the type of size for the segment is invalid. The easiest
way to avoid that crash is to extend the sanity checks in v3_core
to also include the size field of binary segments. That will cause
the compiler to issue a warning and to replace the bad binary
construction with a call to erlang:error/1. (It also means that
Dialyzer will not issue a warning for bad size fields.)
|
|
Tuple funs were deprecated in R15B (in commit a4029940e309518f5500).
|
|
* bjorn/compiler/minor-fixes/OTP-10185:
erl_lint: Add a deprecated warning for literal tuple funs
beam_utils:live_opt/1: Correct handling of try_case_end/1
Correct guard_SUITE_tuple_size.S
beam_type: Print the offending function if this pass crashes
beam_validator: Validate the size operand in bs_init_bits and bs_init2
|
|
Liveness for the try_case_end/1 instruction should be calculated
in the same way as for the case_end/1 instruction.
|
|
|
|
|
|
|
|
* nox/compile-column-numbers:
Fix messages ordering with column numbers
Fix type compile:err_info/0
Test column number reporting in error_SUITE
Fix printing of errors with column numbers
Create a new "column" option in compile
Allow setting of initial position in epp
Export type erl_scan:location/0
|
|
If a process trap exits, calling the compiler would leave an EXIT
message in the message queue of the calling process because the
compiler spawns a temporary work process. Eliminate the EXIT process
by monitoring the temporary process instead of linking to it.
Reported-by: Jeremy Heater
|
|
Commit a612e99fb5aaa934fe5a8591db0f083d7fa0b20a turned module attributes from
2-tuples to 3-tuples but forgot to update get_base/1, breaking BASE for
parametric modules.
|
|
* jv/forms-source:
Allow the source to be set when compiling forms
OTP-10150
|
|
Use a gb_set instead of an ordset to store the set of defined
functions in the module to avoid quadritic time complexity.
|
|
With L1, L2, C1, C2 integers such as L1 < L2 and C1 < C2, locations
are ordered like this:
L1 < {L1, C1} < {L1, C2} < L2
|
|
|
|
OTP-10106
OTP-10107
|
|
There was a colon missing after the column number, it must be an error
as it's not missing in list_errors/2.
|
|
If set, compile will call epp with a full location {1, 1} instead of 1,
thus making it keep the column numbers in the parsed AST.
|
|
This commit adds a source option to compile:forms() that
sets the source value returned by module_info(compile).
|
|
|
|
* bjorn/compiler/coverage-and-minor-fixes/OTP-9982:
v3_life: Use common code for guards and bodies
v3_core: Don't put negative line numbers in annotations
v3_kernel: Dig out the line number only when generating a warning
v3_kernel: Clean up handling of guards
v3_kernel: Introduce is_in_guard/1
v3_kernel: Removed unreached clause for #k_bin_int{} in sub_size_var/1
v3_kernel: Remove unreached handling of #k_bin_int{} in arg_con/1
v3_codegen: Eliminate the special case of 'put' without destination
v3_kernel: Don't attempt to share identical literals
v3_kernel: Handle sequences in guards
v3_kernel: Remove clauses that are never executed in arg_val/1
v3_kernel.hrl: Remove unused record #k_string{}
v3_kernel.erl: Remove unused define of EXPENSIVE_BINARY_LIMIT
sys_core_fold: Refactor previous_ctx_to_binary/2 to cover it completely
sys_core_fold: Fix opt_guard_try/1
sys_core_fold: Simplify opt_bool_not() to cover it completely
sys_core_fold: Remove duplicate optimization
|
|
|
|
In Core Erlang and later passes, compiler-generated code can be
indicated in two different ways: by negative line numbers and by
a 'compiler_generated' annotation.
Simplify the code and improve coverage by turning negative line
numbers positive and adding a 'compiler_generated' annotation in
the v3_core pass. That means that Core Erlang and latter passes
do not have deal with negative line numbers.
|
|
|
|
Handling of guards become a mess when andalso/orelse in guards
were introduced. Clean it up by using common code for most
constructs, regardless of where they occur, and when needed use
is_in_guard/1 to handle guard constructs differently.
|
|
* ks/compile_info-fix:
compiler: Fix discrepancy in compile_info
OTP-9917
|
|
The BEAM disassembler used the atom 'none' to signify the absence
of a compile_info chunk in a .beam file. This clashes with the type
declaration of the compile_info field of a #beam_file{} record as
containing a list. Use [] to signify the absence of this chunk.
This simplifies the code and avoids a dialyzer warning.
For fixing a similar problem and for consistency, changed also the
return type of the attributes field of the #beam_file{} record.
This required a change in the beam_disasm test suite.
|
|
The inliner was ignorant of on_load functions and would discard them
(unless they were exported or referenced).
Noticed-by: Yiannis Tsiouris <[email protected]>
|
|
In the following code excerpt, the instruction marked below was
incorrectly removed:
.
.
.
{'try',{y,2},{f,TryCaseLabel}}.
{bif,get,{f,0},[{x,0}],{x,0}}.
{move,{x,1},{y,0}}.
{move,{x,3},{y,1}}. <======= Incorrectly removed
{jump,{f,TryEndLabel}}.
{label,TryEndLabel}.
{try_end,{y,2}}.
{deallocate,3}.
return.
{label,TryCaseLabel}.
{try_case,{y,2}}.
.
.
.
beam_utils indicated that {y,1} was not used at TryEndLabel,
which by itself is correct. But it is still not safe to remove
the instruction, because {y,1} might be used at TryCaseLabel
if an exception occurs.
Noticed-by: Eric Merritt
|
|
|
|
The size field of a #k_bin_int{} is always a literal integer
(#k_int{}); thus there is no way this clause can match.
While we are at it, remove a duplicated call to
select_assert_match_possible/3 in select_bin_int/1.
|
|
arg_con/1 will never be called with #k_bin_int{} argument, since
a #k_bin_int{} is constructed out of #k_bin_seg{} only after
arg_con/1 has been called with a #k_bin_seg{} argument.
|
|
If we let v3_kernel make sure that a 'put' operation always has a
destination register, the special case in v3_codegen is not needed.
|
|
It is unlikely that sharing literals will actually save any time.
Literals that can be shared are usually small. It is more likely
that maintaining the dictionary of literals will waste time.
|
|
A guard with a sequence will cause a crash in v3_codegen. Currently,
it seems that a sequence in a guard will never happen when compiling
from Erlang code, but there are several reasons to fix this problem
anyway:
* There are other compilers that generate Core Erlang code.
* Changes to sys_core_fold (perhaps additional optimizations) may
cause sequences to be generated in guards.
* A previously uncovered line in sys_core_fold:opt_guard_try/1 will
now be covered.
|
|
arg_val/1 will never be called for single-valued types, so there
is no need handle these types.
|
|
|
|
|
|
|
|
opt_guard_try/1 assumed that it was only operating on guards, and
implicitly assumed that any function call was to BIFs without
any side effects.
|
|
In:
case not Expr of ...
we don't have the information to ascertain that Expr is a boolean
expression. Therefore, add the catch-all clause unconditionally.
|
|
The second clause in opt_case_in_let_2/3 attempts to do the same
optimization as opt_bool_case_redundant/1; it will never succeed.
|
|
Also correct the comment in bsm_ensure_no_partition_2/5, and while at
it correct typos in the comment for bsm_nonempty/2.
|
|
In order to save space, rewrite suitable calls to erlang:error/{1,2}
to special BEAM instructions.
This code is probably longer than the code taken out of v3_life and
v3_codegen in the previous commit, but it is much easier to
understand and maintain since the BEAM assembler format is better
understood than the v3_life format.
|
|
In the v3_life pass, it is assumed that a 'match_fail' primop
only occur at the top-level and at the end of a function.
But this code:
do_split_cases(A) ->
case A of
x ->
Z = dummy1;
_ ->
Z = dummy2,
a=b
end,
Z.
will be optimized by sys_core_fold to the following code:
'split_cases'/1 =
fun (_cor0) ->
let <_cor7,Z> =
case _cor0 of
<'x'> when 'true' ->
< 'dummy1','dummy1' >
<_cor6> when 'true' ->
%% Here follows a 'match_fail' primop inside
%% multiple return values:
< primop 'match_fail'({'badmatch','b'}),'dummy2' >
end
in
Z
moving the 'match_fail' primop into a "values" construction.
In the future, we would like to get rid of the v3_life pass (it is
there for historical reasons), so in the mean-time we prefer to not
add more code to it by generalizing the handling of 'match_fail'.
Since the 'match_fail' primop can be simulated by erlang:error/{1,2},
the simplest solution is to translate 'match_fail' to a call to
erlang:error/{1,2} in v3_kernel and remove the handling of
'match_fail' in v3_life and v3_codegen.
It is tempting to get rid of 'match_fail' also in the Core Erlang
format, but there are two issues:
- Removing the support for 'match_fail' completely may break tools
that generate Core Erlang code. We should not do that in a minor
release.
- There is no easy way to generate a 'function_clause' exception
that will remain correct if it will be inlined into another
function. (Calling "erlang:error(function_clause, Args)" is
fine only if it is not inlined into another function.) A good
solution probably involves introducing new instructions, which
is better done in a major release.
Noticed-by: Håkan Matsson
Minimized-test-case-by: Erik Søe Sørensen
|
