## 1 Compiler Release Notes

This document describes the changes made to the Compiler application.

### 1.1 Compiler 4.5.1

#### 1.1.1 Fixed Bugs and Malfunctions

- A match expression inside a function call could cause a false "a term is constructed but never used" warning.
  Own Id: OTP-7018 Aux Id: seq10824
- The compiler could crash if a binary tail was matched out, and then used in a binary append operation. (Thanks to Oleg Avdeev.)
  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.)
  Own Id: OTP-7022
- Matching an empty binary in a record and then using the same record again could cause a compiler crash. (Thanks to Fredrik Thulin.)
  Own Id: OTP-7029
- In rare circumstances, constants containing floating points and integers could be confused. Example:
  f(a) -> [1]; f(b) -> [1.0].
  Both f(a) and f(b) would return [1].
  Own Id: OTP-7073
- Some bit syntax code such as
  matching d(_,<$lt;$gt;$gt;) -> one; d(0,<$lt;D$gt;$gt;) ->two.
  could crash the compiler. (Thanks to Simon Cornish.)
  Own Id: OTP-7094
- In unusual circumstances, a call to a fun could fail due to an unsafe optimization. (Thanks to Simon Cornish.)
  Own Id: OTP-7102
- Bit syntax matching with a guard containing two or more uses of andalso/orelse could cause the compiler to crash. (Thanks to Mateusz Berezecki.)
  Own Id: OTP-7113
- 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 erlang:'$lt;'(erlang:length(L), 2) as case expression into a guard, which would change the semantics. (Thanks to Robert Virding.)
  Own Id: OTP-7117

#### 1.1.2 Improvements and New Features

- The compiler could generate suboptimal code for record updates if the record update code consisted of multiple source code lines.
  Own Id: OTP-7101

### 1.2 Compiler 4.5

#### 1.2.1 Fixed Bugs and Malfunctions

- 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, <<B/binary,EmptyBinary/binary>> = Bin used to compile, but now the compilation will fail with an an error message.
  Also, it is now longer permitted to give a literal string in a binary pattern a type or a size; for instance, <<"abc"/binary>> = Bin will no longer compile. (In previous releases, there would always be a badmatch exception at run-time.)
  Own Id: OTP-6885

#### 1.2.2 Improvements and New Features

- Bitstrings (bit-level) binaries and binary comprehensions are now part of the language. See the Reference Manual.
  Own Id: OTP-6558
- The 'compressed' option for the compiler has been documented.
  Own Id: OTP-6801
- If the value of a list comprehension is not used, such as in '[do_something(X) || X <- List], ok', a result list will no longer be built. For more details, see the Efficiency Guide.
  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: 'self(),ok' and '{error,Reason},ok'.
  Own Id: OTP-6824
- Three new functions have been added to the compile module: noenv_file/2, noenv_forms/2, and noenv_output_generated/1.
  Own Id: OTP-6829
- Many bit syntax operations, both construction and matching, are faster. For further information, see the Efficiency Guide.
  Own Id: OTP-6838
- 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.
  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.
  Example 1: In the expression element(BitNum-1, {1,2,4,8,16,32,64,128}), 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.
  Example 2: Literal strings, such as "abc", 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 [$a,$b,$c]) 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, <<"abc"<<) instead of string literals for infrequently used long strings (such as error messages).
  Own Id: OTP-6850
- Recursive calls now usually consume less stack than in R11B. See the Efficiency Guide.
  Own Id: OTP-6862 Aux Id: seq10746
- Two new guard BIFs have been introduced as a recommended replacement for size/1. (The size/1 BIF will be removed no earlier than in R14B.) The BIFs are tuple_size/1 to calculate the size of a tuple and byte_size/1 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).
  There is also a new bit_size/1 BIF that returns the exact number of bits that a binary or bitstring contains.
  Own Id: OTP-6902
- The two internal functions erl_bifs:is_bif/3 and erl_bifs:is_guard/3 have been removed. They were unsupported, undocumented, and unmaintained.
  Own Id: OTP-6966

### 1.3 Compiler 4.4.5

#### 1.3.1 Fixed Bugs and Malfunctions

- The compiler would crash if you tried to combine to non-list literals with '++' (for instance, an_atom++"string").
  Own Id: OTP-6630 Aux Id: seq10635

#### 1.3.2 Improvements and New Features

- Minor Makefile changes.
  Own Id: OTP-6689

### 1.4 Compiler 4.4.4

#### 1.4.1 Fixed Bugs and Malfunctions

- Incorrect code could be generated for bit syntax matching if the old inliner was used with aggressive settings.
  Own Id: OTP-6461

### 1.5 Compiler 4.4.3

#### 1.5.1 Fixed Bugs and Malfunctions

- The R10B compiler could generate unsafe bs_save/bs_restore 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 bs_save/bs_restore 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.)
  Own Id: OTP-6386

#### 1.5.2 Improvements and New Features

- 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.
  Own Id: OTP-5344
