## 1 Compiler Release Notes

This document describes the changes made to the Compiler application.

### 1.1 Compiler 4.4.1

#### 1.1.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.2 Compiler 4.4

#### 1.2.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.2.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.3 Compiler 4.3.12

#### 1.3.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.4 Compiler 4.3.11

#### 1.4.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.5 Compiler 4.3.10

#### 1.5.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.6 Compiler 4.3.9

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

#### 1.7.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.7.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.8 Compiler 4.3.7

#### 1.8.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.9 Compiler 4.3.6

#### 1.9.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.9.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.10 Compiler 4.3.5

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

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

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

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

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

Copyright © 1991-2006 Ericsson AB