aboutsummaryrefslogtreecommitdiffstats
path: root/lib
AgeCommit message (Collapse)Author
2015-02-05Merge branch 'maint'Hans Nilsson
* maint: Fix ssh:connect erroneus error msg at timeout
2015-02-05Fix ssh:connect erroneus error msg at timeoutHans Nilsson
2015-02-05Merge branch 'maint'Zandra Hird
2015-02-05Merge branch 'scrapinghub/httpc_set_cookie_with_empty_values' into maintZandra Hird
* scrapinghub/httpc_set_cookie_with_empty_values: inets: parse correctly 'Set-Cookie' header with empty value OTP-12455
2015-02-05Merge branch 'bjorn/compiler/dup-bug-fix/OTP-12453'Björn Gustavsson
* 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
2015-02-05Merge branch 'bjorn/compiler/map-core-syntax/OTP-12454'Björn Gustavsson
* bjorn/compiler/map-core-syntax/OTP-12454: Make the syntax for map pairs readable
2015-02-05Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap Correct unsafe optimization of '==' and '/=' Conflicts: bootstrap/lib/compiler/ebin/sys_core_fold.beam
2015-02-04Correct unsafe optimization of '==' and '/='Björn Gustavsson
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.
2015-02-03Merge branch 'maint'Zandra Hird
Conflicts: OTP_VERSION erts/emulator/sys/unix/sys.c erts/vsn.mk
2015-02-03Merge branch 'maint-17' into maintZandra Hird
2015-02-03Teach case_opt/3 to avoid unnecessary buildingBjörn Gustavsson
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.
2015-02-03inets: parse correctly 'Set-Cookie' header with empty valueKirilll Zaborsky
httpc_cookie should parse cookies with empty values and no attributes set in the 'Set-Cookie' headers.
2015-02-03sys_core_fold: Optimize let statements more aggressivelyBjörn Gustavsson
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.
2015-02-03Suppress warnings for expressions that are assigned to '_'Björn Gustavsson
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}'
2015-02-03Merge branch 'maint'Björn Gustavsson
* 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
2015-02-03Be more careful about map patterns when evalutating element/2Björn Gustavsson
We must not convert map patterns to map expressions.
2015-02-03Do not convert map patterns to map expressionsBjörn Gustavsson
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.
2015-02-02Merge branch 'maint'Ingela Anderton Andin
2015-02-02Merge branch 'ia/ssl/self-signed-root/OTP-12449' into maintIngela Anderton Andin
* ia/ssl/self-signed-root/OTP-12449: ssl: Remove selfsigned anchor certificate from the certificate chain
2015-01-30ssl: Remove selfsigned anchor certificate from the certificate chainIngela Anderton Andin
A selfsigned trusted anchor should not be in the certifcate chain passed to the certificate path validation. Conflicts: lib/ssl/src/ssl_certificate.erl
2015-01-30Prepare releaseErlang/OTP
2015-01-30Make the syntax for map pairs readableBjörn Gustavsson
Use the same syntax for map pairs in Core Erlang code as in the Erlang Code. This Erlang code: M#{x:=42,y=>1} will look like this in Core Erlang: ~{'x':=42,'y'=>1|M}~
2015-01-30inets: Consistent view of configuration parameter keep_alive_timeoutIngela Anderton Andin
2015-01-30inets: httpd - mod_alias now handles https URIsIngela Anderton Andin
2015-01-30Merge branch 'mikpe/hipe-code-alloc-fixes'Marcus Arendt
* mikpe/hipe-code-alloc-fixes: hipe: improve error handling at code allocation failure hipe: remove two obsolete BIFs hipe: remove HIPE_ALLOC_CODE macro
2015-01-29inets: httpd - Sanity check of content-length headerIngela Anderton Andin
Gracefully handle invalid content-lenght headers instead of crashing in list_to_integer.
2015-01-29Merge branch 'maint'Bruce Yinhe
2015-01-29Merge branch '0xAX/inets-typo-fix' into maintBruce Yinhe
* 0xAX/inets-typo-fix: lib/inets: fix typo in httpd_load_test example
2015-01-29Merge branch 'bjorn/compiler/map-fixes'Björn Gustavsson
* bjorn/compiler/map-fixes: cerl: Remove a clause in fold_map_pairs/3 that will never be reached Move grouping of map constructions from v3_core to v3_kernel core_pp: Correct printing of map literals Strengthen and modernize compile_SUITE core_parse: Always fold literal conses cerl: Make sure that we preserve the invariants for maps cerl_clauses: Fix indentation sys_core_fold: Strengthen optimization of letrecs in effect context Fix handling of binary map keys in comprehensions core_lib: Teach is_var_used/2 to handle keys in map patterns warnings_SUITE: Eliminate compiler warning for a shadowed variable lc_SUITE: Add shadow/1 Modernize lc_SUITE
2015-01-29cerl: Remove a clause in fold_map_pairs/3 that will never be reachedBjörn Gustavsson
2015-01-29Move grouping of map constructions from v3_core to v3_kernelBjörn Gustavsson
When translating a function with map construction: f(A) -> B = b, C = c, #{A=>1,B=>2,C=>3}. v3_core would break apart the map construction into three parts because of the way the map instructions in BEAM work -- variable keys need to be in their own instruction. In the example, constant propagation will turn two of the keys to literal keys. But the initial breaking apart will not be undone, so there will still be three map constructions: 'f'/1 = fun (_cor0) -> let <_cor3> = ~{::<_cor0,1>}~ in let <_cor4> = ~{::<'b',2>|_cor3}~ in ~{::<'c',3>|_cor4}~ It would be possible to complicate the sys_core_fold pass to regroup map operations so that we would get: 'f'/1 = fun (_cor0) -> let <_cor3> = ~{::<_cor0,1>}~ in ~{::<'b',2>,::<'c',3>|_cor3}~ A simpler way that allows to simplify the translation is to skip the grouping in v3_core and translate the function to: 'f'/1 = fun (_cor0) -> ~{::<_cor0,1>,::<'b',2>,::<'c',3>}~ We will then let v3_kernel do the grouping while translating from Core Erlang to Kernel Erlang.
2015-01-28core_pp: Correct printing of map literalsBjörn Gustavsson
A map key in a pattern would be incorrectly pretty-printed. As an example, the pattern in: x() -> #{ #{ a => 3 } := 42 } = X. would be pretty-printed as: <~{~<~{~<'a',3>}~,42>}~ instead of: <~{~<~{::<'a',3>}~,42>}~ When this problem has been corrected, the workaround for it in cerl:ann_c_map/3 can be removed. The workaround was not harmless, as it would cause the following map update to incorrectly succeed: (#{})#{a:=1}
2015-01-28sys_core_fold: Remove uncovered clauses matching #c_map{}Björn Gustavsson
sys_core_fold:eval_element/3 attempts to evaluate calls to element/2 at compile time or to warn when the call will obviously fail. For example: element(1, [a]) will obviously fail and eval_element/3 will produce a warning. eval_element/3 uses the helper functions is_not_integer/1 and is_not_tuple/1 to test whether the arguments are known to be incorrect. The clauses that attempt to match #c_map{} in those helper function will never be executed, because #c_map{} will never occur directly in an argument for a function call. For example, code such as: element(1, #{a=>Val}) will be translated to: let <NewVar> = #{a=>Val} in element(1, NewVar) since maps are not considered safe (some map operations may cause an exception at run time).
2015-01-27Strengthen and modernize compile_SUITEBjörn Gustavsson
When we compile from Core Erlang, do it with and without Core Erlang optimizations to ensure that we are not dependent on the optimizations always being run.
2015-01-27core_parse: Always fold literal consesBjörn Gustavsson
v3_core is careful to always create literals whenever possible. Correct core_parse so it, too, always creates literals out of literal conses. With that correction, we can remove the workaround in sys_core_fold (introduced in 26a5dea3cb5e101) that handles non-literal flags in a binary.
2015-01-26beam_z: Remove the uncovered to_typed_literal/1 functionBjörn Gustavsson
It was a workaround for a bug that has been fixed.
2015-01-26Speed up running of compiler test suites in coverage modeBjörn Gustavsson
I have spent too much time lately waiting for 'cover' to finish, so now its time to optimize the running time of the tests suite in coverage mode. Basically, when 'cover' is running, the test suites would not run any tests in parallel. The reason is that using too many parallel processes when running 'cover' would be slower than running them sequentially. But those measurements were made several years ago, and many improvements have been made to improve the parallelism of the run-time system. Experimenting with the test_lib:p_run/2 function, I found that increasing the number of parallel processes would speed up the self_compile tests cases in compilation_SUITE. The difference between using 3 processes or 4 processes was slight, though, so it seems that we should not use more than 4 processes when running 'cover'. We don't want to change test_lib:parallel/0, because there is no way to limit the number of test cases that will be run in parallel by common_test. However, there as test suites (such as andor_SUITE) that don't invoke the compiler at run-time. We can run the cases in such test suites in parallel even if 'cover' is running.
2015-01-26hipe: remove two obsolete BIFsMikael Pettersson
The hipe_bifs:make_native_stub/2 and hipe_bifs:get_emu_address/1 BIFs were originally used by hipe_unified_loader.erl, but the code been obsolete and disabled for ages. Remove the BIFs and all references to them. In hipe_unified_loader.erl, remove the no-op emu_make_stubs/1 function.
2015-01-26Merge branch 'vladdu/edoc_remove_packages/OTP-12431'Marcus Arendt
* vladdu/edoc_remove_packages/OTP-12431: [edoc] remove functionality related to packages [edoc] add test for nested source directories
2015-01-26cerl: Make sure that we preserve the invariants for mapsBjörn Gustavsson
Maps have certain invariants that must be preserved: (1) A map as a pattern must be represented as #c_map{} record, never as a literal. The reason is that the pattern '#{}' will match any map, not just the empty map. The literal '#{}' will only match the empty map. (2) In a map pattern, the key must be a literal, a variable, or data (list or tuple). Keys that are binaries or maps *must* be represented as literals. (3) Maps in expressions should be represented as literals if possible. Nothing is broken if this invariant is broken, but the generated code will be less efficient. To preserve invariant (1), cerl:update_c_map/3 must never collapse a map to a literal. To preserve invariant (3), cerl:update_c_map/3 must collapse a map to a literal if possible. To preserve both invariants, we need a way for cerl:update_c_map/3 to know whether the map is used as a pattern or as an expression. The simplest way is to have an 'is_pat' boolean in the #c_map{} record which is set when a #c_map{} record is initially created. We also need to update core_parse.yrl to establish the invariants in the same way as v3_core, to ensure that compiling from a .core file will work even if all optimizations on Core Erlang are disabled.
2015-01-26cerl_clauses: Fix indentationBjörn Gustavsson
2015-01-26sys_core_fold: Strengthen optimization of letrecs in effect contextBjörn Gustavsson
We used to evaluate the body of a 'letrec' in value context, even if the 'letrec' was being evaluated in effect context. In most cases, the context does not matter because the body is usually just an 'apply' which will never be optimized away. However, in the case of incorrect code described in the previous commit, it does matter. We can find such bad code by evaluating the body in effect context. For example, if we have the following incorrect code: letrec f/1 = fun(A) -> ... <use of Var> ... in let Var = <<2:301>> in apply(Arg) If the letrec is evaluated in effect context, the code will be reduced to: letrec f/1 = fun(A) -> ... <use of Var> ... in seq Var = <<2:301>> do apply(Arg) Now Var will be unbound and a later compiler pass will crash to ensure that the bad Core Erlang code is noticed. Also add a test case to ensure that the compiler crashes if the bug fixed in the previous commit re-surfaces.
2015-01-26Fix handling of binary map keys in comprehensionsBjörn Gustavsson
The translation of list comprehension with a map pattern with a big literal binary as key such as: lc(L) -> [V || #{<<2:301>> := V} <- L]. would generate Core Erlang code where an unbound variable were referenced: 'lc'/1 = fun (L) -> letrec 'lc$^0'/1 = fun (_cor4) -> case _cor4 of <[~{~<_cor1,V>}~|_cor3]> when 'true' -> let <_cor5> = apply 'lc$^0'/1(_cor3) in [V|_cor5] <[_cor2|_cor3]> when 'true' -> apply 'lc$^0'/1(_cor3) <[]> when 'true' -> [] end in let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}# in apply 'lc$^0'/1(L) In the map pattern in the 'case' in the 'letrec', the key is the variable '_cor1' which should be bound in the enclosing environment. It is not. There is binding of '_cor1', but in the wrong place (at the end of the function). Because of the way v3_kernel translates letrecs, the code *happens* to work. The code will break if Core Erlang optimizations were strengthened to more aggressively eliminate variable bindings that are not used, or if the translation from Core Erlang to Kernel Erlang were changed. Correct the translation so that '_cor1' is bound in the environment enclosing the 'letrec': 'lc'/1 = fun (L) -> let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}# in letrec 'lc$^0'/1 = fun (_cor4) -> case _cor4 of <[~{~<_cor1,V>}~|_cor3]> when 'true' -> let <_cor5> = apply 'lc$^0'/1(_cor3) in [V|_cor5] <[_cor2|_cor3]> when 'true' -> apply 'lc$^0'/1(_cor3) <[]> when 'true' -> [] end in apply 'lc$^0'/1(L) Unfortunately I was not able to come up with a test case that demonstrates the bug.
2015-01-26Merge branch 'maint'Marcus Arendt
2015-01-26Merge branch 's1n4/httpc_invalid_set_cookies/OTP-12430' into maintMarcus Arendt
* s1n4/httpc_invalid_set_cookies/OTP-12430: httpc: Avoid parsing invalid 'Set-Cookie' headers
2015-01-26core_lib: Teach is_var_used/2 to handle keys in map patternsBjörn Gustavsson
is_var_used/2 did not notice that variable keys in map patterns were used, which could cause sys_core_fold to do unsafe optimizations.
2015-01-26warnings_SUITE: Eliminate compiler warning for a shadowed variableBjörn Gustavsson
2015-01-26lc_SUITE: Add shadow/1Björn Gustavsson
2015-01-26Modernize lc_SUITEBjörn Gustavsson
Remove ?line macros. Run test cases in parallel.
2015-01-26Merge branch 'maint'Ingela Anderton Andin