sys_core_fold could do unsafe transformations on the
code from the old inliner (invoked using the compiler
option `{inline,[{F/A}]}` to request inlining of specific
functions).

To explain the bug, let's first look at an example that
sys_core_fold handles correctly. Consider this code:

    'foo'/2 =
        fun (Arg1,Arg2) ->
          let <B> = Arg2
          in let <A,B> = <B,Arg1>
             in {A,B}

In this example, the lets can be completely eliminated,
since the arguments for the lets are variables (as opposed
to expressions). Since the variable B is rebound in the
inner let, `sys_core_fold` must take special care when
doing the substitutions.

Here is the correct result:

    'foo'/2 =
        fun (Arg1, Arg2) ->
          {Arg2,Arg1}

Consider a slight modifictation of the example:

    'bar'/2 =
        fun (Arg1,Arg2) ->
            let <B> = [Arg2]
            in let <A,B> = <B,[Arg1]>
               in {A,B}

Here some of the arguments for the lets are expressions, so
the lets must be kept. sys_core_fold does not handle this
example correctly:

    'bar'/2 =
        fun (Arg1,Arg2) ->
          let <B> = [Arg2]
    	  in let <B> = [Arg1]
    	     in {B,B}

In the inner let, the variable A has been eliminated and
replaced with the variable B in the body (the first B in
the tuple). Since the B in the outer let is never used,
the outer let will be eliminated, giving:

    'bar'/2 =
        fun (Arg1,Arg2) ->
    	  let <B> = [Arg1]
    	  in {B,B}

To handle this example correctly, sys_core_fold must
rename the variable B in the inner let like this to
avoid capturing B:

    'bar'/2 =
       fun (Arg1,Arg2) ->
         let <B> = [Arg2]
         in let <NewName> = [Arg1]
            in {B,NewName}

(Note: The `v3_kernel` pass alreday handles those examples correctly
in case `sys_core_fold` has been disabled.)

The sys_core_fold pass would do an unsafe "optimization" when an
apply operation did not have a variable in the function position
as in the following example:

> cat test1.core
module 'test1' ['test1'/2]
    attributes []
'i'/1 =
  fun (_f) -> _f
'test1'/2 =
  fun (_f, _x) ->
    apply apply 'i'/1 (_f) (_x)
end
> erlc test1.core
no_file: Warning: invalid function call

Reported-by: Mikael Pettersson

The compiler produces poor code for complex guard expressions with andalso/orelse.
Here is an example from the filename module:

-define(IS_DRIVELETTER(Letter),(((Letter >= $A) andalso (Letter =< $Z)) orelse
				((Letter >= $a) andalso (Letter =< $z)))).
skip_prefix(Name, false) ->
    Name;
skip_prefix([L, DrvSep|Name], DrvSep) when ?IS_DRIVELETTER(L) ->
    Name;
skip_prefix(Name, _) ->
    Name.

beam_bool fails to simplify the code for the guard, leaving several 'bif'
instructions:

{function, skip_prefix, 2, 49}.
  {label,48}.
    {line,[{location,"filename.erl",187}]}.
    {func_info,{atom,filename},{atom,skip_prefix},2}.
  {label,49}.
    {test,is_ne_exact,{f,52},[{x,1},{atom,false}]}.
    {test,is_nonempty_list,{f,52},[{x,0}]}.
    {get_list,{x,0},{x,2},{x,3}}.
    {test,is_nonempty_list,{f,52},[{x,3}]}.
    {get_list,{x,3},{x,4},{x,5}}.
    {bif,'=:=',{f,52},[{x,1},{x,4}],{x,6}}.
    {test,is_ge,{f,50},[{x,2},{integer,65}]}.
    {bif,'=<',{f,52},[{x,2},{integer,90}],{x,7}}.
    {test,is_eq_exact,{f,51},[{x,7},{atom,false}]}.
    {test,is_ge,{f,50},[{x,2},{integer,97}]}.
    {bif,'=<',{f,52},[{x,2},{integer,122}],{x,7}}.
    {jump,{f,51}}.
  {label,50}.
    {move,{atom,false},{x,7}}.
  {label,51}.
    {bif,'=:=',{f,52},[{x,7},{atom,true}],{x,7}}.
    {test,is_eq_exact,{f,52},[{x,6},{atom,true}]}.
    {test,is_eq_exact,{f,52},[{x,7},{atom,true}]}.
    {move,{x,5},{x,0}}.
    return.
  {label,52}.
    return.

