aboutsummaryrefslogblamecommitdiffstats
path: root/lib/compiler/doc/src/notes.xml
blob: eb5fa8b398b8d3029f590a70b975562b743f4ada (plain) (tree)
1
2
3
4
5
6
7
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
                                       




                                       
                                        







                                                                         
 



                                                                            
 











                                                             




























































                                                                    


















































                                                                     













                                                                     
                                                         































                                                                     


















































                                                                       














                                                                 
                                                                   



























































                                                                        


















































                                                                       
                                              
















                                                                     


































































































                                                                     



























                                                                      























                                                                    






































                                                                     

















































                                                                    














                                                                  



































































































                                                                       






























































                                                                    
































































                                                                       
                                                             















































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































































                                                                                                                                      
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE chapter SYSTEM "chapter.dtd">

<chapter>
  <header>
    <copyright>
      <year>2004</year><year>2013</year>
      <holder>Ericsson AB. All Rights Reserved.</holder>
    </copyright>
    <legalnotice>
      The contents of this file are subject to the Erlang Public License,
      Version 1.1, (the "License"); you may not use this file except in
      compliance with the License. You should have received a copy of the
      Erlang Public License along with this software. If not, it can be
      retrieved online at http://www.erlang.org/.

      Software distributed under the License is distributed on an "AS IS"
      basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
      the License for the specific language governing rights and limitations
      under the License.

    </legalnotice>

    <title>Compiler Release Notes</title>
    <prepared>otp_appnotes</prepared>
    <docno>nil</docno>
    <date>nil</date>
    <rev>nil</rev>
    <file>notes.xml</file>
  </header>
  <p>This document describes the changes made to the Compiler
    application.</p>

