Age | Commit message (Collapse) | Author |
|
The type `beam()` in the `beam_lib` module is confusing:
-type beam() :: module() | file:filename() | binary().
It says that the module name can be used to identify the BEAM module
to be accessed, but passing in the module name only works if the BEAM
file is located in the current working directory because the module
is not searched for in the code path.
The reason that it is allowed to pass in the module name as an atom is
for backward compatibility. A long time ago, atoms instead of strings
were used as filenames. For that reason, `filename` and `file` still
accept atoms as filenames (although the practice is frown
upon). `beam_lib` accepts an atom as the filename for the same reason.
To remove the confusion, remove `module()` from the type and the
mention of it in the documentation. Code that uses an atom as a
filename will still work, but Dialyzer will issue a warning.
https://bugs.erlang.org/browse/ERL-696
|
|
With DEBUG=true in erl_anno, erl_parse, and erl_pp a few (harmless)
non-opaque accesses of annotations were found.
|
|
|
|
|
|
|
|
The new Dbgi chunk returns data in the following format:
{debug_info_v1, Backend, Data}
This allows compilers to store the debug info in different
formats. In order to retrieve a particular format, for
instance, Erlang Abstract Format, one may invoke:
Backend:debug_info(erlang_v1, Module, Data, Opts)
Besides introducing the chunk above, this commit also:
* Changes beam_lib:chunk(Beam, [:abstract_code]) to
read from the new Dbgi chunk while keeping backwards
compatibility with old .beams
* Adds the {debug_info, {Backend, Data}} option to
compile:file/2 and friends that are stored in the
Dbgi chunk. This allows the debug info encryption
mechanism to work across compilers
* Improves dialyzer to work directly on Core Erlang,
allowing languages that do not have the Erlang
Abstract Format to be dialyzer as long as they emit
the new chunk and their backend implementation is
available
Backwards compatibility is kept across the board except
for those calling beam_lib:chunk(Beam, ["Abst"]), as the
old chunk is no longer available. Note however the "Abst"
chunk has always been optional.
Future OTP versions may remove parsing the "Abst" chunk
altogether from beam_lib once Erlang 19 and earlier is no
longer supported.
The current Dialyzer implementation still supports earlier
.beam files and such may also be removed in future versions.
|
|
The new chunk stores atoms encoded in UTF-8.
beam_lib has also been modified to handle the new
'utf8_atoms' attribute while the 'atoms' attribute
may be a missing chunk from now on.
The binary_to_atom/2 BIF can now encode any utf8
binary with up to 255 characters.
The list_to_atom/1 BIF can now accept codepoints
higher than 255 with up to 255 characters (thanks
to Björn Gustavsson).
|
|
The abstract_code chunk can also contain {eof,_}, {error,_}, and
{warning,_} in addition to the abstract forms that make up the Erlang
syntax proper.
|
|
|
|
Forms with record field types created before OTP 19.0 are replaced by
well-formed record forms holding the type information.
Tools reading the 'abstract_code' chunk can rely on the returned forms
being well-formed, that is, there are no badly formed 'type' attribute
forms.
|
|
* bjorn/stdlib/remove-tuple-fun-vestiges:
Eliminate redundant double is_function test
|
|
* maint:
Check for already started beam_lib crypto server
|
|
When tuple funs were still supported, the idiom for allowing
real funs with a certain arity but not tuple funs was:
is_function(Fun) andalso is_function(Fun, Arity)
The reason that both tests were needed is because:
is_function({M,F}) would return 'false'
is_function({M,F}, Arity) would return 'true'
In 53ec991d19, is_function/2 was updated to only return 'false'
for tuples, so the call to is_function/1 can be removed.
|
|
When starting the beam_lib crypto server, don't crash
when it is already running. Some other process might
have already called it.
|
|
* maint:
beam_lib: Document all_chunks/1 and build_module/1
|
|
beam_lib:all_chunks/1 and beam_lib:build_module/1 can be useful
for special-purpose stripping, for example to remove the "Line"
chunk.
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
|
|
|
|
* maint: (128 commits)
beam_lib: Correct wrong type specification
testSeqOf: Test constrained, extensible sizes
[snmp/agent] Some restructuring of test suite
Clean up testSeqOf
Extend tests cases for BIT STRING
Improve tests of ENUMERATED
asn1ct_check: Eliminate useless Per argument from complist_as_tuple()
asn1ct_check: Don't pass on #'ObjectClassFieldType'{} with fixed type
asn1ct_gen_per: Remove useless renewal of 'enumval'
Fix encoding of semi-constrained, extensible INTEGERs
PER/UPER: Fix decoding of semi-constrained INTEGERs
testPrim: Simplify test cases using a roundtrip function
BER: Fix handling of a constructed default value for a class
PER: Generate code for deep table constraints at compile-time
Normalize data representation for table constraints
asn1ct: Simplify check_value/2
Extend tests to cover more code in asn1ct_check
Clean up checking of values for ENUMERATEDs
Introduce a new mechanism for structured error handling
asn1_db: Make dbput/3 and dbsave/2 asynchronous
...
|
|
The function was updated in 5805b576, but not the type specificatin.
|
|
Conflicts:
bootstrap/lib/stdlib/ebin/beam_lib.beam
lib/public_key/test/erl_make_certs.erl
|
|
Since both the STDLIB and compiler applications turn warnings
into errors, we must stop using the old deprecated crypto functions.
While we are at it, generalize the format of the key tuple returned
by beam_lib:make_crypto_key/2 to facilitate introducing new crypto
methods in the future. Change the format to:
{Type,Key,IV,BlockSize}
where Type, Key, and IV are the first three arguments for either
crypto:block_encrypt4/ or crypto:block_decrypt/4, and BlockSize
is the block size for the crypto algorithm (it is needed to properly
pad the plaintext blocks before encryption).
|
|
|
|
|
|
|
|
* dev:
distribution_SUITE:bulk_send_bigbig/1: Fail with more information
distribution_SUITE: Use unique slave node names
beam_lib: Handle rare race in the crypto key server functionality
busy_port_SUITE: Avoid crash in register/2
[wx] Re-generate code
[wx] Remove optional shadowing clauses
[wx] Remove warning
[wx] Fix trailing whitespace
[wx] Test colors in textctrl
[wx] Fix cleanup memory references
|
|
In rare circumstances, there can be a race when the crypto key server
is started by beam_lib:crypto_key_fun/1 shortly after stopping it
using beam_lib:clear_crypto_key_fun/0. The race occurs because
the crypto key server first sends back the reply to the calling
process, then terminates. (The race is probably more likely to happen
on CPUs with hyper threading.)
|
|
|
|
|
|
|
|
Specify that beam_lib:cmp/2 can return {error, beam_lib, different_chunks} if a chunk is only present in one of the beams.
|
|
|
|
* bg/beam_lib:
Remove redundant includes
Make beam_lib:cmp/2 stricter
OTP-8625 bg/beam_lib
The beam_lib:cmp/2 function now compares BEAM files in stricter way. The
BEAM files will be considered different if there are any changes except in
the compilation information ("CInf") chunk. beam_lib:cmp/2 used to ignore
differences in the debug information (significant for Dialyzer) and other
chunks that did not directly change the run-time behavior.
|
|
|
|
The beam_lib:cmp/2 function only compares the executable parts
of the BEAM files, not attributes or abstract code. Since the
types and specs (used by Dialyzer) are contained in the abstract
code, beam_lib:cmp/2 will return 'ok' if the only difference
between two BEAM file are in the types or specs.
If an Erlang/OTP system is installed in a revision control
system, and beam_lib:cmp/2 is used to avoid committing unchanged
but newly compiled BEAM files, BEAM files with no other changes
than in types or specs may not get updated, which can problems
if Dialyzer or the debugger is run.
To avoid that problem, change beam_lib:cmp/2 to compare all
chunks *except* for the "CInf" chunk. The "CInf" chunk contains
the compilation time, compiler options, and compiler version.
|
|
|