Age | Commit message (Collapse) | Author |
|
We are about to deprecate core_lib:get_anno/1 and core_lib:set_anno/2,
so we should stop using them in the compiler.
|
|
Attributes must be literals. Since 1fcdcd50, both core_parse and
v3_core guarantees all Core Erlang terms that may be represented as
literals in fact are represented as literals.
Therefore, we no longer need to call core_lib:is_literal/1, but
can test for a #c_literal{} directly.
|
|
This module is the last that uses -include() instead of
include_lib(). With that change, a quick smoke test can
be done simply like this:
PATH=$ERL_TOP/bin:$PATH erlc -W0 *.erl
Without the change, you would also need to add
-I $ERL_TOP/lib/test_server/include
to the command line.
|
|
Rename add_scope/2 to sub_add_scope/2 to be similar in naming as
the other functions that operates on #sub{} (in particular,
sub_subst_scope/1). Also, move the definition to be near to the
other sub_* functions.
|
|
Compiling the following function:
f(V) when not (bar and V) -> true; %Line 4
f(_) -> false.
would produce the following warnings:
no_file: Warning: the call to is_boolean/1 has no effect
t.erl:4: Warning: the guard for this clause evaluates to 'false'
t.erl:4: Warning: use of operator '=:=' has no effect
Two of the warnings refer to calls to is_boolean/1 and '=:='/2 which
v3_core added when translating the code to Core Erlang. The only
relevant warning is:
t.erl:4: Warning: the guard for this clause evaluates to 'false'
Suppress the other two warning by marking the compiler-generated
calls with a 'compiler_generated' annotation.
|
|
|
|
|
|
Core Erlang annotations are supposed to be a list of terms. v3_core
could temporarily stuff a record in the 'anno' field of a Core Erlang
record. That will cause Dialyzer warnings if we would tighten the
type specs for annotations. (We want to tighten the warnings in order
to catch more real problems.)
Avoid abusing the annotation by wrapping the entire Core Erlang
record in a #isimple{} record.
Reported-by: Kostis Sagonas
|
|
* maint:
mnesia: Check nodes after protocol negotiation
|
|
'dumbbell/mnesia-hang-if-remote-stopped-after-proto-negotiation' into maint
* dumbbell/mnesia-hang-if-remote-stopped-after-proto-negotiation:
mnesia: Check nodes after protocol negotiation
OTP-12473
|
|
During Mnesia startup, after protocol negotiation, the list of connected
nodes is written to "recover_nodes". This list is later used to merge
the schema.
If Mnesia was stopped on a remote node between the protocol negotiation
and the moment the list is stored in "recover_nodes", the remote node
is still considered running: the value of "recover_nodes" stored during
mnesia_down/1 is overwritten. Therefore, this node may be used to
acquire a write lock on the schema in order to perform the merge. In
this case, the remote node never answers to the lock request and Mnesia
hang forever (application:start(mnesia) never returns).
To fix the problem, we check the list one last time and remove from it
all nodes where Mnesia is stopped. And because there is still a chance
for missing mnesia_down event, handle_cast({mnesia_down, ...}, ...)
writes to recover_nodes again, in addition to mnesia_down/1.
|
|
|
|
* ia/ssl/timestamp:
ssl: erlang:timestamp -> os:timestamp
|
|
For comparison with file time stamps os:timestamp makes more sense
and is present in 17 as well as 18.
|
|
Conflicts:
lib/ssl/doc/src/ssl_app.xml
lib/ssl/src/ssl_manager.erl
|
|
* ia/ssl/pem-cache/OTP-12464:
ssl: Improve PEM cache by validating entries
|
|
The PEM cache is now validated by a background process, instead of
always keeping it if it is small enough and clearing it otherwhiss.
That strategy required that small caches where cleared by API function
if a file changes on disk.
However document the clearing API function as it can still be usefull.
|
|
* maint:
Fix ssh:connect erroneus error msg at timeout
|
|
* hans/ssh/error_timeout/OTP-12369:
Fix ssh:connect erroneus error msg at timeout
|
|
|
|
|
|
* scrapinghub/httpc_set_cookie_with_empty_values:
inets: parse correctly 'Set-Cookie' header with empty value
OTP-12455
|
|
|
|
* bjorn/compiler/dup-bug-fix/OTP-12453:
Teach case_opt/3 to avoid unnecessary building
sys_core_fold: Optimize let statements more aggressively
Suppress warnings for expressions that are assigned to '_'
trace_bif_SUITE: Ensure that a call to time/0 is not removed
|
|
* bjorn/compiler/map-core-syntax/OTP-12454:
Make the syntax for map pairs readable
|
|
* maint:
Update primary bootstrap
Correct unsafe optimization of '==' and '/='
Conflicts:
bootstrap/lib/compiler/ebin/sys_core_fold.beam
|
|
|
|
* bjorn/compiler/maps-comparison/OTP-12456:
Correct unsafe optimization of '==' and '/='
|
|
Since '=:=' is cheaper than '==', the compiler tries to replace
'==' with '=:=' if the result of comparison will be the same.
As an example:
V == {a,b}
can be rewritten to:
V =:= {a,b}
since the literal on the right side contains no numeric values
that '==' would compare differently to '=:='.
With the introduction of maps, we will need to take them into
account. Since the comparison of maps is planned to change in 18.0,
we will be very conservative and only do the optimization if
both keys and values are non-numeric.
|
|
* henrik/fix-master:
fix faulty merge
|
|
|
|
Conflicts:
OTP_VERSION
erts/emulator/sys/unix/sys.c
erts/vsn.mk
|
|
|
|
Given this code:
f(S) ->
F0 = F1 = {S,S},
[F0,F1].
case_opt/3 would "optimize" it like this:
f(S) ->
F1 = {S,S},
F0 = {S,S},
[F0,F1].
Similarly, this code:
g({a,_,_}=T) ->
{b,
[_,_] = [T,none],
x}.
would be rewritten to:
g({a,Tmp1,Tmp2}=T) ->
Tmp3 = {a,Tmp1,Tmp2},
{b,
[Tmp3,none],
x}.
where the tuple is rebuilt instead of using the T variable.
Rewrite case_opt/3 to be more careful while optimizing.
|
|
httpc_cookie should parse cookies with empty values
and no attributes set in the 'Set-Cookie' headers.
|
|
I originally decided that in 'value' context, rewriting a let statement
where the variables were not in the body to a sequence was not worth
it, because the variables would be unused in only one let in a
thousand lets (roughly).
I have reconsidered.
The main reason is that if we do the rewrite, core_lib:is_var_used/2
will be used much more frequently, which will help us to find bugs
in it sooner.
Another reason is that the way letify/2 is currently implemented
with its own calls to core_lib:is_var_used/2 is only safe as long
as all the bindings are independent of each other. We could make
letify/2 smarter, but if we introduce this new optimization there
is no need.
Measuring compilation speed, I have not seen any significant slowdown.
It seems that although core_lib:is_var_used/2 is called much more
frequently, most calls will be fast because is_var_used/2 will quickly
find a use of the variable.
Also add a test case to cover a line opt_guard_try/1 that was
no longer covered.
|
|
In c34ad2d5, the compiler learned to silence some warnings for
expressions that were explicitly assigned to the '_' variable,
as in this example:
_ = list_to_integer(S),
ok
That commit intentionally only made it possible to silence warnings
for BIFs that could cause an exception. Warnings would still be
produced for:
_ = date(),
ok
because date/0 can never fail and thus making the call completely
useless. The reasoning was that such warnings can always be
eliminated by eliminating the offending code.
While that is true, there is the question about rules and their
consistency. It is surprising that '_' can be used to silence
some warnings, but has no effect on other warnings.
Therefore, we will teach the compiler to silence warnings for
the following constructs:
* Calls to safe BIFs such as date/0
* Expressions that will cause an exception such as 'X/0'
* Terms that are built but not used, such as '{x,X}'
|
|
Assigning the result of a BIF call to a variable used to be
sufficient to prevent the call from being optimized away. With
the more aggressive optimization that will be introduced in
a future commit it will not be sufficient.
Matching the return value will prevent the compiler from doing
the optimization.
|
|
* maint:
Update primary bootstrap
Be more careful about map patterns when evalutating element/2
Do not convert map patterns to map expressions
Conflicts:
bootstrap/lib/compiler/ebin/sys_core_fold.beam
lib/compiler/test/match_SUITE.erl
|
|
|
|
* bjorn/compiler/map-bugs/OTP-12451:
Be more careful about map patterns when evalutating element/2
Do not convert map patterns to map expressions
|
|
We must not convert map patterns to map expressions.
|
|
In code such as:
case {a,Map} of
{a,#{}}=T ->
T
end
we must NOT rewrite a map pattern to a map expression like this:
case Map of
#{} ->
{a,#{}}
end
because the pattern '#{}' will match any map, but the expression
'#{}' will construct an empty map.
|
|
|
|
* ia/ssl/self-signed-root/OTP-12449:
ssl: Remove selfsigned anchor certificate from the certificate chain
|
|
A selfsigned trusted anchor should not be in the certifcate chain passed to
the certificate path validation.
Conflicts:
lib/ssl/src/ssl_certificate.erl
|
|
|
|
|
|
* egil/fix-getifaddrs-realloc/OTP-12445:
erts: Fix getifaddrs realloc ptr mismatch
|
|
* egil/fix-child_setup-close/OTP-12446:
erts: Use closefrom() if available when closing fds
erts: Don't close all fds twice in child_setup
|