| Age | Commit message (Collapse) | Author |
|---|
|
* hasse/stdlib/chars_limit_bug/OTP-15847/ERL-957:
stdlib: Fix a bug concerning io_lib option 'chars_limit'
# Conflicts:
# lib/stdlib/test/io_SUITE.erl
|
|
See also https://bugs.erlang.org/browse/ERL-957.
|
|
* hasse/stdlib/optimize_io_format/OTP-15705:
stdlib: Optimize pretty printing of strings with chars_limit
stdlib: Optimize printing of maps a bit
stdlib: Optimize pretty printing of lists slightly
|
|
* hasse/stdlib/check_spec_module/OTP-15563/ERL-845:
stdlib: Do not allow specs for functions in other modules
|
|
See also https://bugs.erlang.org/browse/ERL-845.
[Kostis:]
My suggestion is that the compiler refuses to compile modules that
contain specs for functions that are not from this module. I do not
remember when / why this `feature' was introduced, but thinking about
it I see a lot of (ugly) semantics issues with it. For example, should
one be allowed to declare in the foo module that lists:flatten/1 takes
an integer() as an argument and returns a binary()? Should one be
allowed to declare a spec in some module m1 for a function of m2 that
is not defined in m2?
There are all kinds of checks that will need to be added to dialyzer
to protect itself from these semantics issues. The compiler already
refuses to compile modules that contain specs for non-existing
functions of the module. Similarly, it should refuse to compile
modules that contain specs for functions of other modules - unless it
can somehow check that these functions are indeed defined, but it is
not how the compiler currently works.
|
|
Avoid traversing all of string arguments when limiting the output with
the 'chars_limit' option.
|
|
Could expand binary to list for to many elements.
Fix and add tests.
|
|
Fixed bug in slice which wrongly could return <<>> for non-utf8 binary input.
Also give a better error reason when non-utf8 binaries are given as
input to some functions.
|
|
This commit fixes an ETS test case that tests the decentralized memory
counter in tables of type ordered_set with the write_concurrency
option turned on. The test case assumed that the memory consumption of
the table would only grow monotonically when terms are
inserted. However, this was not the case when the emulator was
compiled in debug mode as random splits and joins of CA tree nodes
could happen. This commit fixes the test case by disabling random
splits and joins in the tested table.
|
|
|
|
Atomic elements such as atoms, '{}', '[]', and '<<>>' are output on
the same line in types, structs, lists, &c.
In particular types can be more compact, and easier to read.
A space is output after comma in tuples, to be more consistent.
|
|
* hasse/stdlib/erl_pp_quoted_atom_types/OTP-15756:
stdlib: Add option 'quote_singleton_atom_types' to erl_pp
|
|
The new option can be used by Dialyzer, which has traditionally quoted
singleton atom types.
The OTP team has decided not to use the convention in OTP
documentation, at least not for now. That is why the option is needed.
EDoc does not use the new option.
Syntax Tools does not have a similar option.
|
|
* sverker/test-cuddle:
stdlib: Remove ets_SUITE:time_lookup
|
|
Previously, all ETS tables used centralized counter variables to keep
track of the number of items stored and the amount of memory
consumed. These counters can cause scalability problems (especially on
big NUMA systems). This commit adds an implementation of a
decentralized counter and modifies the implementation of ETS so that
ETS tables of type ordered_set with write_concurrency enabled use the
decentralized counter. [Experiments][1] indicate that this change
substantially improves the scalability of ETS ordered_set tables with
write_concurrency enabled in scenarios with frequent `ets:insert/2`
and `ets:delete/2` calls.
The new counter is implemented in the module erts_flxctr
(`erts_flxctr.h` and `erts_flxctr.c`). The module has the suffix
flxctr as it contains the implementation of a flexible counter (i.e.,
counter instances can be configured to be either centralized or
decentralized). Counters that are configured to be centralized are
implemented with a single counter variable which is modified with
atomic operations. Decentralized counters are spread over several
cache lines (how many can be configured with the parameter
`+dcg`). The scheduler threads are mapped to cache lines so that there
is no single point of contention when decentralized counters are
updated. The thread progress functionality of the Erlang VM is
utilized to implement support for linearizable snapshots of
decentralized counters. The snapshot functionality is used by the
`ets:info/1` and `ets:info/2` functions.
[1]: http://winsh.me/ets_catree_benchmark/flxctr_res.html
|
|
Issue an error for improper use of record_info/2 in a fun
OTP-15760
|
|
Fix various spelling mistakes
|
|
* hasse/stdlib/erl_pp_throw/OTP-15751:
stdlib: Fix a bug concerning exception class 'throw'
|
|
`record_info/2` is a pseudo-function that requires literal arguments
known at compile time. Therefore, the following usage is illegal:
f() -> fun record_info/2.
However, `erl_lint` did not issue a compilation error for this usage,
and the compiler would crash in a later pass.
https://bugs.erlang.org/browse/ERL-907
|
|
Since the introduction of the stack trace variable, the Erlang Pretty
Printer has left out the exception class 'throw' even when the stack
trace variable cannot be left out, which is not correct Erlang code.
The fix is to always include the exception class 'throw'.
An alternative is to exclude 'throw' exactly when the stack trace
variable is '_'.
|
|
An appliction outside of OTP may want to reuse then name of a module
that was previously included in OTP. Therefore, there should be
a way to suppress warnings for removed functions.
|
|
|
|
Fails sometimes on windows due to bad timer precision
leading to division by zero.
This is more a (bad) benchmark than a regression test.
|
|
Fix ERL-541 and various other unreported spelling mistakes.
|
|
Make sure the test case meas() terminates without failing.
|
|
* hasse/stdlib/optimize_string/OTP-15649:
stdlib: Optimize handling of Unicode in the string module
stdlib: Optimize handling of Unicode in the string module
stdlib: Fix a bug in string:lexemes()
|
|
Unroll some of the functions returning codepoints and grapheme clusters.
|
|
The unicode_util:cp() function handles deep lists faster by returning
the rest of the input more balanced to the right than before.
|
|
* Refactor the code to make it easier to configure the benchmark
* Add a test case for long benchmark runs. The new test case is run by
the OTP-team's benchmark infrastructure and can help in keeping
track of how the performance of ETS is affected by code changes.
|
|
Allow list of chunks to be given to strip*()
OTP-15680
|
|
Symtom:
ETS table remains fixed after finished ets:select* call.
Problem:
The decision to unfix table after a yielding ets:select*
is based on table ownership, but ownership might have changed
while ets:select* was yielding.
Solution:
Remember and pass along whether table was fixed
when the traversal started.
|
|
This allows extra chunks to be preserved for languages such as Elixir
|
|
into sverker/master/ets-no-mbuf-trapping/OTP-15660
|
|
into sverker/maint/ets-no-mbuf-trapping/OTP-15660
|
|
Many heap fragments do no longer make the GC slow.
Even worse, we are not guaranteed that a yield will provoke a GC
removing the fragments, which might lead to a one-yield-per-bucket
scenario if the heap fragment(s) still remains after each yield.
|
|
* maint:
stdlib: Correct and optimize pretty printing of strings
|
|
Avoid traversing all of the list/string when only part of it will be
used. An explicit check that the list is flat is needed since
string:slice() accepts deep lists and more.
|
|
* maint:
stdlib: Optimize calendar:system_time_to_rfc3339()
|
|
* hasse/stdlib/optimize_calendar_rfc3339/OTP-15630:
stdlib: Optimize calendar:system_time_to_rfc3339()
|
|
The stronger compiler optimizations made the test case fail.
|
|
5239eb0c62a9 removed some optimizations in `sys_core_fold`, and
because of that two warnings are no longer emitted.
|
|
* maint:
stdlib: Fix a bug in the Erlang Pretty Printer
|
|
Not using io_lib for formatting makes the conversion several times
faster.
|
|
Long atom names in combination with <c><<>></c> could cause a crash.
|
|
|
|
Fix bug in binary:encode_unsigned causing a read of uninitialized memory
|
|
* maint:
Optimize calendar:gregorian_days_to_date/1
|
|
Consider this pseudo code:
f(...) ->
Val = case Expr of
... ->
... ;
... ->
... ;
... ->
my_abort(something_went_wrong)
end,
%% Here follows code that uses Val.
.
.
.
my_abort(Reason) ->
throw({error,Reason}).
The first two clauses in the case will probably provide some
information about the type of the variable `Var`, information
that would be useful for optimizing the code that follows the
case.
However, the third clause would ruin everything. The call
to `my_abort/1` could return anything, and thus `Val` could
also have any type.
294d66a295f6 introduced module-level type analysis, which will in
general keep track of the return type of a local function
call. However, it does not improve the optimization for this specific
function. When a function never returns, that is, when its type is
`none`, it does not propagate the `none` type, but instead pretends
that the return type is `any`.
This commit extends the handling of functions that don't return to
properly handle the `none` type. Any instructions that directly
follows the function that does not return will be discarded, and the
call will be rewritten to a tail-recursive call.
For this specific example, it means that the type for `Val` deduced
from the first two clauses will be retained and can be used for
optimizing the code after the case.
|
|
This patch improves the performance of calendar:gregorian_days_to_date/1
by changing the algorithm for finding the year to log-logarithmic.
The old implementation has linear complexity, which makes function
too slow for large values.
For example:
There is an API that allows you to create events for future dates.
There are users of this API who, for some reasons, choose dates
very far in the future. In such conditions, function works very slow.
New implementation based on interpolation search, takes 1 or 2
iterations at most cases and free from such a flaw.
A unit test was also developed to illustrate the speed of a function
at large values.
|
|
The bug could be seen by running the test that is added by this commit
in a valgrind enabled emulator.
Co-authored-by: John Högberg <[email protected]>
|
