## 1 Compiler Release Notes

This document describes the changes made to the Compiler application.

### 1.1 Compiler 4.3.8

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

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

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

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

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

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

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

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

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

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

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

#### 1.12.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-2005 Ericsson AB