1 Compiler Release Notes
This document describes the changes made to the Compiler application.
1.1 Compiler 4.3.12
1.1.1 Improvements and New Features
-
The following code would crash the compiler:
case T
of #r{s = ""} -> T #r{s = "x"} end
. (Thanks to
Richard Carlsson.)
The compiler could crash if binaries were constructed
in certain guards involving boolean operators (including
semicolon). (Thanks to Torbjorn Tornkvist.)
Own Id: OTP-5872
-
The compiler will now warn that the
megaco:format_versions/1
function is deprecated.
Own Id: OTP-5976
1.2 Compiler 4.3.11
1.2.1 Improvements and New Features
-
The compiler would assume that some patterns with
aliases ('=') would not match if they were split into
several lines. (Thanks to Peter Nagy/Mats Cronqvist.)
Minor cleanups to eliminate Dialyzer warnings.
Own Id: OTP-5791 Aux Id: seq10141
1.3 Compiler 4.3.10
1.3.1 Fixed Bugs and Malfunctions
-
When given the new option
'
strict_record_tests
', the compiler will generate
code that verifies the record type for
'R#record.field
' operations (in body context only,
not in guards). See the documentation for the
compile
module for more information.
The beam validator pass of the compiler could crash
given in rare circumstances when given certain
combinations of catches and record operations. (Thanks to
Mats Cronqvist.)
Attributes containing binaries (such as -a(<<1,2,3>>))
would crash the compiler. (Thanks to Roger Price.)
Multiple behaviours in the same module will no longer
generate a warning, unless one or more callbacks for the
behaviours overlap. For instance, using both the
'application
' and 'supervisor
' behaviours
in the same module will NOT generate any warning, but
using 'gen_server
' and 'gen_fsm
' will.
Own Id: OTP-5714 Aux Id: seq10073
-
The pre-processor used to complain that the macro
definition '
-define(S(S), ??S).
' was circular,
which it isn't. (Thanks to Richard Carlsson.)
Own Id: OTP-5777
1.4 Compiler 4.3.9
1.4.1 Fixed Bugs and Malfunctions
-
Updating at least two fields of a record with a literal
string could cause the compiler to generate dangerous
code that could cause a crash at run-time (e.g.
R#r{a="abc",b=1}
). (Thanks to Mikael Karlsson.)
Unecessary tests (such as a 'case' with two case
branches that were identical) could cause the compiler to
crash. (Thanks to Fredrik Thulin.)
The validation pass of the compiler could generate an
error for correct code when floating point operations
were used in try/catch statements.
In bit syntax construction, any field following a
binary field would always be marked as "aligned" (which
may or may not be correct). That would cause the hipe
native compiler to generate incorrect code if the field
was in fact unaligned. (Thanks to Per Gustafsson.)
Some complex guard expressions (such as A#a.b=="";
A#a.b==undefined
) would crash the compiler. (Thanks
to Sean Hinde.)
Compilation speed has been increased for modules with
many functions and/or atoms (such as modules generated by
the asn1 application or other code generators).
Own Id: OTP-5632 Aux Id: seq10057
1.5 Compiler 4.3.8
1.5.1 Fixed Bugs and Malfunctions
-
In some circumstances, having two try/catch constructs
following each in a function body, would cause an
internal error to be generated (when in fact the
generated code was correct). (Thanks to Fredrik Thulin.)
Incorrect calls such as M:42()
would crash the
compiler. The compiler now generates a warning. (Thanks
to Ulf Wiger.)
Own Id: OTP-5553
1.5.2 Improvements and New Features
-
The new 'fun M:F/A' construct creates a fun that
refers to the latest version of M:F/A. This syntax is
meant to replace tuple funs '{M,F}' which have many
problems.
The new type test 'is_function(Fun, A)' (which may be
used in guards) test whether Fun is a fun that can be
applied with A arguments. (Currently, Fun can also be a
tuple fun.)
Own Id: OTP-5584
1.6 Compiler 4.3.7
1.6.1 Improvements and New Features
-
Further improvements of encrypted debug info: New option
'encrypt_debug_info' for compiler.
Own Id: OTP-5541 Aux Id: seq9837
1.7 Compiler 4.3.6
1.7.1 Fixed Bugs and Malfunctions
-
Fixed a bug in the validator of the generated code
(beam_validator) which caused an internal compiler error
even though the generated code was indeed correct.
Own Id: OTP-5481 Aux Id: seq9798
1.7.2 Improvements and New Features
-
It is now possible to encrypt the debug information in
Beam files, to help keep the source code secret. See the
documentation for compile on how to provide the key for
encrypting, and the documentation for beam_lib on how to
provide the key for decryption so that tools such as the
Debugger, Xref, or Cover can be used.
The beam_lib:chunks/2
functions now accepts an
additional chunk type 'compile_info
' to retrieve
the compilation information directly as a term. (Thanks
to Tobias Lindahl.)
Own Id: OTP-5460 Aux Id: seq9787
1.8 Compiler 4.3.5
1.8.1 Fixed Bugs and Malfunctions
-
Complex functions could cause the internal validator in
the compiler to generate an internal error even though
the generated code was correct.
Own Id: OTP-5436 Aux Id: seq9781
1.9 Compiler 4.3.4
1.9.1 Fixed Bugs and Malfunctions
-
In rare circumstances, inccorrect code for record or
tuple access could be generated. The incorrect code would
either trigger an internal error in the compiler or cause
an exception at run time. (Thanks to Martin Bjorklund.)
Corrected a bug in in bit syntax matching where
clauses could match in the wrong order. (Thanks to Ulf
Wiger.)
Own Id: OTP-5404 Aux Id: seq9767
1.10 Compiler 4.3.3
1.10.1 Improvements and New Features
-
Given bit syntax construction in certain complex
contexts involving a catch, the compiler would either
crash or terminate due to failure in an internal
consistency check. (Thanks to Fredrik Thulin.)
Matches
such as '<<103133:64/float>> = <<103133:64/float>>' used
to fail. Now they succeed.
Shadowing of variables in
bit syntax matches in fun heads such as in 'L = 8, F =
fun(<<L:L,B:L>>) -> B end' was handled incorrectly by the
compiler. The fun used to be compiled as if it was
written 'fun(<<8:8,B:8>>)', while it should be compiled
in the same way as 'fun(<<L:8,B:L>>)'.
A bug in the
validation pass has been corrected. It sometimes occurred
when the compiler optimized by reusing code for causing
an exception when the reused code was called from within
catch or try-catch statements. Then the validator refused
to approve the code and complained about
unknown_catch_try_state.
Corrected a bug in the
optimizer that would cause the compiler to crash. (Thanks
to Peter-Henry Mander.)
There a now warnings generated
if a bit syntax construction will fail at run-time
because of a type mismatch (e.g. <<an_atom:8>>).
Own Id: OTP-5342 Aux Id: OTP-5118, OTP-5270, OTP-5323
-
Binary pattern mattern such as 't(<<A:8>> = <<A:8>)' used
to silently fail at runtime (i.e. never match). The
compiler now generates an error for any such patterns.
Own Id: OTP-5371
1.11 Compiler 4.3.2
1.11.1 Fixed Bugs and Malfunctions
-
In rare cases, the code compiler code generate code
for a tuple match that could crash the emulator if passed
a term that was not a tuple.
If a bit syntax construction failed within a catch,
previously assigned variables could get the wrong value.
The compiler now runs a validation pass on the
generated code and aborts before writing a Beam file if
any suspect code is found. In particular, the validation
pass checks for incorrect code that may cause emulator
crashes or other strange symptoms in the emulator.
Some corrections to the unsupported feature
parameterized modules by Richard Carlsson (HiPE).
Own Id: OTP-5247 Aux Id: OTP-5235
1.12 Compiler 4.3.1
1.12.1 Fixed Bugs and Malfunctions
-
Corrected the release note regarding
try/catch
below.
try/catch
DOES work in the initial R10B release.
A few minor issues code generation issues were corrected.
Although the generated code was correct, it was slightly
slower and larger than it needed to be.
A debug printout (that could be seen in rare
circumstances) has been removed.
not record_test(not_a_tuple, RecordTag)
and
similar expressions in a guard would fail.
New options basic_validation
and
strong_validation
to do a quick check of the code
of a module.
The inline
option was not recognized if it
appeared in a -compile()
directive inside the
module.
Corrected some bugs in the undocumented feature
"parameterized modules".
Own Id: OTP-5198
-
When the undocumented feature "parameterized modules was
used, the ?MODULE macro did not work correctly.
Own Id: OTP-5224
1.13 Compiler 4.3
1.13.1 Fixed Bugs and Malfunctions
-
The semantics for boolean operators in guards have
been changed to be more consistent.
All boolean
operators will fail if given non-boolean arguments;
'true or garbage
' used to succeed but will now
fail. Also, failure in the evaluation of the operands
will also cause the guard to fail; 'true or element(1,
[])
' used to succeed but will now fail.
Semicolon
will behave as it used to. If a failure as described
above occurs, evaluation will continue with the right
operand of the semicolon.
*** POTENTIAL INCOMPATIBILITY ***
Own Id: OTP-4623
-
-compile(...)
attributes inside an Erlang module
can now contain compiler options that control warnings
(such as warn_unused_vars). They used to be ignored.
Own Id: OTP-4911
-
When a record was updated, and the record given as an
expression (such as function call), the record could be
evaluated more than once.
Own Id: OTP-4933
-
Compilation of modules with long strings could be
extremely slow.
Own Id: OTP-4960 Aux Id: seq8310
-
In bit syntax matching with clauses having guards,
sometimes the following clauses would never match if a
guard was evaluated (and failed).
Own Id: OTP-4961 Aux Id: seq8338, OTP-4891
-
Using multiple matching ('=') in the pattern for a
generator in list comprenhension would cause an internal
compiler error.
Example:
[3 || {3=4} <- []].
Own Id: OTP-5076 Aux Id: OTP-5092
-
List and string literals, and integer and character
literals were not equivalent in matching as they should
be. For instance,
f("a"=[$a])
would never match.
Own Id: OTP-5092 Aux Id: OTP-5076
1.13.2 Improvements and New Features
-
The compiler used to warn for definition of functions
having the same name as an auto-imported BIF (such as
size/1). In the R10B release, such warnings will only be
emitted if the function is NOT exported (because it will
be impossible to call it). Instead, there will be a
warning for any local call (call without module prefix)
to any (exported) function in the same module that is
also the name of an auto-imported BIF. To avoid the
warning, insert a module prefix (either 'erlang' to call
the BIF, or the name of the module to call function in
the module).
Own Id: OTP-4909
-
The unary '+' operator has been changed to throw an
'badarith' exception if its argument is not numeric (or
fail in a guard). It used its argument unchanged whatever
the type. Given the new meaning, unary '+' can now be
used to test whether a term is numeric.
*** POTENTIAL INCOMPATIBILITY ***
Own Id: OTP-4928
-
The compiler now warns for more types of suspect code,
such as expressions that will fail at run-time (such as
atom-42
), guards that are always false, or
patterns that cannot match.
Own Id: OTP-5098 Aux Id: seq8965, OTP-2456
-
The long-awaited
try
...catch
construction
is included in this release. See the reference manual
for how to use it.
Own Id: OTP-5150
1.14 Compiler 4.2.3
1.14.1 Fixed Bugs and Malfunctions
-
The compiler could generate incorrect code for receive
clauses did not use the message in any way, for instance
if a guard would ignore message depending on some
condition not based on the contents of the message (e.g.
a state variable in the "loop data").
Own Id: OTP-5050
1.15 Compiler 4.2.2
1.15.1 Fixed Bugs and Malfunctions
-
Compilation of modules with long strings could be
extremely slow.
Own Id: OTP-4960 Aux Id: seq8310
-
In bit syntax matching with clauses having guards,
sometimes the following clauses would never match if a
guard was evaluated (and failed).
Own Id: OTP-4961 Aux Id: seq8338, OTP-4891
-
In (Expr)#rec{a=A,b=B}, Expr would be evaluated more than
once.
Own Id: OTP-4962 Aux Id: seq8292
1.16 Compiler 4.2.1
1.16.1 Improvements and New Features
-
In rare circumstances, the compiler could optimize away
test that would verify that a tuple or record argument
indeed was of the correct type (resulting in an emulator
crash if the argument was not of the correct type/size).
Wrong code could also be generated for floating point
expressions.
Own Id: OTP-4790
Copyright © 1991-2006
Ericsson AB