* bjorn/compiler/fix-beam_jump-crash/ERL-660/OTP-15166:
  Eliminate a crash in the beam_jump pass

* bjorn/compiler/fix-map_get/OTP-15157:
  Fix internal compiler error for map_get/2

* bjorn/compiler/fix-skipped-matching/ERL-655/OTP-15156:
  beam_type: Fix unsafe optimization

https://bugs.erlang.org/browse/ERL-660

Code such as that the following:

    Val = map_get(a, Map),
    Map#{a:=z}   %Could be any map update

would incorrectly cause an internal consistency check failure:

   Internal consistency check failed - please report this bug.
   Instruction: {put_map_exact,{f,0},{x,0},{x,0},1,{list,[{atom,a},{atom,z}]}}
   Error:       {bad_type,{needed,map},{actual,term}}:

Update beam_validator so that it understands that the second
argument for map_get/2 is a map.

beam_type assumed that the operand for the bs_context_to_binary
instruction must be a binary. That is not correct;
bs_context_to_binary accepts anything. Based on the incorrect
assumption, beam_type would remove other test instructions.

The bug was introduced in eee8655788d2, which was supposed
to be just a refactoring commit.

https://bugs.erlang.org/browse/ERL-655

The compiler would crash when compiling code such as:

    serialize(#{tag := value, id := Id, domain := Domain}) ->
        [case Id of
             nil ->
                 error(id({required, id}));
             _ ->
                 <<10, 1:16/signed, Id:16/signed>>
         end,
         case Domain of
             nil ->
                 error(id({required, domain}));
             _ ->
                 <<8, 2:16/signed, Domain:32/signed>>
         end].

The crash would look like this:

    Function: serialize/1
    t.erl: internal error in block2;
    crash reason: {badmatch,false}

      in function  beam_utils:live_opt/4 (beam_utils.erl, line 861)
      in call from beam_utils:live_opt/1 (beam_utils.erl, line 285)
      in call from beam_block:function/2 (beam_block.erl, line 47)
      in call from beam_block:'-module/2-lc$^0/1-0-'/2 (beam_block.erl, line 33)
      in call from beam_block:'-module/2-lc$^0/1-0-'/2 (beam_block.erl, line 33)
      in call from beam_block:module/2 (beam_block.erl, line 33)
      in call from compile:block2/2 (compile.erl, line 1358)
      in call from compile:'-internal_comp/5-anonymous-1-'/3 (compile.erl, line 349)

The reason for the crash is an assertion failure caused by a previous
unsafe optimization. Here is the code before the unsafe optimization:

       .
       .
       .
    {bs_init2,{f,0},7,0,0,{field_flags,[]},{x,1}}.
    {bs_put_string,3,{string,[8,0,2]}}.
    {bs_put_integer,{f,0},{integer,32},1,{field_flags,[signed,big]},{y,1}}.

    {move,{x,1},{x,0}}.
    {test_heap,4,1}.
       .
       .
       .

beam_block:move_allocate/1 moved up the test_heap/2 instruction past the
move/2 instruction, adjusting the number of live registers at the same
time:

       .
       .
       .
    {bs_init2,{f,0},7,0,0,{field_flags,[]},{x,1}}.
    %% Only x1 is live now.
    {bs_put_string,3,{string,[8,0,2]}}.
    {bs_put_integer,{f,0},{integer,32},1,{field_flags,[signed,big]},{y,1}}.

    {test_heap,4,2}.     %Unsafe. x0 is dead.
    {move,{x,1},{x,0}}.
       .
       .
       .

This optimization is unsafe because the bs_init2 instruction killed
x0.

The bug is in beam_utils:anno_defs/1, which adds annotations indicating
the registers that are defined at the beginning of each block. The
annotation before the move/2 instruction incorrectly indicated that
x0 was live.

https://bugs.erlang.org/browse/ERL-650
https://github.com/elixir-lang/elixir/issues/7782

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.)