<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html xmlns:fn="http://www.w3.org/2005/02/xpath-functions">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="../../../../doc/otp_doc.css" type="text/css">
<title>Erlang -- Compiler Release Notes</title>
</head>
<body bgcolor="white" text="#000000" link="#0000ff" vlink="#ff00ff" alink="#ff0000"><div id="container">
<script id="js" type="text/javascript" language="JavaScript" src="../../../../doc/js/flipmenu/flipmenu.js"></script><script id="js2" type="text/javascript" src="../../../../doc/js/erlresolvelinks.js"></script><script language="JavaScript" type="text/javascript">
<!--
function getWinHeight() {
var myHeight = 0;
if( typeof( window.innerHeight ) == 'number' ) {
//Non-IE
myHeight = window.innerHeight;
} else if( document.documentElement && ( document.documentElement.clientWidth ||
document.documentElement.clientHeight ) ) {
//IE 6+ in 'standards compliant mode'
myHeight = document.documentElement.clientHeight;
} else if( document.body && ( document.body.clientWidth || document.body.clientHeight ) ) {
//IE 4 compatible
myHeight = document.body.clientHeight;
}
return myHeight;
}
function setscrollpos() {
var objf=document.getElementById('loadscrollpos');
document.getElementById("leftnav").scrollTop = objf.offsetTop - getWinHeight()/2;
}
function addEvent(obj, evType, fn){
if (obj.addEventListener){
obj.addEventListener(evType, fn, true);
return true;
} else if (obj.attachEvent){
var r = obj.attachEvent("on"+evType, fn);
return r;
} else {
return false;
}
}
addEvent(window, 'load', setscrollpos);
//--></script><div id="leftnav"><div class="innertube">
<img alt="Erlang logo" src="../../../../doc/erlang-logo.png"><br><small><a href="index.html">Reference Manual</a><br><a href="release_notes.html">Release Notes</a><br><a href="../pdf/compiler-4.8.2.pdf">PDF</a><br><a href="../../../../doc/index.html">Top</a></small><p><strong>Compiler</strong><br><strong>Release Notes</strong><br><small>Version 4.8.2</small></p>
<br><a href="javascript:openAllFlips()">Expand All</a><br><a href="javascript:closeAllFlips()">Contract All</a><p><small><strong>Chapters</strong></small></p>
<ul class="flipMenu" imagepath="../../../../doc/js/flipmenu"><li id="loadscrollpos" title="Compiler Release Notes" expanded="true">Compiler Release Notes<ul>
<li><a href="notes.html">
Top of chapter
</a></li>
<li title="Compiler 4.8.2"><a href="notes.html#id61614">Compiler 4.8.2</a></li>
<li title="Compiler 4.8.1"><a href="notes.html#id57975">Compiler 4.8.1</a></li>
<li title="Compiler 4.8"><a href="notes.html#id57433">Compiler 4.8</a></li>
<li title="Compiler 4.7.5"><a href="notes.html#id57203">Compiler 4.7.5</a></li>
<li title="Compiler 4.7.4"><a href="notes.html#id56442">Compiler 4.7.4</a></li>
<li title="Compiler 4.7.3"><a href="notes.html#id56487">Compiler 4.7.3</a></li>
<li title="Compiler 4.7.2"><a href="notes.html#id56565">Compiler 4.7.2</a></li>
<li title="Compiler 4.7.1"><a href="notes.html#id56657">Compiler 4.7.1</a></li>
<li title="Compiler 4.7"><a href="notes.html#id62704">Compiler 4.7</a></li>
<li title="Compiler 4.6.5"><a href="notes.html#id62909">Compiler 4.6.5</a></li>
<li title="Compiler 4.6.4"><a href="notes.html#id65948">Compiler 4.6.4</a></li>
<li title="Compiler 4.6.3"><a href="notes.html#id66048">Compiler 4.6.3</a></li>
<li title="Compiler 4.6.2"><a href="notes.html#id66110">Compiler 4.6.2</a></li>
<li title="Compiler 4.6.1"><a href="notes.html#id66146">Compiler 4.6.1</a></li>
<li title="Compiler 4.6.0.1"><a href="notes.html#id66212">Compiler 4.6.0.1</a></li>
<li title="Compiler 4.6"><a href="notes.html#id66262">Compiler 4.6</a></li>
<li title="Compiler 4.5.5"><a href="notes.html#id66596">Compiler 4.5.5</a></li>
<li title="Compiler 4.5.4"><a href="notes.html#id66680">Compiler 4.5.4</a></li>
<li title="Compiler 4.5.3"><a href="notes.html#id66711">Compiler 4.5.3</a></li>
<li title="Compiler 4.5.2.1"><a href="notes.html#id66749">Compiler 4.5.2.1</a></li>
<li title="Compiler 4.5.2"><a href="notes.html#id66780">Compiler 4.5.2</a></li>
<li title="Compiler 4.5.1.1"><a href="notes.html#id66849">Compiler 4.5.1.1</a></li>
<li title="Compiler 4.5.1"><a href="notes.html#id66942">Compiler 4.5.1</a></li>
<li title="Compiler 4.5"><a href="notes.html#id67122">Compiler 4.5</a></li>
<li title="Compiler 4.4.5"><a href="notes.html#id67394">Compiler 4.4.5</a></li>
<li title="Compiler 4.4.4"><a href="notes.html#id67459">Compiler 4.4.4</a></li>
<li title="Compiler 4.4.3"><a href="notes.html#id67492">Compiler 4.4.3</a></li>
<li title="Compiler 4.4.2.1"><a href="notes.html#id67574">Compiler 4.4.2.1</a></li>
<li title="Compiler 4.4.2"><a href="notes.html#id67607">Compiler 4.4.2</a></li>
<li title="Compiler 4.4.1"><a href="notes.html#id67734">Compiler 4.4.1</a></li>
<li title="Compiler 4.4"><a href="notes.html#id67810">Compiler 4.4</a></li>
<li title="Compiler 4.3.12"><a href="notes.html#id68007">Compiler 4.3.12</a></li>
<li title="Compiler 4.3.11"><a href="notes.html#id68065">Compiler 4.3.11</a></li>
<li title="Compiler 4.3.10"><a href="notes.html#id68102">Compiler 4.3.10</a></li>
<li title="Compiler 4.3.9"><a href="notes.html#id68194">Compiler 4.3.9</a></li>
<li title="Compiler 4.3.8"><a href="notes.html#id68262">Compiler 4.3.8</a></li>
<li title="Compiler 4.3.7"><a href="notes.html#id68361">Compiler 4.3.7</a></li>
<li title="Compiler 4.3.6"><a href="notes.html#id68397">Compiler 4.3.6</a></li>
<li title="Compiler 4.3.5"><a href="notes.html#id68478">Compiler 4.3.5</a></li>
<li title="Compiler 4.3.4"><a href="notes.html#id68512">Compiler 4.3.4</a></li>
<li title="Compiler 4.3.3"><a href="notes.html#id68551">Compiler 4.3.3</a></li>
<li title="Compiler 4.3.2"><a href="notes.html#id68658">Compiler 4.3.2</a></li>
<li title="Compiler 4.3.1"><a href="notes.html#id68708">Compiler 4.3.1</a></li>
</ul>
</li></ul>
</div></div>
<div id="content">
<div class="innertube">
<h1>1 Compiler Release Notes</h1>
<p>This document describes the changes made to the Compiler
application.</p>
<h3><a name="id61614">1.1
Compiler 4.8.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Modules with very many functions would compile very
slowly.</p>
<p>
Own Id: OTP-10123</p>
</li>
<li>
<p>
<span class="code">compile:forms/2</span> will now use a
{source,SourceFilePath} to set the source returned by
<span class="code">module_info(compile)</span> (Thanks to José Valim)</p>
<p>
Own Id: OTP-10150</p>
</li>
<li>
<p>
A process which had enabled trap_exit would receive EXIT
messages after calling the compiler. (Thanks to Jeremy
Heater.)</p>
<p>
Own Id: OTP-10171</p>
</li>
<li>
<p>
Fix messages ordering with column numbers</p>
<p>
Own Id: OTP-10183</p>
</li>
<li>
<p>
sys_pre_expand: Fix BASE never being set</p>
<p>
Commit a612e99fb5aaa934fe5a8591db0f083d7fa0b20a turned
module attributes from 2-tuples to 3-tuples but forgot to
update get_base/1, breaking BASE for parametric modules.</p>
<p>
Own Id: OTP-10184</p>
</li>
<li>
<p>
The compiler will now issue a warning if literal tuple
funs are used. For example, {erlang,is_tuple}(X) will now
generate a warning.</p>
<p>
Own Id: OTP-10185</p>
</li>
<li>
<p>
The compiler will now warn for illegal sizes for segments
in binary construction. For example,
<<X:(2.5)>> will now cause the compiler to
issue a warning.</p>
<p>
Own Id: OTP-10197</p>
</li>
<li>
<p>
Fix the erlc -MP flag</p>
<p>
Because of a copy-and-paste error in erlc.c, the -MP flag
had the same effect as -MG. As a workaround, you had to
pass +makedep_phony to enable the MP option. This patch
makes -MP work as intended.</p>
<p>
Own Id: OTP-10211</p>
</li>
</ul>
<h3><a name="id57975">1.2
Compiler 4.8.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
In rare circumstance, the compiler could crash when
compiling a case statement. (Thanks to Hakan Mattsson.)</p>
<p>
Own Id: OTP-9842</p>
</li>
<li>
<p>Calling a guard test (such as is_list/1) from the
top-level in a guard, would cause a compiler crash if
there was a local definition with the same name.
Corrected to reject the program with an error
message.</p>
<p>
Own Id: OTP-9866</p>
</li>
<li>
<p>Using <span class="code">get/1</span> in a <span class="code">try</span> block could in some
cases cause an internal compiler error. (Thanks to Eric
Merritt.)</p>
<p>
Own Id: OTP-9867</p>
</li>
<li>
<p>
An unexported on_load function would not get run if the
module was compiled with the <span class="code">inline</span> option.
(Thanks to Yiannis Tsiouris.)</p>
<p>
Own Id: OTP-9910</p>
</li>
<li>
<p>
Fixed a discrepancy in compile_info</p>
<p>
The BEAM disassembler used the atom 'none' to signify the
absence of a compile_info chunk in a .beam file. This
clashed with the type declaration of the compile_info
field of a #beam_file{} record as containing a list. Now
[] signifies the absence of this chunk. This simplifies
the code and avoids a dialyzer warning.</p>
<p>
Own Id: OTP-9917</p>
</li>
<li>
<p>
Fix typo in `compile' doc: unmatched parenthesis (Thanks
to Ricardo Catalinas Jiménez)</p>
<p>
Own Id: OTP-9919</p>
</li>
<li>
<p>In a <span class="code">try</span>...<span class="code">catch</span> statement that always
returned <span class="code">false</span>, the compiler would remove calls to
BIFs that could not cause an exception (such as
<span class="code">put/2</span>). Example of such code: <span class="code">try put(K, V),
false catch _:_ -> false end.</span></p>
<p>
Own Id: OTP-9982</p>
</li>
</ul>
<h3><a name="id57433">1.3
Compiler 4.8</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Add '-callback' attributes in stdlib's behaviours</p>
<p>
Replace the behaviour_info(callbacks) export in stdlib's
behaviours with -callback' attributes for all the
callbacks. Update the documentation with information on
the callback attribute Automatically generate
'behaviour_info' function from '-callback' attributes</p>
<p>
'behaviour_info(callbacks)' is a special function that is
defined in a module which describes a behaviour and
returns a list of its callbacks.</p>
<p>
This function is now automatically generated using the
'-callback' specs. An error is returned by lint if user
defines both '-callback' attributes and the
behaviour_info/1 function. If no type info is needed for
a callback use a generic spec for it. Add '-callback'
attribute to language syntax</p>
<p>
Behaviours may define specs for their callbacks using the
familiar spec syntax, replacing the '-spec' keyword with
'-callback'. Simple lint checks are performed to ensure
that no callbacks are defined twice and all types
referred are declared.</p>
<p>
These attributes can be then used by tools to provide
documentation to the behaviour or find discrepancies in
the callback definitions in the callback module.</p>
<p>
Add callback specs into 'application' module in kernel
Add callback specs to tftp module following internet
documentation Add callback specs to inets_service module
following possibly deprecated comments</p>
<p>
Own Id: OTP-9621</p>
</li>
<li>
<p>
The calculation of the 'uniq' value for a fun (see
<span class="code">erlang:fun_info/1</span>) was too weak and has been
strengthened. It used to be based on the only the code
for the fun body, but it is now based on the MD5 of the
BEAM code for the module.</p>
<p>
Own Id: OTP-9667</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>Variables are now now allowed in '<span class="code">fun M:F/A</span>' as
suggested by Richard O'Keefe in EEP-23.</p>
<p>The representation of '<span class="code">fun M:F/A</span>' in the
abstract format has been changed in an incompatible way.
Tools that directly read or manipulate the abstract
format (such as parse transforms) may need to be updated.
The compiler can handle both the new and the old format
(i.e. extracting the abstract format from a pre-R15 BEAM
file and compiling it using compile:forms/1,2 will work).
The <span class="code">syntax_tools</span> application can also handle both
formats.</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-9643</p>
</li>
<li>
<p>
<span class="code">filename:find_src/1,2</span> will now work on stripped
BEAM files (reported by Per Hedeland). The HiPE compiler
will also work on stripped BEAM files. The BEAM compiler
will no longer include compilation options given in the
source code itself in <span class="code">M:module_info(compile)</span>
(because those options will be applied anyway if the
module is re-compiled).</p>
<p>
Own Id: OTP-9752</p>
</li>
<li>
<p>Inlining binary matching could cause an internal
compiler error. (Thanks to Rene Kijewski for reporting
this bug.)</p>
<p>
Own Id: OTP-9770</p>
</li>
</ul>
<h3><a name="id57203">1.4
Compiler 4.7.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Compiler options given in the source code using a
<span class="code">-compile()</span> attribute used to be included twice in
<span class="code">Mod:module_info(compile)</span>. They are now only
included once at the beginning of the list of options.</p>
<p>
Own Id: OTP-9534</p>
</li>
<li>
<p>
beam_disasm: Handle stripped BEAM files</p>
<p>
beam_disasm:file/1 would crash if asked to disassemble a
stripped BEAM file without an "Attr" chunk. (Thanks to
Haitao Li)</p>
<p>
Own Id: OTP-9571</p>
</li>
</ul>
<h3><a name="id56442">1.5
Compiler 4.7.4</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
If a variable is matched out in binary matching and used
as the size for a binary element, it would seem to be
unbound if used in a subsequent match operation. (Thanks
to Bernard Duggan.)</p>
<p>
Own Id: OTP-9134</p>
</li>
<li>
<p>Eliminate incorrect warning in
<span class="code">sys_core_fold</span></p>
<p>
Own Id: OTP-9152</p>
</li>
</ul>
<h3><a name="id56487">1.6
Compiler 4.7.3</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
The <span class="code">-export_type()</span> directive is no longer included
among the attributes.</p>
<p>
Own Id: OTP-8998</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The maximum number of allowed arguments for an Erlang
function has been lowered from 256 to 255, so that the
number of arguments can now fit in a byte.</p>
<p>
Own Id: OTP-9049</p>
</li>
<li>
<p>
Dependency generation for Makefiles has been added to the
compiler and erlc. See the manual pages for
<span class="code">compile</span> and <span class="code">erlc</span>. (Thanks to Jean-Sebastien
Pedron.)</p>
<p>
Own Id: OTP-9065</p>
</li>
</ul>
<h3><a name="id56565">1.7
Compiler 4.7.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Two compiler bugs (that would cause the compiler to
terminate) reported by Christopher Williams have been
fixed.</p>
<p>
Own Id: OTP-8949</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>The compiler would translate binary comprehensions
containing tail segments in a way that would would
confuse Dialyzer. For instance:</p>
<p><span class="code">[42 || <<_:8/integer, _/bits>> <=
Bits]</span></p>
<p>
would produce a Dialyzer warning.</p>
<p>
Own Id: OTP-8864</p>
</li>
<li>
<p>
Code such as <span class="code">foo(A) -> <<A:0>></span>
would crash the compiler.</p>
<p>
Own Id: OTP-8865</p>
</li>
<li>
<p>
The compiler could fail with an internal error when
variables were exported from a receive block but the
return value of the receive block were not used. (Thanks
to Jim Engquist for reporting this error.)</p>
<p>
Own Id: OTP-8888</p>
</li>
</ul>
<h3><a name="id56657">1.8
Compiler 4.7.1</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
Eliminated warnings for auto-imported BIF clashes.</p>
<p>
Own Id: OTP-8840</p>
</li>
</ul>
<h3><a name="id62704">1.9
Compiler 4.7</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Several problems in the inliner have been fixed.</p>
<p>
Own Id: OTP-8552</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The module binary from EEP31 (and EEP9) is implemented.</p>
<p>
Own Id: OTP-8217</p>
</li>
<li>
<p>Local and imported functions now override the
auto-imported BIFs when the names clash. The pre R14
behaviour was that auto-imported BIFs would override
local functions. To avoid that old programs change
behaviour, the following will generate an error:</p>
<ul>
<li><p>Doing a call without explicit module name
to a local function having a name clashing with the name
of an auto-imported BIF that was present (and
auto-imported) before OTP R14A</p></li>
<li><p>Explicitly importing a function having a name
clashing with the name of an autoimported BIF that was
present (and autoimported) before OTP R14A</p></li>
<li><p>Using any form of the old compiler directive
<span class="code">nowarn_bif_clash</span></p></li> </ul> <p>If the BIF
was added or auto-imported in OTP R14A or later,
overriding it with an import or a local function will
only result in a warning,</p> <p>To resolve clashes, you
can either use the explicit module name <span class="code">erlang</span> to
call the BIF, or you can remove the auto-import of that
specific BIF by using the new compiler directive
<span class="code">-compile({no_auto_import,[F/A]}).</span>, which makes all
calls to the local or imported function without explicit
module name pass without warnings or errors.</p> <p>The
change makes it possible to add auto-imported BIFs
without breaking or silently changing old code in the
future. However some current code ingeniously utilizing
the old behaviour or the <span class="code">nowarn_bif_clash</span> compiler
directive, might need changing to be accepted by the
compiler.</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-8579</p>
</li>
<li>
<p>The undocumented, unsupport, and deprecated function
<span class="code">lists:flat_length/1</span> has been removed.</p>
<p>
Own Id: OTP-8584</p>
</li>
<li>
<p>Nested records can now be accessed without
parenthesis. See the Reference Manual for examples.
(Thanks to YAMASHINA Hio and Tuncer Ayaz.)</p>
<p>
Own Id: OTP-8597</p>
</li>
<li>
<p>It is now possible to suppress the warning in code
such as "<span class="code">list_to_integer(S), ok</span>" by assigning the
ignored value "_" like this: "<span class="code">_ = list_to_integer(S),
ok</span>".</p>
<p>
Own Id: OTP-8602</p>
</li>
<li>
<p><span class="code">receive</span> statements that can only read out a
newly created reference are now specially optimized so
that it will execute in constant time regardless of the
number of messages in the receive queue for the process.
That optimization will benefit calls to
<span class="code">gen_server:call()</span>. (See <span class="code">gen:do_call/4</span> for
an example of a receive statement that will be
optimized.)</p>
<p>
Own Id: OTP-8623</p>
</li>
<li>
<p>The compiler optimizes record operations better.</p>
<p>
Own Id: OTP-8668</p>
</li>
</ul>
<h3><a name="id62909">1.10
Compiler 4.6.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Using complex boolean expressions in ifs could cause the
compiler to either crash or teminate with an internal
error. (Thanks to Simon Cornish.)</p>
<p>
Own Id: OTP-8338</p>
</li>
<li>
<p>Bit string comprehensions can now be used in
parameterized modules. (Thanks to Jebu Ittiachen.)</p>
<p>
Own Id: OTP-8447</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The expected return value for an on_load function has
been changed. (See the section about code loading in the
Reference manual.)</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-8339</p>
</li>
<li>
<p>
In rare circumstances when using garbaging collecting
guard BIFs, the validation pass (beam_validator) would
signal that the code was unsafe, when it in fact was
correct. (Thanks to Kiran Khaladkar.)</p>
<p>
Own Id: OTP-8378</p>
</li>
<li>
<p>
The <span class="code">-Werror</span> option for <span class="code">erlc</span> and the
compiler option <span class="code">warnings_as_errors</span> will cause
warnings to be treated as errors. (Thanks to Christopher
Faulet.)</p>
<p>
Own Id: OTP-8382</p>
</li>
<li>
<p>Macros overloading has been implemented. (Thanks to
Christopher Faulet.)</p>
<p>
Own Id: OTP-8388</p>
</li>
</ul>
<h3><a name="id65948">1.11
Compiler 4.6.4</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The compiler's 'E' option now works with modules with
types and specifications.</p>
<p>
Own Id: OTP-8238 Aux Id: OTP-8150 </p>
</li>
<li>
<p>
Certain uses of binary matching in a
<span class="code">begin</span>-<span class="code">end</span> in a list comprehension could
cause the compiler to crash or generate incorrect code.</p>
<p>
Own Id: OTP-8271</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The documentation is now built with open source tools
(xsltproc and fop) that exists on most platforms. One
visible change is that the frames are removed.</p>
<p>
Own Id: OTP-8201</p>
</li>
<li>
<p>
The compiler could crash if invalid calls to is_record/2
was used in (for example) a list comprehension. (Thanks
to Tobias Lindahl.)</p>
<p>
Own Id: OTP-8269</p>
</li>
<li>
<p>The -on_load() directive can be used to run a function
when a module is loaded. It is documented in the section
about code loading in the Reference Manual.</p>
<p>
Own Id: OTP-8295</p>
</li>
</ul>
<h3><a name="id66048">1.12
Compiler 4.6.3</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>Corrected liveness optimization to eliminate a
compiler crash that could occur when compiling bit syntax
construction code. (Thanks to Mikage Sawatari.)</p>
<p>Calling BIFs such as <span class="code">length/1</span> in guard context
in a try/catch block could cause a compiler crash.
(Thanks to Paul Fisher.)</p>
<p>Using filter expressions containing <span class="code">andalso</span> or
<span class="code">orelse</span> in a list comprehension could cause a
compiler crash. (Thanks to Martin Engström.)</p>
<p>
Own Id: OTP-8054</p>
</li>
<li>
<p>
A guard with nested 'not' operators could cause the
compiler to crash. (Thanks to Tuncer Ayaz.)</p>
<p>
Own Id: OTP-8131</p>
</li>
</ul>
<h3><a name="id66110">1.13
Compiler 4.6.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
The compiler would crash while compiling certain complex
function bodies containing <span class="code">receive after</span> due to a
bug in the jump optimizer (a label that had only had
backward references could still be removed). (Thanks to
Vincent de Phily.)</p>
<p>
Own Id: OTP-7980</p>
</li>
</ul>
<h3><a name="id66146">1.14
Compiler 4.6.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Miscellaneous minor bugs fixed.</p>
<p>
Own Id: OTP-7937</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
There will be more efficient code if there is a clause
that matches the empty binary and no other clauses that
matches non-empty binaries.</p>
<p>
Own Id: OTP-7924</p>
</li>
<li>
<p>There is new option to allow a module to have a module
name other than the filename. Do not use it unless you
know what you are doing.</p>
<p>
Own Id: OTP-7927</p>
</li>
</ul>
<h3><a name="id66212">1.15
Compiler 4.6.0.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Using <span class="code">andalso</span>/<span class="code">orelse</span> or record access in
a <span class="code">try</span>...<span class="code">catch</span> could cause a compiler
crash.</p>
<p>Som large and complex functions could require
extremely long compilation times (hours or days).</p>
<p>
Own Id: OTP-7905</p>
</li>
</ul>
<h3><a name="id66262">1.16
Compiler 4.6</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
For some complex guards which used
<span class="code">andalso</span>/<span class="code">orelse</span>, the compiler would crash.
(Thanks to Hunter Morris.)</p>
<p>
Own Id: OTP-7679</p>
</li>
<li>
<p>
Code that (incorrectly) used the the value of nested
applications of <span class="code">setelement/3</span> in bit syntax
construction could crash the compiler.</p>
<p>
Own Id: OTP-7690</p>
</li>
<li>
<p>Modules containing huge integers (consisting of
several hundreds of thousands of digits or more) could be
slow to compile. This problem has been corrected.</p>
<p>
Own Id: OTP-7707 Aux Id: seq11129 </p>
</li>
<li>
<p>If the generator in a list comprehension is given a
non-list term, there will now be <span class="code">function_clause</span>
exception instead of a <span class="code">case_clause</span> exception (as
it was in all releases before R12B).</p>
<p>
Own Id: OTP-7844</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The compiler could crash if the size for a binary segment
in matching was a complex literal such as binary or
tuple.</p>
<p>
Own Id: OTP-7650</p>
</li>
<li>
<p>
The compiler generates more compact and faster code for
matching of complex constants (such as constant lists and
tuples).</p>
<p>
Own Id: OTP-7655</p>
</li>
<li>
<p>
The undocumented, unsupported, and deprecated guard BIF
<span class="code">is_constant/1</span> has been removed.</p>
<p>
*** INCOMPATIBILITY with R12B ***</p>
<p>
Own Id: OTP-7673</p>
</li>
<li>
<p>The compiler generates better code for many guard
expressions, and especially for guards that use
<span class="code">andalso</span>/<span class="code">orelse</span> or record fields.</p>
<p>(In technical terms, <span class="code">andalso</span>/<span class="code">orelse</span> in a
guard would case the creation of a stack frame and saving
of all x registers that could potentially be alive after
the guard and restoring all x registers before leaving
the guard. For certain guards, far too many x registers
were saved and subsequently restored. In this version of
the compiler, no stack frame is created and no x
registers are saved and restored.)</p>
<p>
Own Id: OTP-7718</p>
</li>
<li>
<p>The default size for the resulting binary created by a
binary comprehension was 64Kb in R12B (it would grow if
needed). This was often far too much. In this release,
the default is changed to 256 bytes. Furthermore, for
most binary comprehensions without filters, the exact
size of the resulting binary can be calculated beforehand
and the compiler now generates code that does that
calculation.</p>
<p>
Own Id: OTP-7737</p>
</li>
<li>
<p>The short-circuit operators <span class="code">andalso</span> and
<span class="code">orelse</span> no longer guarantees that their second
argument is either <span class="code">true</span> or <span class="code">false</span>. As a
consequence, <span class="code">andalso</span>/<span class="code">orelse</span> are now
tail-recursive.</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-7748</p>
</li>
<li>
<p>The compiler will refuse to a compile file where the
module name in the file differs from the output file
name.</p>
<p>When compiling using <span class="code">erlc</span>, the current working
directory will no be included in the code path (unless
explicitly added using "-pa .").</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-7793</p>
</li>
<li>
<p>There will no longer be any warnings for list
comprehensions without generators, as such list
comprehension have turned out to be useful.</p>
<p>
Own Id: OTP-7846</p>
</li>
<li>
<p>Warnings for obsolete guard tests are now turned on.
(That is, writing <span class="code">list(L)</span> in a guard instead of
<span class="code">is_list(L)</span> will generate a warning.)</p>
<p>The warnings can be turned off using the
<span class="code">nowarn_obsolete_guard</span> option.</p>
<p>
Own Id: OTP-7850</p>
</li>
<li>
<p>The copyright notices have been updated.</p>
<p>
Own Id: OTP-7851</p>
</li>
<li>
<p>If a module contains an exported function with the
same name as an auto-imported BIF (such as
<span class="code">length/1</span>), any calls to the BIF must have an
explicit <span class="code">erlang:</span> prefix, or there will be a
compilation error (such calls would only generate a
warning in previous releases).</p>
<p>(The reason for the change is to avoid breaking code
in a future major release, R14 or R15, in which we plan
to make calls without a module prefix always call the
local function in the same module even if there is an
auto-imported BIF with the same name.)</p>
<p>
*** POTENTIAL INCOMPATIBILITY ***</p>
<p>
Own Id: OTP-7873</p>
</li>
</ul>
<h3><a name="id66596">1.17
Compiler 4.5.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Matching on a zero-width segment in the bit syntax
would crash the compiler. (Thanks to Will.)</p>
<p>
Own Id: OTP-7591</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
In bit syntax expressions which started with a binary
segment, and was followed by at least two segments of
variable size, too little space could be allocated for
the binary, leading to memory corruption.</p>
<p>
Own Id: OTP-7556</p>
</li>
<li>
<p>In user-defined attributes, <span class="code">Name/Arity</span> is now
allowed and will be translated to <span class="code">{Name,Arity}</span>.
(An implementation of EEP-24 by Richard O'Keefe.)</p>
<p>The <span class="code">module_info/{0,1}</span> functions automatically
inserted into each compiled modules are now documented in
the Modules section in the Reference Manual.</p>
<p>
Own Id: OTP-7586</p>
</li>
</ul>
<h3><a name="id66680">1.18
Compiler 4.5.4</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
Certain complex bit syntax matching operations matching
out binaries and having several clauses could give
incorrect results (the matched out binaries were too
short). (Thanks to Christian von Roques for bug report
and correction.)</p>
<p>
Own Id: OTP-7498</p>
</li>
</ul>
<h3><a name="id66711">1.19
Compiler 4.5.3</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
New option <span class="code">warn_export_all</span> to warn for a module
using <span class="code">export_all</span>. (Thanks to Richard Carlsson.)</p>
<p>
Own Id: OTP-7392</p>
</li>
</ul>
<h3><a name="id66749">1.20
Compiler 4.5.2.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
In rare circumstances, the length/1 BIF (and a few other
guard BIFs) would seem to return an incorrect value (of
any type).</p>
<p>
Own Id: OTP-7345 Aux Id: seq10962 </p>
</li>
</ul>
<h3><a name="id66780">1.21
Compiler 4.5.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>A bug in the old inliner has been fixed. Some
undocumented functionality has been removed.</p>
<p>
Own Id: OTP-7223</p>
</li>
<li>
<p>Matching several binary patterns in parallel using the
'=' operator is not allowed (an implementation
limitation), but the compiler did not reject all such
attempts (depending on the patterns, the generated code
might or might not work correctly). Now the compiler
rejects all binary patterns joined by '='.</p>
<p>
Own Id: OTP-7227</p>
</li>
<li>
<p>Complex combinations of record operations and binary
matching could cause the compiler to crash. (Thanks to
Vladimir Klebansky.)</p>
<p>
Own Id: OTP-7233</p>
</li>
<li>
<p>
In rare circumstances, mixing binary matching clauses
with clauses matching other data types, the compiler
could crash.</p>
<p>
Own Id: OTP-7240 Aux Id: seq10916 </p>
</li>
</ul>
<h3><a name="id66849">1.22
Compiler 4.5.1.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
Corrected a compiler bug that could cause a complex
binary matching operation to fail when it shouldn't.
(Thanks to Tomas Stejskal.)</p>
<p>
Own Id: OTP-7188</p>
</li>
<li>
<p>
In unusual circumstances, the environment for a fun could
bind wrong values.</p>
<p>
Own Id: OTP-7202 Aux Id: seq10887 </p>
</li>
<li>
<p>Long sequences of list comprehensions without
generators joined by the '++' operator would cause a code
expansion explosion, which could cause the compiler to
run out of memory. To resolve this problem, in
'<span class="code">[...||...]++Expr</span>', <span class="code">Expr</span> is now evaluated
before the list comprehension. This change <strong>is</strong>
backwards compatible (see the following note about
evaluation order if you have doubts).</p>
<p>Note about evaluation order: The Reference manual says
that subexpressions are evaluated <strong>in any order</strong>
before the expression itself. Therefore, in an expression
such as '<span class="code">LeftExpr++RightExpr</span>', you should not
depend on <span class="code">LeftExpr</span> being evaluated before
<span class="code">RightExpr</span> or vice versa. The evaluation order is
only important if the expressions contains and/or depends
on operations with side-effects, such as message passing
or <span class="code">ets</span> operations.</p>
<p>
Own Id: OTP-7206</p>
</li>
</ul>
<h3><a name="id66942">1.23
Compiler 4.5.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>
A match expression inside a function call could cause a
false "a term is constructed but never used" warning.</p>
<p>
Own Id: OTP-7018 Aux Id: seq10824 </p>
</li>
<li>
<p>The compiler could crash if a binary tail was matched
out, and then used in a binary append operation. (Thanks
to Oleg Avdeev.)</p>
<p>Similarly, the compiler could crash if a binary tail
was matched out, and then used (incorrectly) in binary
construction in an integer field. (Thanks to Fredrik
Svahn.) Or was incorrectly used in a float field. Or was
used in a binary field with a given length. (Thanks to
Chih - Wei Yu.) </p>
<p>
Own Id: OTP-7022</p>
</li>
<li>
<p>
Matching an empty binary in a record and then using the
same record again could cause a compiler crash. (Thanks
to Fredrik Thulin.)</p>
<p>
Own Id: OTP-7029</p>
</li>
<li>
<p>In rare circumstances, constants containing floating
points and integers could be confused. Example:</p>
<p><span class="code">f(a) -> [1]; f(b) -> [1.0].</span></p>
<p>Both <span class="code">f(a)</span> and <span class="code">f(b)</span> would return
<span class="code">[1]</span>.</p>
<p>
Own Id: OTP-7073</p>
</li>
<li>
<p>Some bit syntax code such as</p>
<p><span class="code">matching d(_,<$lt;$gt;$gt;) -> one; d(0,<$lt;D$gt;$gt;)
->two.</span></p>
<p>could crash the compiler. (Thanks to Simon
Cornish.)</p>
<p>
Own Id: OTP-7094</p>
</li>
<li>
<p>
In unusual circumstances, a call to a fun could fail due
to an unsafe optimization. (Thanks to Simon Cornish.)</p>
<p>
Own Id: OTP-7102</p>
</li>
<li>
<p>
Bit syntax matching with a guard containing two or more
uses of andalso/orelse could cause the compiler to crash.
(Thanks to Mateusz Berezecki.)</p>
<p>
Own Id: OTP-7113</p>
</li>
<li>
<p>
This was only a problem if you generated or wrote your
own Core Erlang code: The Core Erlang optimizer code
could move nested calls such as
<span class="code">erlang:'$lt;'(erlang:length(L), 2)</span> as case expression
into a guard, which would change the semantics. (Thanks
to Robert Virding.)</p>
<p>
Own Id: OTP-7117</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
The compiler could generate suboptimal code for record
updates if the record update code consisted of multiple
source code lines.</p>
<p>
Own Id: OTP-7101</p>
</li>
</ul>
<h3><a name="id67122">1.24
Compiler 4.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The compiler used to allow that a binary field without
size could be used in other positions than at the end in
bit syntax pattern. For instance,
<span class="code"><<B/binary,EmptyBinary/binary>> = Bin</span>
used to compile, but now the compilation will fail with
an an error message.</p>
<p>Also, it is now longer permitted to give a literal
string in a binary pattern a type or a size; for
instance, <span class="code"><<"abc"/binary>> = Bin</span> will
no longer compile. (In previous releases, there would
always be a <span class="code">badmatch</span> exception at run-time.)</p>
<p>
Own Id: OTP-6885</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>
Bitstrings (bit-level) binaries and binary comprehensions
are now part of the language. See the Reference Manual.</p>
<p>
Own Id: OTP-6558</p>
</li>
<li>
<p>
The '<span class="code">compressed</span>' option for the compiler has been
documented.</p>
<p>
Own Id: OTP-6801</p>
</li>
<li>
<p>If the value of a list comprehension is not used, such
as in '<span class="code">[do_something(X) || X <- List], ok</span>', a
result list will no longer be built. For more details,
see the Efficiency Guide.</p>
<p>If the value of an expression is not used, and the
expression has no side effects except for possibly
throwing an exception, a warning will be generated.
Examples: '<span class="code">self(),ok</span>' and
'<span class="code">{error,Reason},ok</span>'.</p>
<p>
Own Id: OTP-6824</p>
</li>
<li>
<p>
Three new functions have been added to the <span class="code">compile</span>
module: <span class="code">noenv_file/2</span>, <span class="code">noenv_forms/2</span>, and
<span class="code">noenv_output_generated/1</span>.</p>
<p>
Own Id: OTP-6829</p>
</li>
<li>
<p>Many bit syntax operations, both construction and
matching, are faster. For further information, see the
Efficiency Guide.</p>
<p>
Own Id: OTP-6838</p>
</li>
<li>
<p>Literal lists, tuples, and binaries are no longer
constructed at run-time as they used to be, but are
stored in a per-module constant pool. Literals that are
used more than once are stored only once.</p>
<p>This is not a change to the language, only in the
details of its implementation. Therefore, the
implications of this change is described in the
Efficiency Guide.</p>
<p>Example 1: In the expression <span class="code">element(BitNum-1,
{1,2,4,8,16,32,64,128})</span>, the tuple used to be
constructed every time the expression was executed, which
could be detrimental to performance in two ways if the
expression was executed in a loop: the time to build the
tuple itself and the time spent in garbage collections
because the heap filled up with garbage faster.</p>
<p>Example 2: Literal strings, such as <span class="code">"abc"</span>, used
to be stored in the compiled code compactly as a byte
string and expanded to a list at run-time. Now all
strings will be stored expanded to lists (such as
<span class="code">[$a,$b,$c]</span>) in the constant pool. That means that
the string will be faster to use at run-time, but that it
will require more space even when not used. If space is
an issue, you might want to use binary literals (that is,
<span class="code"><<"abc"<<</span>) instead of string literals for
infrequently used long strings (such as error
messages).</p>
<p>
Own Id: OTP-6850</p>
</li>
<li>
<p>
Recursive calls now usually consume less stack than in
R11B. See the Efficiency Guide.</p>
<p>
Own Id: OTP-6862 Aux Id: seq10746 </p>
</li>
<li>
<p>Two new guard BIFs have been introduced as a
recommended replacement for <span class="code">size/1</span>. (The
<span class="code">size/1</span> BIF will be removed no earlier than in
R14B.) The BIFs are <span class="code">tuple_size/1</span> to calculate the
size of a tuple and <span class="code">byte_size/1</span> to calculate the
number of bytes needed for the contents of the binary or
bitstring (rounded up to the nearest number of bytes if
necessary).</p>
<p>There is also a new <span class="code">bit_size/1</span> BIF that returns
the exact number of bits that a binary or bitstring
contains.</p>
<p>
Own Id: OTP-6902</p>
</li>
<li>
<p>
The two internal functions <span class="code">erl_bifs:is_bif/3</span> and
<span class="code">erl_bifs:is_guard/3</span> have been removed. They were
unsupported, undocumented, and unmaintained.</p>
<p>
Own Id: OTP-6966</p>
</li>
</ul>
<h3><a name="id67394">1.25
Compiler 4.4.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The compiler would crash if you tried to combine to
non-list literals with '<span class="code">++</span>' (for instance,
<span class="code">an_atom++"string"</span>).</p>
<p>Own Id: OTP-6630 Aux Id: seq10635 </p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>Minor Makefile changes.</p>
<p>Own Id: OTP-6689</p>
</li>
</ul>
<h3><a name="id67459">1.26
Compiler 4.4.4</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Incorrect code could be generated for bit syntax matching
if the old inliner was used with aggressive settings.</p>
<p>Own Id: OTP-6461</p>
</li>
</ul>
<h3><a name="id67492">1.27
Compiler 4.4.3</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The R10B compiler could generate unsafe
<span class="code">bs_save/bs_restore</span> instructions that could cause
memory corruption. (The R11B compiler does not have that
problem.) The erlang emulator will now refuse to load
R10B-compiled modules that contain such unsafe
<span class="code">bs_save/bs_restore</span> instructions. In addition, the
beam_validator module in the compiler will also reject
such instructions (in case it is used to validate R10B
code). (Thanks to Matthew Reilly.)</p>
<p>Own Id: OTP-6386</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>Directives for parse transforms that have been run are
now removed from the abstract code stored when the
debug_info option is given, to prevent the parse
transforms to be run again.</p>
<p>Own Id: OTP-5344</p>
</li>
<li>
<p>Minor improvements in code generation for some guards
expression involving boolean expressions.</p>
<p>Own Id: OTP-6347</p>
</li>
</ul>
<h3><a name="id67574">1.28
Compiler 4.4.2.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The compiler could generate incorrect code for bit syntax
matching consisting of several clauses.</p>
<p>Own Id: OTP-6392 Aux Id: seq10539 </p>
</li>
</ul>
<h3><a name="id67607">1.29
Compiler 4.4.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Defining a fun itself containing a fun in an
<span class="code">after</span> block of a <span class="code">try</span> would cause the
compiler to crash or generate incorrect code. (Thanks to
Tim Rath.)</p>
<p>Shorter compilation times for modules containing with
an extreme number of functions (10000 functions or more).</p>
<p>(The compiled could generate deprecated instructions
for certain bit syntax matching operations.)</p>
<p>Own Id: OTP-6212 Aux Id: seq10446 </p>
</li>
<li>
<p>Fixed several bugs that would cause warnings to be shown
without file name and line number.</p>
<p>Own Id: OTP-6260 Aux Id: seq10461 </p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>The <span class="code">strict_record_tests</span> option is now default;
that is, reading a field from a record using the
<span class="code">Record#record_tag.field</span> syntax will fail if
<span class="code">Record</span> is not a record of the correct type.</p>
<p>If necessary, the record tests can be turned off by
giving the <span class="code">no_strict_record_tests</span> option. To avoid
editing Makefiles, the environment variable
<span class="code">ERL_COMPILER_OPTIONS</span> can be set to
"<span class="code">no_strict_record_tests</span>".</p>
<p>The <span class="code">no_strict_record_tests</span> option will probably
be removed in the R12B release.</p>
<p>*** POTENTIAL INCOMPATIBILITY ***</p>
<p>Own Id: OTP-6294</p>
</li>
</ul>
<h3><a name="id67734">1.30
Compiler 4.4.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>The compiler used to crash if a module contained code
similar to '<span class="code">fun(1=0) -> ok end</span>'. (Thanks to
Richard Carlsson.)</p>
<p>The compiler would spend really long time compiling
bit syntax expressions such as
'<span class="code"><<1:(50*1024*1024)>></span>' and produce a huge .beam
file. Corrected.</p>
<p>The compiler would compile list comprehensions with
many generators really, really slow. (Thanks to Thomas
Raes.)</p>
<p>Module attributes would be stored in reverse order
compared to the order in the source code. (Thus,
<span class="code">M:module_info(attributes)</span> would also return the
attributes in reversed order.)</p>
<p>Defining a fun in an <span class="code">after</span> block of a
<span class="code">try</span> would cause the compiler to crash or generate
incorrect code. (Thanks to Martin Bjorklund.)</p>
<p>The combination of binary pattern and a guard with
andalso/orelse could cause the compiler to crash.</p>
<p>Own Id: OTP-6121 Aux Id: seq10400 </p>
</li>
</ul>
<h3><a name="id67810">1.31
Compiler 4.4</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>When a <span class="code">.hrl</span> file is included using
<span class="code">-include_lib</span>, the include path is temporarily
updated to include the directory the <span class="code">.hrl</span> file was
found in, which will allow that <span class="code">.hrl</span> file to itself
include files from the same directory using
<span class="code">-include</span>. (Thanks to Richard Carlsson.)</p>
<p>Own Id: OTP-5944</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>The <span class="code">andalso</span> and <span class="code">orelse</span> operators are
now allowed to be used in guards. That also applies to
match specifications.</p>
<p>Own Id: OTP-5894 Aux Id: OTP-5149 </p>
</li>
<li>
<p>When given the new option
<span class="code">strict_record_tests</span>, the compiler will generate
code that verifies the record type for
<span class="code">R#record.field</span> operations in guards. Code that
verifies record types in bodies has already been
generated since R10B, but in this release there will be a
<span class="code">{badrecord,RecordTag}</span> instead of a
<span class="code">badmatch</span> if the record verification test fails.
See <span class="code">compile(3)</span> for more information.</p>
<p>The Erlang shell always applies strict record tests.</p>
<p>Own Id: OTP-5915 Aux Id: OTP-5714 </p>
</li>
<li>
<p>The BIF <span class="code">is_record/3</span> can now be used in guards.
Also, <span class="code">is_record/3</span> can now be called without an
<span class="code">erlang:</span> module prefix for consistency with the other
<span class="code">is_*</span> functions.</p>
<p>Own Id: OTP-5916</p>
</li>
<li>
<p>The compiler options <span class="code">ignore_try</span> and
<span class="code">ignore_cond</span>, which allowed code that used
unquoted <span class="code">try</span> or <span class="code">cond</span> as atoms or record
tags, has been removed. Old code that depended on the
options need to be revised to have occurrences of
<span class="code">try</span> or <span class="code">cond</span> as atom or record tags
single-quoted. (Note: Although <span class="code">cond</span> is a reserved
keyword, there is no <span class="code">cond</span> statement. It might be
introduced in a future release.)</p>
<p>*** POTENTIAL INCOMPATIBILITY ***</p>
<p>Own Id: OTP-6058</p>
</li>
</ul>
<h3><a name="id68007">1.32
Compiler 4.3.12</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>The following code would crash the compiler: <span class="code">case T of #r{s = ""} -> T #r{s = "x"} end</span>. (Thanks to
Richard Carlsson.)</p>
<p>The compiler could crash if binaries were constructed
in certain guards involving boolean operators (including
semicolon). (Thanks to Torbjorn Tornkvist.)</p>
<p>Own Id: OTP-5872</p>
</li>
<li>
<p>The compiler will now warn that the
<span class="code">megaco:format_versions/1</span> function is deprecated.</p>
<p>Own Id: OTP-5976</p>
</li>
</ul>
<h3><a name="id68065">1.33
Compiler 4.3.11</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>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.)</p>
<p>Minor cleanups to eliminate Dialyzer warnings.</p>
<p>Own Id: OTP-5791 Aux Id: seq10141 </p>
</li>
</ul>
<h3><a name="id68102">1.34
Compiler 4.3.10</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>When given the new option
<span class="code">strict_record_tests</span>, the compiler will generate
code that verifies the record type for
<span class="code">R#record.field</span> operations (in body context only,
not in guards). See the documentation for the
<span class="code">compile</span> module for more information.</p>
<p>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.)</p>
<p>Attributes containing binaries (such as -a(<<1,2,3>>))
would crash the compiler. (Thanks to Roger Price.)</p>
<p>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
<span class="code">application</span> and <span class="code">supervisor</span> behaviours
in the same module will NOT generate any warning, but
using <span class="code">gen_server</span> and <span class="code">gen_fsm</span> will.</p>
<p>Own Id: OTP-5714 Aux Id: seq10073 </p>
</li>
<li>
<p>The pre-processor used to complain that the macro
definition <span class="code">-define(S(S), ??S).</span> was circular,
which it isn't. (Thanks to Richard Carlsson.)</p>
<p>Own Id: OTP-5777</p>
</li>
</ul>
<h3><a name="id68194">1.35
Compiler 4.3.9</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>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.
<span class="code">R#r{a="abc",b=1}</span>). (Thanks to Mikael Karlsson.)</p>
<p>Unecessary tests (such as a 'case' with two case
branches that were identical) could cause the compiler to
crash. (Thanks to Fredrik Thulin.)</p>
<p>The validation pass of the compiler could generate an
error for correct code when floating point operations
were used in try/catch statements.</p>
<p>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.)</p>
<p>Some complex guard expressions (such as <span class="code">A#a.b==""; A#a.b==undefined</span>) would crash the compiler. (Thanks
to Sean Hinde.)</p>
<p>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).</p>
<p>Own Id: OTP-5632 Aux Id: seq10057 </p>
</li>
</ul>
<h3><a name="id68262">1.36
Compiler 4.3.8</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>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.)</p>
<p>Incorrect calls such as <span class="code">M:42()</span> would crash the
compiler. The compiler now generates a warning. (Thanks
to Ulf Wiger.)</p>
<p>Own Id: OTP-5553</p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>The new <span class="code">fun M:F/A</span> construct creates a fun that
refers to the latest version of <span class="code">M:F/A</span>. This syntax is
meant to replace tuple funs <span class="code">{M,F}</span> which have many
problems.</p>
<p>The new type test <span class="code">is_function(Fun, A)</span> (which may be
used in guards) test whether <span class="code">Fun</span> is a fun that can be
applied with <span class="code">A</span> arguments. (Currently, <span class="code">Fun</span> can
also be a tuple fun.)</p>
<p>Own Id: OTP-5584</p>
</li>
</ul>
<h3><a name="id68361">1.37
Compiler 4.3.7</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>Further improvements of encrypted debug info: New option
<span class="code">encrypt_debug_info</span> for compiler.</p>
<p>Own Id: OTP-5541 Aux Id: seq9837 </p>
</li>
</ul>
<h3><a name="id68397">1.38
Compiler 4.3.6</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>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.</p>
<p>Own Id: OTP-5481 Aux Id: seq9798 </p>
</li>
</ul>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>It is now possible to encrypt the debug information in
Beam files, to help keep the source code secret. See the
documentation for <span class="code">compile</span> on how to provide the key
for encrypting, and the documentation for <span class="code">beam_lib</span>
on how to provide the key for decryption so that tools such
as the Debugger, Xref, or Cover can be used.</p>
<p>The <span class="code">beam_lib:chunks/2</span> functions now accepts an
additional chunk type <span class="code">compile_info</span> to retrieve
the compilation information directly as a term. (Thanks
to Tobias Lindahl.)</p>
<p>Own Id: OTP-5460 Aux Id: seq9787 </p>
</li>
</ul>
<h3><a name="id68478">1.39
Compiler 4.3.5</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Complex functions could cause the internal validator in
the compiler to generate an internal error even though
the generated code was correct.</p>
<p>Own Id: OTP-5436 Aux Id: seq9781 </p>
</li>
</ul>
<h3><a name="id68512">1.40
Compiler 4.3.4</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>In rare circumstances, incorrect 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.)</p>
<p>Corrected a bug in in bit syntax matching where
clauses could match in the wrong order. (Thanks to Ulf
Wiger.)</p>
<p>Own Id: OTP-5404 Aux Id: seq9767 </p>
</li>
</ul>
<h3><a name="id68551">1.41
Compiler 4.3.3</a></h3>
<h4>Improvements and New Features</h4>
<ul>
<li>
<p>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.)</p>
<p>Matches such as
<span class="code"><<103133:64/float>> = <<103133:64/float>></span>
used to fail. Now they succeed.</p>
<p>Shadowing of variables in bit syntax matches in fun heads
such as in
<span class="code">L = 8, F = fun(<<L:L,B:L>>) -> B end</span> was
handled incorrectly by the compiler. The fun used to be
compiled as if it was written
'<span class="code">>fun(<<8:8,B:8>>)</span>, while it should be
compiled in the same way as <span class="code">fun(<<L:8,B:L>>)</span>.</p>
<p>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
<span class="code">fun(<<L:L,B:L>>) -> B end</span> was handled
incorrectly by the in the same way as
<span class="code">fun(<<L:8,B:L>>)</span>.</p>
<p>A bug in the unknown_catch_try_state.</p>
<p>Corrected a bug in the optimizer that would cause
the compiler to crash. (Thanks to Peter-Henry Mander.)</p>
<p>There are now warnings generated if a bit syntax
construction will fail at run-time because of a type
mismatch (e.g. <span class="code"><<an_atom:8>></span>).</p>
<p>Own Id: OTP-5342 Aux Id: OTP-5118, OTP-5270, OTP-5323 </p>
</li>
<li>
<p>Binary pattern matching such as
<span class="code">t(<<A:8>> = <<A:8>)</span> used to silently
fail at runtime (i.e. never match). The compiler now
generates an error for any such patterns.</p>
<p>Own Id: OTP-5371</p>
</li>
</ul>
<h3><a name="id68658">1.42
Compiler 4.3.2</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>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.</p>
<p>If a bit syntax construction failed within a catch,
previously assigned variables could get the wrong value.</p>
<p>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.</p>
<p>Some corrections to the unsupported feature
parameterized modules by Richard Carlsson (HiPE).</p>
<p>Own Id: OTP-5247 Aux Id: OTP-5235 </p>
</li>
</ul>
<h3><a name="id68708">1.43
Compiler 4.3.1</a></h3>
<h4>Fixed Bugs and Malfunctions</h4>
<ul>
<li>
<p>Corrected the release note regarding <span class="code">try/catch</span> below.
<span class="code">try/catch</span> DOES work in the initial R10B release.</p>
<p>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.</p>
<p>A debug printout (that could be seen in rare
circumstances) has been removed.</p>
<p><span class="code">not record_test(not_a_tuple, RecordTag)</span> and
similar expressions in a guard would fail.</p>
<p>New options <span class="code">basic_validation</span> and
<span class="code">strong_validation</span> to do a quick check of the code
of a module.</p>
<p>The <span class="code">inline</span> option was not recognized if it
appeared in a <span class="code">-compile()</span> directive inside the
module.</p>
<p>Corrected some bugs in the undocumented feature
"parameterized modules".</p>
<p>Own Id: OTP-5198</p>
</li>
<li>
<p>When the undocumented feature "parameterized modules" was
used, the <span class="code">?MODULE</span> macro did not work correctly.</p>
<p>Own Id: OTP-5224</p>
</li>
</ul>
</div>
<div class="footer">
<hr>
<p>Copyright © 1997-2012 Ericsson AB. All Rights Reserved.</p>
</div>
</div>
</div></body>
</html>
distrib
>
Fedora
>
17
>
i386
>
media
>
updates
>
by-pkgid
>
675c8c8167236dfcf8d66da674f931e8
>
files
>
272