<section><title>Compiler 4.9.3</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Expressions such as <c>'B = is_integer(V), if B and B
	    -&gt; ok end'</c> would crash the compiler.</p>
          <p>
	    Own Id: OTP-11240</p>
        </item>
        <item>
          <p>
	    <c>compile:file2/2</c> with the option
	    <c>report_errors</c> could return ErrorInfo tuples with
	    only two elements, while the documentation says that the
	    ErrorInfo tuple always has three elements. Also updated
	    the documentation to add that the first element may be
	    '<c>none</c>' if no line number is applicable.</p>
          <p>
	    Own Id: OTP-11304 Aux Id: seq12412 </p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    Fix matching of floating point middle-endian machines.
	    Thanks to Johannes Weissl.</p>
          <p>
	    Own Id: OTP-11201</p>
        </item>
        <item>
          <p>
	    Restrict inlining of local fun references. Thanks to
	    Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11211</p>
        </item>
        <item>
          <p>
	    Silence a misleading warning with some comprehensions.
	    Thanks to Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11212</p>
        </item>
        <item>
          <p>
	    Forbid returning a match context in beam_validator.
	    Thanks to Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11247</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.9.2</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Compiling functions with complex boolean operations in
	    guards could be very slow. (Thanks to Magnus Muller for
	    reporting this issue.)</p>
          <p>
	    Own Id: OTP-10939</p>
        </item>
        <item>
          <p>
	    Certain guard expressions used in a receive statement
	    could cause the compiler to crash.</p>
          <p>
	    Own Id: OTP-11119 Aux Id: seq12342 </p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    Fix optimization of some binary comprehensions. Thanks to
	    Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11005</p>
        </item>
        <item>
          <p>
	    Use a set to store ref registers in beam_receive. Thanks
	    to Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11069</p>
        </item>
        <item>
          <p>
	    Fix renaming of bs_put_string instructions. Thanks to
	    Anthony Ramine.</p>
          <p>
	    Own Id: OTP-11129</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.9.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    The compiler would crash attempting to compile
	    expressions such as "element(2, not_tuple)".</p>
          <p>
	    Own Id: OTP-10794</p>
        </item>
        <item>
          <p>
	    Forbid multiple values in Core Erlang sequence arguments.
	    Thanks to José Valim and Anthony Ramine.</p>
          <p>
	    Own Id: OTP-10818</p>
        </item>
        <item>
          <p>
	    An unsafe optimization would cause the compiler to crash
	    with an internal error for certain complex code
	    sequences.</p>
          <p>
	    Own Id: OTP-10825 Aux Id: seq12247 </p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
	    <p>Integers in expression that will give a floating point
	    result (such as "<c>X / 2</c>" will now be converted to
	    floating point at compile-time. (Suggested by Richard
	    O'Keefe.)</p>
	    <p>Identical floating points constans in a module will
	    now be coalesced to one entry in the constant pool.</p>
          <p>
	    Own Id: OTP-10788</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.9</title>

    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    The compiler optimizations have been polished, so that
	    the code quality will be slightly better in some cases.</p>
          <p>
	    Own Id: OTP-10193</p>
        </item>
        <item>
	    <p> Support for Unicode has been implemented. </p>
          <p>
	    Own Id: OTP-10302</p>
        </item>
        <item>
	    <p>Where necessary a comment stating encoding has been
	    added to Erlang files. The comment is meant to be removed
	    in Erlang/OTP R17B when UTF-8 becomes the default
	    encoding. </p>
          <p>
	    Own Id: OTP-10630</p>
        </item>
        <item>
          <p>
	    Fix some wrong warnings triggered by the option
	    inline_list_funcs. Thanks to Anthony Ramine.</p>
          <p>
	    Own Id: OTP-10690</p>
        </item>
        <item>
          <p>
	    Forbid local fun variables in Core Erlang guards. Thanks
	    to Anthony Ramine.</p>
          <p>
	    Own Id: OTP-10706</p>
        </item>
        <item>
          <p>
	    Binary syntax matches could cause an internal consistency
	    error in in the compiler. (Thanks to Viktor Sovietov for
	    reporting this bug.)</p>
          <p>
	    Own Id: OTP-10724</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.8.2</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Modules with very many functions would compile very
	    slowly.</p>
          <p>
	    Own Id: OTP-10123</p>
        </item>
        <item>
          <p>
	    <c>compile:forms/2</c> will now use a
	    {source,SourceFilePath} to set the source returned by
	    <c>module_info(compile)</c> (Thanks to José Valim)</p>
          <p>
	    Own Id: OTP-10150</p>
        </item>
        <item>
          <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>
        </item>
        <item>
          <p>
	    Fix messages ordering with column numbers</p>
          <p>
	    Own Id: OTP-10183</p>
        </item>
        <item>
          <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>
        </item>
        <item>
          <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>
        </item>
        <item>
          <p>
	    The compiler will now warn for illegal sizes for segments
	    in binary construction. For example,
	    &lt;&lt;X:(2.5)&gt;&gt; will now cause the compiler to
	    issue a warning.</p>
          <p>
	    Own Id: OTP-10197</p>
        </item>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.8.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    In rare circumstance, the compiler could crash when
	    compiling a case statement. (Thanks to Hakan Mattsson.)</p>
          <p>
	    Own Id: OTP-9842</p>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <p>Using <c>get/1</c> in a <c>try</c> block could in some
	    cases cause an internal compiler error. (Thanks to Eric
	    Merritt.)</p>
          <p>
	    Own Id: OTP-9867</p>
        </item>
        <item>
          <p>
	    An unexported on_load function would not get run if the
	    module was compiled with the <c>inline</c> option.
	    (Thanks to Yiannis Tsiouris.)</p>
          <p>
	    Own Id: OTP-9910</p>
        </item>
        <item>
          <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>
        </item>
        <item>
          <p>
	    Fix typo in `compile' doc: unmatched parenthesis (Thanks
	    to Ricardo Catalinas Jiménez)</p>
          <p>
	    Own Id: OTP-9919</p>
        </item>
        <item>
	    <p>In a <c>try</c>...<c>catch</c> statement that always
	    returned <c>false</c>, the compiler would remove calls to
	    BIFs that could not cause an exception (such as
	    <c>put/2</c>). Example of such code: <c>try put(K, V),
	    false catch _:_ -&gt; false end.</c></p>
          <p>
	    Own Id: OTP-9982</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.8</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <p>
	    The calculation of the 'uniq' value for a fun (see
	    <c>erlang:fun_info/1</c>) 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>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
	    <p>Variables are now now allowed in '<c>fun M:F/A</c>' as
	    suggested by Richard O'Keefe in EEP-23.</p>
	    <p>The representation of '<c>fun M:F/A</c>' 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 <c>syntax_tools</c> application can also handle both
	    formats.</p>
          <p>
	    *** POTENTIAL INCOMPATIBILITY ***</p>
          <p>
	    Own Id: OTP-9643</p>
        </item>
        <item>
          <p>
	    <c>filename:find_src/1,2</c> 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 <c>M:module_info(compile)</c>
	    (because those options will be applied anyway if the
	    module is re-compiled).</p>
          <p>
	    Own Id: OTP-9752</p>
        </item>
        <item>
	    <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7.5</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Compiler options given in the source code using a
	    <c>-compile()</c> attribute used to be included twice in
	    <c>Mod:module_info(compile)</c>. They are now only
	    included once at the beginning of the list of options.</p>
          <p>
	    Own Id: OTP-9534</p>
        </item>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7.4</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
        <item>
	    <p>Eliminate incorrect warning in
	    <c>sys_core_fold</c></p>
          <p>
	    Own Id: OTP-9152</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7.3</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    The <c>-export_type()</c> directive is no longer included
	    among the attributes.</p>
          <p>
	    Own Id: OTP-8998</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <p>
	    Dependency generation for Makefiles has been added to the
	    compiler and erlc. See the manual pages for
	    <c>compile</c> and <c>erlc</c>. (Thanks to Jean-Sebastien
	    Pedron.)</p>
          <p>
	    Own Id: OTP-9065</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7.2</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
	    <p>The compiler would translate binary comprehensions
	    containing tail segments in a way that would would
	    confuse Dialyzer. For instance:</p>
	    <p><c>[42 || &lt;&lt;_:8/integer, _/bits&gt;&gt; &lt;=
	    Bits]</c></p>
          <p>
	    would produce a Dialyzer warning.</p>
          <p>
	    Own Id: OTP-8864</p>
        </item>
        <item>
          <p>
	    Code such as <c>foo(A) -&gt; &lt;&lt;A:0&gt;&gt;</c>
	    would crash the compiler.</p>
          <p>
	    Own Id: OTP-8865</p>
        </item>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7.1</title>

    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    Eliminated warnings for auto-imported BIF clashes.</p>
          <p>
	    Own Id: OTP-8840</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.7</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Several problems in the inliner have been fixed.</p>
          <p>
	    Own Id: OTP-8552</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    The module binary from EEP31 (and EEP9) is implemented.</p>
          <p>
	    Own Id: OTP-8217</p>
        </item>
        <item>
	    <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>
	    <list><item><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></item>
	    <item><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></item>
	    <item><p>Using any form of the old compiler directive
	    <c>nowarn_bif_clash</c></p></item> </list> <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 <c>erlang</c> to
	    call the BIF, or you can remove the auto-import of that
	    specific BIF by using the new compiler directive
	    <c>-compile({no_auto_import,[F/A]}).</c>, 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 <c>nowarn_bif_clash</c> compiler
	    directive, might need changing to be accepted by the
	    compiler.</p>
          <p>
	    *** POTENTIAL INCOMPATIBILITY ***</p>
          <p>
	    Own Id: OTP-8579</p>
        </item>
        <item>
	    <p>The undocumented, unsupport, and deprecated function
	    <c>lists:flat_length/1</c> has been removed.</p>
          <p>
	    Own Id: OTP-8584</p>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <p>It is now possible to suppress the warning in code
	    such as "<c>list_to_integer(S), ok</c>" by assigning the
	    ignored value "_" like this: "<c>_ = list_to_integer(S),
	    ok</c>".</p>
          <p>
	    Own Id: OTP-8602</p>
        </item>
        <item>
	    <p><c>receive</c> 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
	    <c>gen_server:call()</c>. (See <c>gen:do_call/4</c> for
	    an example of a receive statement that will be
	    optimized.)</p>
          <p>
	    Own Id: OTP-8623</p>
        </item>
        <item>
	    <p>The compiler optimizes record operations better.</p>
          <p>
	    Own Id: OTP-8668</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.5</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
        <item>
	    <p>Bit string comprehensions can now be used in
	    parameterized modules. (Thanks to Jebu Ittiachen.)</p>
          <p>
	    Own Id: OTP-8447</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <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>
        </item>
        <item>
          <p>
	    The <c>-Werror</c> option for <c>erlc</c> and the
	    compiler option <c>warnings_as_errors</c> will cause
	    warnings to be treated as errors. (Thanks to Christopher
	    Faulet.)</p>
          <p>
	    Own Id: OTP-8382</p>
        </item>
        <item>
	    <p>Macros overloading has been implemented. (Thanks to
	    Christopher Faulet.)</p>
          <p>
	    Own Id: OTP-8388</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.4</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
	    <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>
        </item>
        <item>
          <p>
	    Certain uses of binary matching in a
	    <c>begin</c>-<c>end</c> in a list comprehension could
	    cause the compiler to crash or generate incorrect code.</p>
          <p>
	    Own Id: OTP-8271</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <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>
        </item>
        <item>
	    <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.3</title>

    <section><title>Improvements and New Features</title>
      <list>
        <item>
	    <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 <c>length/1</c> in guard context
	    in a try/catch block could cause a compiler crash.
	    (Thanks to Paul Fisher.)</p>
	    <p>Using filter expressions containing <c>andalso</c> or
	    <c>orelse</c> in a list comprehension could cause a
	    compiler crash. (Thanks to Martin Engström.)</p>
          <p>
	    Own Id: OTP-8054</p>
        </item>
        <item>
          <p>
	    A guard with nested 'not' operators could cause the
	    compiler to crash. (Thanks to Tuncer Ayaz.)</p>
          <p>
	    Own Id: OTP-8131</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.2</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    The compiler would crash while compiling certain complex
	    function bodies containing <c>receive after</c> 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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    Miscellaneous minor bugs fixed.</p>
          <p>
	    Own Id: OTP-7937</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
	    <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6.0.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
            <p>Using <c>andalso</c>/<c>orelse</c> or record access in
            a <c>try</c>...<c>catch</c> 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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.6</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <p>
	    For some complex guards which used
	    <c>andalso</c>/<c>orelse</c>, the compiler would crash.
	    (Thanks to Hunter Morris.)</p>
          <p>
	    Own Id: OTP-7679</p>
        </item>
        <item>
          <p>
	    Code that (incorrectly) used the the value of nested
	    applications of <c>setelement/3</c> in bit syntax
	    construction could crash the compiler.</p>
          <p>
	    Own Id: OTP-7690</p>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <p>If the generator in a list comprehension is given a
	    non-list term, there will now be <c>function_clause</c>
	    exception instead of a <c>case_clause</c> exception (as
	    it was in all releases before R12B).</p>
          <p>
	    Own Id: OTP-7844</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <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>
        </item>
        <item>
          <p>
	    The undocumented, unsupported, and deprecated guard BIF
	    <c>is_constant/1</c> has been removed.</p>
          <p>
	    *** INCOMPATIBILITY with R12B ***</p>
          <p>
	    Own Id: OTP-7673</p>
        </item>
        <item>
	    <p>The compiler generates better code for many guard
	    expressions, and especially for guards that use
	    <c>andalso</c>/<c>orelse</c> or record fields.</p>
	    <p>(In technical terms, <c>andalso</c>/<c>orelse</c> 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>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <p>The short-circuit operators <c>andalso</c> and
	    <c>orelse</c> no longer guarantees that their second
	    argument is either <c>true</c> or <c>false</c>. As a
	    consequence, <c>andalso</c>/<c>orelse</c> are now
	    tail-recursive.</p>
          <p>
	    *** POTENTIAL INCOMPATIBILITY ***</p>
          <p>
	    Own Id: OTP-7748</p>
        </item>
        <item>
	    <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 <c>erlc</c>, 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>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <p>Warnings for obsolete guard tests are now turned on.
	    (That is, writing <c>list(L)</c> in a guard instead of
	    <c>is_list(L)</c> will generate a warning.)</p>
	    <p>The warnings can be turned off using the
	    <c>nowarn_obsolete_guard</c> option.</p>
          <p>
	    Own Id: OTP-7850</p>
        </item>
        <item>
	    <p>The copyright notices have been updated.</p>
          <p>
	    Own Id: OTP-7851</p>
        </item>
        <item>
	    <p>If a module contains an exported function with the
	    same name as an auto-imported BIF (such as
	    <c>length/1</c>), any calls to the BIF must have an
	    explicit <c>erlang:</c> 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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5.5</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
	    <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>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
	    <p>In user-defined attributes, <c>Name/Arity</c> is now
	    allowed and will be translated to <c>{Name,Arity}</c>.
	    (An implementation of EEP-24 by Richard O'Keefe.)</p>
	    <p>The <c>module_info/{0,1}</c> 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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5.4</title>

    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5.3</title>

    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <p>
	    New option <c>warn_export_all</c> to warn for a module
	    using <c>export_all</c>. (Thanks to Richard Carlsson.)</p>
          <p>
	    Own Id: OTP-7392</p>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5.2.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>
<section><title>Compiler 4.5.2</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
	    <p>A bug in the old inliner has been fixed. Some
	    undocumented functionality has been removed.</p>
          <p>
	    Own Id: OTP-7223</p>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <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>
        </item>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5.1.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <p>
	    In unusual circumstances, the environment for a fun could
	    bind wrong values.</p>
          <p>
	    Own Id: OTP-7202 Aux Id: seq10887 </p>
        </item>
        <item>
	    <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
	    '<c>[...||...]++Expr</c>', <c>Expr</c> is now evaluated
	    before the list comprehension. This change <em>is</em>
	    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 <em>in any order</em>
	    before the expression itself. Therefore, in an expression
	    such as '<c>LeftExpr++RightExpr</c>', you should not
	    depend on <c>LeftExpr</c> being evaluated before
	    <c>RightExpr</c> 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 <c>ets</c> operations.</p>
          <p>
	    Own Id: OTP-7206</p>
        </item>
      </list>
    </section>

</section>


<section><title>Compiler 4.5.1</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
          <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>
        </item>
        <item>
	    <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>
        </item>
        <item>
          <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>
        </item>
        <item>
	    <p>In rare circumstances, constants containing floating
	    points and integers could be confused. Example:</p>
	    <p><c>f(a) -> [1]; f(b) -> [1.0].</c></p>
	    <p>Both <c>f(a)</c> and <c>f(b)</c> would return
	    <c>[1]</c>.</p>
          <p>
	    Own Id: OTP-7073</p>
        </item>
        <item>
	    <p>Some bit syntax code such as</p>
	    <p><c>matching d(_,&lt;$lt;$gt;$gt;) -> one; d(0,&lt;$lt;D$gt;$gt;)
	    ->two.</c></p>
	    <p>could crash the compiler. (Thanks to Simon
	    Cornish.)</p>
          <p>
	    Own Id: OTP-7094</p>
        </item>
        <item>
          <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>
        </item>
        <item>
          <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>
        </item>
        <item>
          <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
	    <c>erlang:'$lt;'(erlang:length(L), 2)</c> as case expression
	    into a guard, which would change the semantics. (Thanks
	    to Robert Virding.)</p>
          <p>
	    Own Id: OTP-7117</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
      </list>
    </section>

</section>

<section><title>Compiler 4.5</title>

    <section><title>Fixed Bugs and Malfunctions</title>
      <list>
        <item>
	    <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,
	    <c><![CDATA[<<B/binary,EmptyBinary/binary>> = Bin]]></c>
	    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, <c><![CDATA[<<"abc"/binary>> = Bin]]></c> will
	    no longer compile. (In previous releases, there would
	    always be a <c>badmatch</c> exception at run-time.)</p>
          <p>
	    Own Id: OTP-6885</p>
        </item>
      </list>
    </section>


    <section><title>Improvements and New Features</title>
      <list>
        <item>
          <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>
        </item>
        <item>
          <p>
	    The '<c>compressed</c>' option for the compiler has been
	    documented.</p>
          <p>
	    Own Id: OTP-6801</p>
        </item>
        <item>
	    <p>If the value of a list comprehension is not used, such
	    as in '<c>[do_something(X) || X &lt;- List], ok</c>', 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: '<c>self(),ok</c>' and
	    '<c>{error,Reason},ok</c>'.</p>
          <p>
	    Own Id: OTP-6824</p>
        </item>
        <item>
          <p>
	    Three new functions have been added to the <c>compile</c>
	    module: <c>noenv_file/2</c>, <c>noenv_forms/2</c>, and
	    <c>noenv_output_generated/1</c>.</p>
          <p>
	    Own Id: OTP-6829</p>
        </item>
        <item>
	    <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>
        </item>
        <item>
	    <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 <c>element(BitNum-1,
	    {1,2,4,8,16,32,64,128})</c>, 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 <c>"abc"</c>, 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
	    <c>[$a,$b,$c]</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,
	    <c>&lt;&lt;"abc"&lt;&lt;</c>) instead of string literals for
	    infrequently used long strings (such as error
	    messages).</p>
          <p>
	    Own Id: OTP-6850</p>
        </item>
        <item>
          <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>
        </item>
        <item>
	    <p>Two new guard BIFs have been introduced as a
	    recommended replacement for <c>size/1</c>. (The
	    <c>size/1</c> BIF will be removed no earlier than in
	    R14B.) The BIFs are <c>tuple_size/1</c> to calculate the
	    size of a tuple and <c>byte_size/1</c> 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 <c>bit_size/1</c> BIF that returns
	    the exact number of bits that a binary or bitstring
	    contains.</p>
          <p>
	    Own Id: OTP-6902</p>
        </item>
        <item>
          <p>
	    The two internal functions <c>erl_bifs:is_bif/3</c> and
	    <c>erl_bifs:is_guard/3</c> have been removed. They were
	    unsupported, undocumented, and unmaintained.</p>
          <p>
	    Own Id: OTP-6966</p>
        </item>
      </list>
    </section>

</section>

  <section>
    <title>Compiler 4.4.5</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>The compiler would crash if you tried to combine to
            non-list literals with '<c><![CDATA[++]]></c>' (for instance,
            <c><![CDATA[an_atom++"string"]]></c>).</p>
          <p>Own Id: OTP-6630 Aux Id: seq10635 </p>
        </item>
      </list>
    </section>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>Minor Makefile changes.</p>
          <p>Own Id: OTP-6689</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4.4</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4.3</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>The R10B compiler could generate unsafe
            <c><![CDATA[bs_save/bs_restore]]></c> 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
            <c><![CDATA[bs_save/bs_restore]]></c> 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>
        </item>
      </list>
    </section>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
        <item>
          <p>Minor improvements in code generation for some guards
            expression involving boolean expressions.</p>
          <p>Own Id: OTP-6347</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4.2.1</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4.2</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>Defining a fun itself containing a fun in an
            <c><![CDATA[after]]></c> block of a <c><![CDATA[try]]></c> 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>
        </item>
        <item>
          <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>
        </item>
      </list>
    </section>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>The <c><![CDATA[strict_record_tests]]></c> option is now default;
            that is, reading a field from a record using the
            <c><![CDATA[Record#record_tag.field]]></c> syntax will fail if
            <c><![CDATA[Record]]></c> is not a record of the correct type.</p>
          <p>If necessary, the record tests can be turned off by
            giving the <c><![CDATA[no_strict_record_tests]]></c> option. To avoid
            editing Makefiles, the environment variable
            <c><![CDATA[ERL_COMPILER_OPTIONS]]></c> can be set to
            "<c><![CDATA[no_strict_record_tests]]></c>".</p>
          <p>The <c><![CDATA[no_strict_record_tests]]></c> option will probably
            be removed in the R12B release.</p>
          <p>*** POTENTIAL INCOMPATIBILITY ***</p>
          <p>Own Id: OTP-6294</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4.1</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>The compiler used to crash if a module contained code
            similar to '<c><![CDATA[fun(1=0) -> ok end]]></c>'. (Thanks to
            Richard Carlsson.)</p>
          <p>The compiler would spend really long time compiling
            bit syntax expressions such as
            '<c><![CDATA[<<1:(50*1024*1024)>>]]></c>' 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,
            <c><![CDATA[M:module_info(attributes)]]></c> would also return the
            attributes in reversed order.)</p>
          <p>Defining a fun in an <c><![CDATA[after]]></c> block of a
            <c><![CDATA[try]]></c> 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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.4</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>When a <c><![CDATA[.hrl]]></c> file is included using
            <c><![CDATA[-include_lib]]></c>, the include path is temporarily
            updated to include the directory the <c><![CDATA[.hrl]]></c> file was
            found in, which will allow that <c><![CDATA[.hrl]]></c> file to itself
            include files from the same directory using
            <c><![CDATA[-include]]></c>. (Thanks to Richard Carlsson.)</p>
          <p>Own Id: OTP-5944</p>
        </item>
      </list>
    </section>

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

  <section>
    <title>Compiler 4.3.12</title>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>The following code would crash the compiler: <c><![CDATA[case T of #r{s = ""} -> T #r{s = "x"} end]]></c>. (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>
        </item>
        <item>
          <p>The compiler will now warn that the
            <c><![CDATA[megaco:format_versions/1]]></c> function is deprecated.</p>
          <p>Own Id: OTP-5976</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.11</title>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.10</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>When given the new option
            <c><![CDATA[strict_record_tests]]></c>, the compiler will generate
            code that verifies the record type for
            <c><![CDATA[R#record.field]]></c> operations (in body context only,
            not in guards). See the documentation for the
            <c><![CDATA[compile]]></c> 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(&lt;&lt;1,2,3&gt;&gt;))
            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
            <c><![CDATA[application]]></c> and <c><![CDATA[supervisor]]></c> behaviours
            in the same module will NOT generate any warning, but
            using <c><![CDATA[gen_server]]></c> and <c><![CDATA[gen_fsm]]></c> will.</p>
          <p>Own Id: OTP-5714 Aux Id: seq10073 </p>
        </item>
        <item>
          <p>The pre-processor used to complain that the macro
            definition <c><![CDATA[-define(S(S), ??S).]]></c> was circular,
            which it isn't. (Thanks to Richard Carlsson.)</p>
          <p>Own Id: OTP-5777</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.9</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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.
            <c><![CDATA[R#r{a="abc",b=1}]]></c>). (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 <c><![CDATA[A#a.b==""; A#a.b==undefined]]></c>) 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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.8</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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 <c><![CDATA[M:42()]]></c> would crash the
            compiler. The compiler now generates a warning. (Thanks
            to Ulf Wiger.)</p>
          <p>Own Id: OTP-5553</p>
        </item>
      </list>
    </section>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>The new <c><![CDATA[fun M:F/A]]></c> construct creates a fun that
            refers to the latest version of <c><![CDATA[M:F/A]]></c>. This syntax is
            meant to replace tuple funs <c><![CDATA[{M,F}]]></c> which have many
            problems.</p>
          <p>The new type test <c><![CDATA[is_function(Fun, A)]]></c> (which may be
            used in guards) test whether <c><![CDATA[Fun]]></c> is a fun that can be
            applied with <c><![CDATA[A]]></c> arguments. (Currently, <c><![CDATA[Fun]]></c> can
            also be a tuple fun.)</p>
          <p>Own Id: OTP-5584</p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.7</title>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>Further improvements of encrypted debug info: New option
            <c><![CDATA[encrypt_debug_info]]></c> for compiler.</p>
          <p>Own Id: OTP-5541 Aux Id: seq9837 </p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.6</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <p>It is now possible to encrypt the debug information in
            Beam files, to help keep the source code secret. See the
            documentation for <c><![CDATA[compile]]></c> on how to provide the key
            for encrypting, and the documentation for <c><![CDATA[beam_lib]]></c>
            on how to provide the key for decryption so that tools such
            as the Debugger, Xref, or Cover can be used.</p>
          <p>The <c><![CDATA[beam_lib:chunks/2]]></c> functions now accepts an
            additional chunk type <c><![CDATA[compile_info]]></c> to retrieve
            the compilation information directly as a term. (Thanks
            to Tobias Lindahl.)</p>
          <p>Own Id: OTP-5460 Aux Id: seq9787 </p>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.5</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.4</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.3</title>

    <section>
      <title>Improvements and New Features</title>
      <list type="bulleted">
        <item>
          <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
            <c><![CDATA[<<103133:64/float>> = <<103133:64/float>>]]></c>
            used to fail. Now they succeed.</p>
          <p>Shadowing of variables in bit syntax matches in fun heads
            such as in
            <c><![CDATA[L = 8, F = fun(<<L:L,B:L>>) -> B end]]></c> was
            handled incorrectly by the compiler. The fun used to be
            compiled as if it was written
            '<c><![CDATA[>fun(<<8:8,B:8>>)]]></c>, while it should be
            compiled in the same way as <c><![CDATA[fun(<<L:8,B:L>>)]]></c>.</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
            <c><![CDATA[fun(<<L:L,B:L>>) -> B end]]></c> was handled
            incorrectly by the in the same way as
            <c><![CDATA[fun(<<L:8,B:L>>)]]></c>.</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. <c><![CDATA[<<an_atom:8>>]]></c>).</p>
          <p>Own Id: OTP-5342 Aux Id: OTP-5118, OTP-5270, OTP-5323 </p>
        </item>
        <item>
          <p>Binary pattern matching such as
            <c><![CDATA[t(<<A:8>> = <<A:8>)]]></c> 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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.2</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <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>
        </item>
      </list>
    </section>
  </section>

  <section>
    <title>Compiler 4.3.1</title>

    <section>
      <title>Fixed Bugs and Malfunctions</title>
      <list type="bulleted">
        <item>
          <p>Corrected the release note regarding <c><![CDATA[try/catch]]></c> below.
            <c><![CDATA[try/catch]]></c> 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><c><![CDATA[not record_test(not_a_tuple, RecordTag)]]></c> and
            similar expressions in a guard would fail.</p>
          <p>New options <c><![CDATA[basic_validation]]></c> and
            <c><![CDATA[strong_validation]]></c> to do a quick check of the code
            of a module.</p>
          <p>The <c><![CDATA[inline]]></c> option was not recognized if it
            appeared in a <c><![CDATA[-compile()]]></c> directive inside the
            module.</p>
          <p>Corrected some bugs in the undocumented feature
            "parameterized modules".</p>
          <p>Own Id: OTP-5198</p>
        </item>
        <item>
          <p>When the undocumented feature "parameterized modules" was
            used, the <c><![CDATA[?MODULE]]></c> macro did not work correctly.</p>
          <p>Own Id: OTP-5224</p>
        </item>
      </list>
    </section>
  </section>
</chapter>