We can add optimizations of guard tests to v3_kernel to achive a better result:

{function, skip_prefix, 2, 49}.
  {label,48}.
    {line,[{location,"filename.erl",187}]}.
    {func_info,{atom,filename},{atom,skip_prefix},2}.
  {label,49}.
    {test,is_ne_exact,{f,51},[{x,1},{atom,false}]}.
    {test,is_nonempty_list,{f,51},[{x,0}]}.
    {get_list,{x,0},{x,2},{x,3}}.
    {test,is_nonempty_list,{f,51},[{x,3}]}.
    {get_list,{x,3},{x,4},{x,5}}.
    {test,is_eq_exact,{f,51},[{x,1},{x,4}]}.
    {test,is_ge,{f,51},[{x,2},{integer,65}]}.
    {test,is_lt,{f,50},[{integer,90},{x,2}]}.
    {test,is_ge,{f,51},[{x,2},{integer,97}]}.
    {test,is_ge,{f,51},[{integer,122},{x,2}]}.
  {label,50}.
    {move,{x,5},{x,0}}.
    return.
  {label,51}.
    return.

Looking at the STDLIB application, there were 112 lines of BIF calls in guards
that beam_bool failed to convert to test instructions. This commit eliminates
all those BIF calls.

Here is how I counted the instructions:

$ PATH=$ERL_TOP/bin:$PATH erlc -I ../include -I ../../kernel/include -S *.erl
$ grep "bif,'[=<>]" *.S | grep -v f,0
dets.S:    {bif,'=:=',{f,547},[{x,4},{atom,read_write}],{x,4}}.
dets.S:    {bif,'=:=',{f,547},[{x,5},{atom,saved}],{x,5}}.
dets.S:    {bif,'=:=',{f,589},[{x,5},{atom,read}],{x,5}}.
.
.
.
$ grep "bif,'[=<>]" *.S | grep -v f,0 | wc
     112     224    6765
$

For tidiness, always place .core files in data directories.

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}~

Ex.

Instead of:

    M~{~<K,V>}~

The format is now:

    ~{~<K,V>|M}~

This also removes a shift/reduce warning.

The changes in core_pp now requires compiler-5.0 to compile
because of is_map/1 guard, i.e. a need for a compiler with Maps know-how.

Expressions such as erlang:'or'(bar, true) can make beam_bool crash if it tries
to optimize them, as this code is not quite really written by users, no attempt
to rewrite them more efficiently should be done, for simplicity's sake.

Reported-by: Ulf Norell

Starting in e12b7d5331c58b41db06cadfa4af75b78b62a2b1,
sys_core_fold:eval_case/2 will crash on handwritten but legal
Core Erlang programs such as:

   case let <Var> = Arg in {'x',Var} of
      {x,X} -> X
   end

The problem is that the only clause *is* guaranteed to match, but
cerl_clauses:match_list/2 does not understand that; all it can say is
that the clause *may* match. In those circumstances, we will need to
keep the case.

Also make sure that we keep the case if the guard is something else
than 'true'. That is not strictly necessary, because in a legal Core
Erlang program the guard in the last clause in a case must always
evaluate to 'true', so removing the guard test would still leave the
program correct. Keeping the guard, however, will make it somewhat
easier to debug an incorrect Core Erlang program. (The unsafe_case
test case has guard test in the only clause in a case, so we don't
need to write a new test case to test that.)

Reported-by: Anthony Ramine

A guard with a sequence will cause a crash in v3_codegen. Currently,
it seems that a sequence in a guard will never happen when compiling
from Erlang code, but there are several reasons to fix this problem
anyway:

* There are other compilers that generate Core Erlang code.

* Changes to sys_core_fold (perhaps additional optimizations) may
  cause sequences to be generated in guards.

* A previously uncovered line in sys_core_fold:opt_guard_try/1 will
  now be covered.