| Age | Commit message (Collapse) | Author |
|---|
|
In the future, erlang:get_stacktrace/0 will probably only work
inside a the 'catch' block of a 'try' expression.
Future-proof the code by rewriting the old-style catch to
a try...catch.
|
|
The extended parser introduced in last commit is used in qlc for
solving an old bug: pids and refs could not be parsed by
string_to_handle(). The parser is also used for adjustments regarding
ETS identifiers (now references) in qlc_SUITE.
Notice that pids, references, ports, and external functions that
cannot be created in the currently running system cause syntax errors
(as before).
|
|
|
|
|
|
* maint:
xmerl: Remove 'no_return' Dialyzer warnings
xmerl: Add suppression of Dialyzer warnings
eunit: Add suppression of Dialyzer warnings
debugger: Add suppression of Dialyzer warnings
kernel: Add suppression of Dialyzer warnings
mnesia: Add suppression of Dialyzer warnings
observer: Add suppression of Dialyzer warnings
runtime_tools: Add suppression of Dialyzer warnings
stdlib: Add suppression of Dialyzer warnings
test_server: Add suppression of Dialyzer warnings
tools: Add suppression of Dialyzer warnings
Conflicts:
lib/stdlib/src/erl_lint.erl
lib/stdlib/src/otp_internal.erl
|
|
|
|
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.
|
|
|
|
|
|
|
|
The current code for the evaluation of ordinary funs is dependent
on the order on variables in the fun environment as returned by
erlang:fun_info(Fun, env).
To avoid the problem in the future, make sure that we only have one
free variable in the funs that we will need to inspect using
erlang:fun_info(Fun, env).
|
|
|
|
|
|
|
|
Opaque types need to be exported.
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
|
|
|
|
* ks/stdlib-cleanups:
stdlib: clean up as suggested by tidier
OTP-8435: ks/stdlib-cleanups
|
|
Hans Bolinder (the author/maintainer of qlc) prefers
for readability reasons to use length/1 in a guard
when it is known that the list is guaranteed to be
short, so the change suggested by tidier for line 875
of qlc_pt has not been included.
|
|
|
