Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* bjorn/compiler/eliminate-warnings:
compiler Makefile: Turn warnings into errors
v3_kernel_pp: Add support for pretty-printing #k_literal{} records
v3_kernel_pp: Eliminate warning
|
|
By accident a previous instance of St is used, which is
harmless in this case, but leads to worse quality of
the generated code.
|
|
We want to ensure that the compiler applications is kept
free of warnings.
|
|
|
|
|
|
Similar to -spec and -type, -export_type should be not be included
as attributes (and therefore loaded) in BEAM files, but only in
the abstract code chunk.
|
|
|
|
* bjorn/fix-compiler-bugs/OTP-8949:
beam_utils: Fix check_liveness/3 for receive loops
beam_utils: Fix liveness analysis for gc_bif instructions
|
|
Sometimes the beam_bool pass wants to know whether an
y register will be killed by the code that follows and
will do (effectively):
beam_utils:is_killed({y,Y}, Code, L)
When asked to calculate the liveness for an y register,
beam_utils:is_killed/3 will loop forever if the code
includes a receive loop.
Since this rarely occurs, fix the problem in the simplest
and most conservative way.
Reported-by: Christopher Williams
|
|
* pan/auto-import-doc-fix/OTP-8848:
Correct description of no_auto_import compiler directive
|
|
When gc_bif instructions occurred outside of a block,
beam_utils:check_liveness/3 did not take into account
that the instruction could do a garbage collection, and
could falsely report that an x register would be killed.
That could cause the beam_dead pass to make the code
unsafe by removing the assignment to an x register that
would subsequently be referenced by the garbage collector.
Reported-by: Christopher Williams
|
|
* ks/strengthen-specs:
lists: Strengthen and modernize specs
syntax_tools: Fix an erroneous type and strengthen some specs
ordsets: Export ordset/1 type and strengthen specs
compiler: Strengthen some specs to shut off dialyzer warnings
|
|
|
|
Moving of allocation instructions upwards in the instruction
stream (in order to enable further optimizations) in beam_block,
is implemented with the assumption that if a register {x,X}
contains a valid term, then all other x register with lower
numbers than X also contain valid terms. That assumption is
true after code generation.
The beam_utils:live_opt/1 optimization, however, may invalidate
that assumption. For instance, if a receive statement exports a
variable that is used, but the return value of the receive statement
is not used, then {x,1} but not {x,0} contains a valid term at the
end of the receive statement. If the receive statement is
followed by
{bif,self,{f,0},[],{x,0}}.
{test_heap,NumberOfWords,2}.
moving the allocation upwards will produce
{test_heap,NumberOfWords,2}.
{bif,self,{f,0},[],{x,0}}.
which will cause the beam_validator pass to scream loudly that
{x,0} is not live at the test_heap instruction.
Fix the problem by doing the optimizations in reverse order.
Reported-by: Jim Engquist
|
|
Silence the Dialyzer warning introduced in commit
7b283aa9507b45f2cd403b061ad92ab059fb71b5.
|
|
* bjorn/compiler-bin-generators/OTP-8864:
core_lint: Enforce that tail segments only occur at the end
Don't generate multiple tail segments in binary matching
Factor out some of the code for binary generators
Add tests for tail segments in binary generators
|
|
|
|
Code such as
foo(A) -> <<A:0>>.
would cause a compiler crash.
|
|
In binary matching, there must only be one "tail segment" (i.e.
a size-less segment of type binary) and it must be last. Thus,
the compiler will reject the following function definition:
foo(<<A/bits,B/bits>>) -> ok.
But code such as the following:
[42 || <<_:8/integer, _/bits>> <= Bits]
will internally (in the Core Erlang format) be translated to a
binary matching pattern containing two tail segments. The compiler
happens to generate correct code anyway (later passes will get
rid of the redundant tail segment), but it is ugly and will
confuse tools such as Dialyzer.
Change the transformation of binary generators (in both list and
binary comprehensions) not to generate add a tail segment if there
already is one.
|
|
In the code for handling binary generators (in list and binary
comprehensions), factor out the code for appending a match-all tail
segment onto a pattern into a separate function. That will only
make the code somewhat simpler, but will facilitate fixing a
bug/misfeture in the next commit.
|
|
|
|
|
|
|
|
|
|
* pan/ms_transform_warnings/OTP-6759:
Add testcases for ms_transform warning and fix scoping
Add warnings for shadowed variables in ms_transform funs
|
|
The code for generating the string table (which is now
only used for bit syntax matching) in a BEAM file is quite
complicated and potentially expensive when compiling modules
with many thousands of clauses doing bit syntax matching.
Simplify and optimize the code using bit syntax and
binary:match/2 instead of the list operations in the
original code.
|
|
* ks/cleanups:
compiler: Fix incorrect types and specs
escript: Add more types to records
debugger: Clean up as suggested by tidier
docbuilder: Clean up as suggested by tidier
Conflicts:
lib/debugger/src/dbg_iload.erl
lib/debugger/src/dbg_ui_trace_win.erl
|
|
Also changed compiler to allow for warnings in parse_transforms.
|
|
|
|
|
|
|
|
warn_unused_import works correctly (does not give warnings when overridden).
Local call in guard gives its own error pointing out the local/imported
function.
Use of the phrase "overridden auto-imported bif" instead of "redefined
auto-imported bif" in textual error messages.
|
|
While at it, do some other minor clean-ups.
|
|
* ks/dialyzer:
dialyzer: Build the PLT even if there are unresolved remote types
proplists: Export the type property()
erl_lint: Issue warnings for undefined exported types
Minor fix in a print message
Add handling of unknown types
Add declaration for exported types
Add types and specs; performed some cleanups also
erl_scan: Add declarations for exported types
stdlib: Add declarations for exported types
hipe: Add declarations for exported types
compiler: Add declarations for exported types
syntax_tools: Add declarations for exported types
kernel: Add declaration for exported types
Support -export_type() in dialyzer and erl_types
Add infrastructure for the -export_type() attribute
OTP-8678 ks/dialyzer
|
|
|
|
* origin/pan/otp_8579_autoimport_override:
Update preloaded modules
Update primary bootstrap
Remove outcommented code from erl_lint
Make port_command/3 auto-imported
Remove (harmless) warnings about min/max in core applications
Autoimport min/2 and max/2
Improve coverage of erl_int in testcases
Change warning to error for nowarn_bif_clash compiler directive
Add -compile({no_auto_import,[F/A]}) doc to compiler.xml
Add some testcases to compiler to verify that overriding really happens
Return nowarn_bif_clash functionality but with warning
Teach erl_lint to better override BIFs with local functions and imports
Teach compiler to override autoimport with import
First prototype for local functions overriding autoimported
OTP-8579 Local functions should override auto-imported
Local and imported functions now override the autoimported
BIFs when the names clash. The pre R14 behaviour was that
autoimported BIFs would override local functions. To avoid
that old programs change behaviour, the following will
generate an error:
Doing a call without explicit module name to a local function
having a name clashing with the name of an autoimported BIF
that was present (and autoimported) before OTP R14A
Explicitly importing a function having a name clashing with
the name of an autoimported BIF that was present (and
autoimported) before OTP R14A Using any form of the old
compiler directive nowarn_bif_clash
If the BIF was added or autoimported in OTP R14A or later,
overriding it with an import or a local function will only
result in a warning,
To resolve clashes, you can either use the explicit module
name erlang to call the BIF, or you can remove the autoimport
of that specific BIF by using the new compiler directive
-compile({no_auto_import,[F/A]})., which makes all calls to
the local or imported function without explicit module name
pass without warnings or errors.
The change makes it possible to add autoimported BIFs without
breaking or silently changing old code in the future. However
some current code ingeniously utilizing the old behaviour or
the nowarn_bif_clash compiler directive, might need changing
to be accepted by the compiler.
|
|
|
|
|
|
|
|
|
|
Wrote and changed some tests in stdlib:erl_lint_SUITE
nowarn_bif_clash is obsoleted but will remove warnings and errors about bif
clashes. The recommended way is to use no_auto_import directives instead.
Hopefully erlang.erl is the only user in the world of nowarn_bif_clash.
|
|
Added only a few testcases in compiler:error_SUITE and guard_SUITE
The new behaviour of warnings and errors when overriding autoimported BIF's:
Bifs that were autoimported before R14 are dangerous because old code
using them and overriding them in exports can start behaving
differently. For newly added autoimports this can't happen to the new
code that wants to (or dont want to) use them, why only warnings are
added for the BIFs autoimported after the compilator change. Errors
are issued only for code that could have worked in one way in R13 and
now will behave in a different way.
If overriding autoimport with local function:
- if explicit -compile directive supresses autoimport
-> no message
else
- if called from inside module
- if pre R14 autoimported bif
-> error
else
-> warning
else
-> no message
If overriding autoimport with import directive
- if explicit -compile directive supresses autoimport
-> no message
else (regardless of actual usage)
- if pre R14 autoimported bif
-> error
else
-> warning
Calls of local functions or imports overriding autoimported functions
(either post R14 or by using explicit -compile supressions of
autoimport) always goes to the local function or the imported.
The compileation errors are added to not let code like this silently
and disastrously change its semantic (probably to an infinite loop)
between R13 and R14:
----------
-module(m).
-export([length/1]).
length(X) ->
...
Y = length(Z),
....
----------
The user has to select if he/she wants to call length in 'erlang' explicitly
or if the overriding semantics is desired, in which case the -compile
directive has to be used.
-compile({no_auto_import,[F/A]}). Is added to allow to override the
autoimports so that code gets unanbiguous. The directive will remove
an autoimport even if there is no local function or import overriding,
because any other behaviour would be inconsistent and confusing.
record_info and module_info can never be overridden.
|
|
|