| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* jlouis/stdlib/implement-lists-join/PR-1012/OTP-13523:
Implement lists:join/2
|
|
* bjorn/compiler/core-erlang-fixes:
Slightly optimize core_pp
v3_core: Don't depend on sys_core_fold for cleaning up
|
|
* erlang/pr/1006:
Use define-derived-mode to define erlang-mode
|
|
|
|
* gomoripeti/fix-cpu_sup_spec/PR-1029/OTP-13526:
Fix type spec for cpu_sup:util/1
|
|
|
|
* margnus1/dialyzer-maps/PR-1014: (24 commits)
doc: Correct shorthand typo
stdlib: Correct association types
stdlib: Add shadow comments for BIFs in maps
erts: Add exact association types to the abstract format doc
stdlib: Add pretty-printing of exact map types
stdlib: Correct a type in module epp
erl_types: Don't consider opaque keys singleton
erl_types: Fix t_subtract/2 correctness bug
erl_types: Fix crash merging maps with opaque keys
dialyzer_typesig: Fix bad external type
dialyzer: Fix another pattern literal bug
Bump Dialyzer version
dialyzer: Improve map pattern typesetting
dialyzer_contracts: Consider #{} a violation
dialyzer_typesig: Fix simplification bug
dialyzer_dataflow: Fix try in guards
dialyzer: Unfold cerl patterns containing maps
dialyzer_dataflow: Add map support
dialyzer_typesig: Add map support
Enhance map specs in erts, stdlib, runtime_tools
...
|
|
|
|
'...' is allowed at the end of of association types.
|
|
Type information is stored in erl_bif_types for certain BIFs.
This fact must be stated in the type specification for the
stubs that are superceded by erl_bif_types.
* Shadowed by erl_bif_types: maps:from_list/1
* Shadowed by erl_bif_types: maps:get/2
* Shadowed by erl_bif_types: maps:is_key/2
* Shadowed by erl_bif_types: maps:merge/2
* Shadowed by erl_bif_types: maps:put/3
* Shadowed by erl_bif_types: maps:to_list/1
* Shadowed by erl_bif_types: maps:update/3
|
|
|
|
|
|
|
|
Opaque singleton keys have the unfortunate property, unlike any other
singleton type, to overlap with other singleton types that do not have
the same internal representation. Therefore, we must not keep opaque
singletons in the Pairs list in a map type.
|
|
t_subtract/2 would break its postcondition by always returning the
underapproximation none() when given a variable on the right hand side.
This broke map type parsing, since it relied on t_subtract/2 to tell it
when map keys would shadow each other.
|
|
Opaque keys in maps broke an assumption in
erl_types:mapmerge_otherv/3 (that the infinimum of a singleton type and
some other type would either be none() or that same singleton type),
causing a case_clause crash.
|
|
28a4a5057ab9 mistakenly used the non-existing type cerl:tree() instead
of cerl:cerl().
|
|
dialyzer_typesig:traverse/3 would perform an unsafe optimisation when
given a cons pattern that contained a map and could be folded into a
literal with cerl:fold_literal/1. In this case, when traversing the map
a type variable would be generated, but this variable would be dropped
by the erl_types:t_cons/2 constructor by in turn calling t_sup(),
producing the overapproximation any(). However, in this particular case,
dialyzer_typesig:traverse/3 is not allowed to overapproximate, since its
result is used in an EQ-constraint.
Although erl_types:t_tuple/1 does not overapproximate like t_cons/2,
which makes the bug unlikely to affect tuples too, the fix was
nevertheless applied defensively to the case of tuples as well.
Also, fix a bug where dialyzer_utils:refold_pattern/1 would generate
syntax nodes with two {label, _} attributes.
|
|
Because the type representation has changed, old PLTs are not
compatible. We update the version to 2.10 because of this.
|
|
|
|
This is analogous to the case of nil. Since #{} is a base-case of almost
all map types, contract and success typing sharing #{} does not mean
much, and is often sign of a violation.
|
|
mk_constraint_list/2 was simplifying (C OR TriviallyTrue) to (C), which
is obviously wrong.
|
|
The assumption that 'try' nodes were only used to wrap entire guards is
no longer true.
We're still swallowing warnings when the handler returns successfully.
Unfortunately, bind_guard/5 would need to be refactored to return a new
state in order to generate those warnings.
|
|
Dialyzer relies heavily on the assumption that the type of a literal
that is used as a pattern is the type of any value that can match that
pattern. For maps, that is not true, and it was causing bad analysis
results. A new help function dialyzer_utils:refold_pattern/1 identifies
maps in literal patterns, and unfolds and labels them, allowing them to
be properly analysed.
|
|
|
|
|
|
Using the new type syntax, we can specify which keys are required, and
which are optional in a way Dialyzer could use.
|
|
|
|
erl_types typesets mandatory keys with :=, and uses "..." as a shorthand
for "any() => any()". Add these to erl_parse so that all representable
types can be written in type-specs.
|
|
* maps:from_list/1
* maps:get/2
* maps:is_key/2
* maps:merge/2
* maps:put/3
* maps:size/1
* maps:to_list/1
* maps:update/3
|
|
The type of a map is represented as a three-tuple {Pairs, DefaultKey,
DefaultValue}. DefaultKey and DefaultValue are types. Pairs is a list of
three-tuples {Key, mandatory | optional, Value}, where Key and Value are
types. All types Key must be singleton, or "known at compile time," as
the EEP put it. Examples:
#{integer()=>list()} {[], integer(), list()}
#{a=>char(), b=>atom()} {[{a, optional, char()},
{b, optional, atom()}],
none(), none()}
map() {[], any(), any()}
A more formal description of the representation and its invariants can
be found in erl_types.erl
Special thanks to Daniel S. McCain (@dsmccain) that co-authored a very
early version of this with me back in April 2014, although only the
singleton type logic remains from that version.
|
|
|
|
v3_core would generate unsafe code for the following example:
f() ->
{ok={error,E}} = foo(),
E.
Internally, the code would look similar to:
f() ->
Var = foo(),
error({badmatch,Var}),
E.
That is, there would remain a reference to an unbound variable.
Normally, sys_core_fold would remove the reference to 'E', but if
if optimization was disabled the compiler would crash.
|
|
* egil/maps-api-additions/PR-1025/OTP-13522:
stdlib: Document maps:update_with/3,4
stdlib: Add tests for maps:update_with/3,4
stdlib: Add maps:update_with/3,4
erts: Add tests for maps:take/2
stdlib: Document maps:take/2
erts: Add BIF maps:take/2
|
|
* bjorn/compiler/cuddle-with-tests:
compilation_SUITE: Use explicit exports
Remove support for running tests on a separate Erlang node
Move code from compilation_SUITE to beam_block_SUITE
Move list comprehension tests to lc_SUITE
Move catch tests to trycatch_SUITE
Remove compilation_SUITE:long_string/1
Move pattern-matching tests to match_SUITE
Remove toothless test compile_SUITE:missing_testheap/1
misc_SUITE: Add missing export of integer_encoding/0
Move test cases from compilation_SUITE to beam_utils_SUITE
Move complex_guard/1 from compilation_SUITE to guard_SUITE
Remove compilation_SUITE:guards/1
Move tests from compilation_SUITE to record_SUITE
Move bit syntax test cases from compilation_SUITE to bs_match_SUITE
Remove useless test case compilation_SUITE:otp_2141/1
compilation_SUITE: Run the Core linter for all compilations
|
|
|
|
|
|
Maps equivalent to dict:update/3,4
|
|
|
|
|
|
With 'export_all' it is easy to add a new test case function
and forget to add its name to the list of test cases to run.
While we are it, remove unused functions and add the forgotten
test case on_load_inline/1.
|
|
It has not been used for ages.
|
|
|
|
|
|
|
|
long_string/1 was written to test that long string were handled
efficiently in beam_asm. Strings used to be stored in the string
table chunk, but are currently literals.
There does not seem that this test case is likely to find any bugs.
|
|
|
|
missing_testheap/1 is no longer relevant for the following reasons:
1) Because of the literal pool introduced in R12, no test_heap
instructions are needed in the guards.
2) beam_validator would abort the compilation if any needed test_heap
instructions were missing.
|
|
The integer_encoding/1 test is supposed to be run with a tighter
timetrap ensure that encoding of integer in BEAM files is efficient
enough.
|