- Minor improvements in code generation for some guards expression involving boolean expressions.
  Own Id: OTP-6347

### 1.6 Compiler 4.4.2.1

#### 1.6.1 Fixed Bugs and Malfunctions

- The compiler could generate incorrect code for bit syntax matching consisting of several clauses.
  Own Id: OTP-6392 Aux Id: seq10539

### 1.7 Compiler 4.4.2

#### 1.7.1 Fixed Bugs and Malfunctions

- Defining a fun itself containing a fun in an after block of a try would cause the compiler to crash or generate incorrect code. (Thanks to Tim Rath.)
  Shorter compilation times for modules containing with an extreme number of functions (10000 functions or more).
  (The compiled could generate deprecated instructions for certain bit syntax matching operations.)
  Own Id: OTP-6212 Aux Id: seq10446
- Fixed several bugs that would cause warnings to be shown without file name and line number.
  Own Id: OTP-6260 Aux Id: seq10461

#### 1.7.2 Improvements and New Features

- The strict_record_tests option is now default; that is, reading a field from a record using the Record#record_tag.field syntax will fail if Record is not a record of the correct type.
  If necessary, the record tests can be turned off by giving the no_strict_record_tests option. To avoid editing Makefiles, the environment variable ERL_COMPILER_OPTIONS can be set to "no_strict_record_tests".
  The no_strict_record_tests option will probably be removed in the R12B release.
  *** POTENTIAL INCOMPATIBILITY ***
  Own Id: OTP-6294

### 1.8 Compiler 4.4.1

#### 1.8.1 Fixed Bugs and Malfunctions

- The compiler used to crash if a module contained code similar to 'fun(1=0) -> ok end'. (Thanks to Richard Carlsson.)
  The compiler would spend really long time compiling bit syntax expressions such as '<<1:(50*1024*1024)>>' and produce a huge .beam file. Corrected.
  The compiler would compile list comprehensions with many generators really, really slow. (Thanks to Thomas Raes.)
  Module attributes would be stored in reverse order compared to the order in the source code. (Thus, M:module_info(attributes) would also return the attributes in reversed order.)
  Defining a fun in an after block of a try would cause the compiler to crash or generate incorrect code. (Thanks to Martin Bjorklund.)
  The combination of binary pattern and a guard with andalso/orelse could cause the compiler to crash.
  Own Id: OTP-6121 Aux Id: seq10400

### 1.9 Compiler 4.4

#### 1.9.1 Fixed Bugs and Malfunctions

- When a .hrl file is included using -include_lib, the include path is temporarily updated to include the directory the .hrl file was found in, which will allow that .hrl file to itself include files from the same directory using -include. (Thanks to Richard Carlsson.)
  Own Id: OTP-5944

#### 1.9.2 Improvements and New Features

- The andalso and orelse operators are now allowed to be used in guards. That also applies to match specifications.
  Own Id: OTP-5894 Aux Id: OTP-5149
- When given the new option strict_record_tests, the compiler will generate code that verifies the record type for R#record.field operations in guards. Code that verifies record types in bodies has already been generated since R10B, but in this release there will be a {badrecord,RecordTag} instead of a badmatch if the record verification test fails. See compile(3) for more information.
  The Erlang shell always applies strict record tests.
  Own Id: OTP-5915 Aux Id: OTP-5714
- The BIF is_record/3 can now be used in guards. Also, is_record/3 can now be called without an erlang: module prefix for consistency with the other is_* functions.
  Own Id: OTP-5916
- The compiler options ignore_try and ignore_cond, which allowed code that used unquoted try or cond as atoms or record tags, has been removed. Old code that depended on the options need to be revised to have occurrences of try or cond as atom or record tags single-quoted. (Note: Although cond is a reserved keyword, there is no cond statement. It might be introduced in a future release.)
  *** POTENTIAL INCOMPATIBILITY ***
  Own Id: OTP-6058

### 1.10 Compiler 4.3.12

#### 1.10.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.11 Compiler 4.3.11

#### 1.11.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.12 Compiler 4.3.10

#### 1.12.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.13 Compiler 4.3.9

#### 1.13.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.14 Compiler 4.3.8

#### 1.14.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.14.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.15 Compiler 4.3.7

#### 1.15.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.16 Compiler 4.3.6

#### 1.16.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.16.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.17 Compiler 4.3.5

#### 1.17.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.18 Compiler 4.3.4

#### 1.18.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.19 Compiler 4.3.3

#### 1.19.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 fun(<<L:L,B:L>>) -> B end was handled incorrectly by the in the same way as fun(<<L:8,B:L>>).
  A bug in the unknown_catch_try_state.
  Corrected a bug in the optimizer that would cause the compiler to crash. (Thanks to Peter-Henry Mander.)
  There are 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.20 Compiler 4.3.2

#### 1.20.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.21 Compiler 4.3.1

#### 1.21.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

compiler 4.5.1
Copyright © 1991-2008 Ericsson AB