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.

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.

core_lib:is_var_used/2 would not consider a variable used in the
value of a map pattern such as:

  case Map of
    #{key := <<42:N>>} -> ok
  end

Here the variable 'N' would not be considered used.

It was assumed that there was no need to check map patterns at
all, since maps currently don't support variables in keys.

* bjorn/compiler/map-in-record-bug/OTP-12402:
  sys_core_fold: Correct optimization of 'case'

When optimizing boolean expressions, it is not always possible
to find a number of live registers for a GC BIF that both preserves
all source registers that will be tested and at the same time
does not include registers that are not initialized.

As currently implemented, we have incomplete information about
the register calculated from the free variables. Some registers
are marked as "reserved". Reserved registers means that we don't
know anything about them; they may or may not be initialized.

As a conservative correction (suitable for a maintenance release), we
will abort the optimization if we find any reserved registers when
calculating the number of live registers. We will not attempt to
improve the information about the registers in this commit.

By examining the coverage when running the existing compiler test
suite we find that the optimization is aborted 15 times (before
adding any new test cases). To put that in perspective, the
optimization is successfully applied 4927 times, and aborted for
other reasons 547 times.

Reported-by: Ulf Norell
Reported-by: Anthony Ramine

Old versions of the Erlang mode for Emacs used to indent try...catch
strangely - the first clause following the 'catch' would be indented
with one space less than the following clauses.

If we are to use the new Erlang mode when we add more clauses, they
would be indented with one space less than the preceding clauses.
That would look silly.

The optimization of a 'case' statement could lead to incorrect
code that would cause an exception at run-time.

Here is an example to show how the optimization went wrong. Start
with the following code:

  f({r,#{key:=Val},X}=S) ->
    case S of
      {r,_,_} ->
        setelement(3, Val, S)
    end.

(The record operations have already been translated to the
corresponding tuple operations.) The first step in case_opt/3 is
to substitute S to obtain:

  f({r,#{key:=Val},X}=S) ->
    case {r,#{key:=Val},X} of
      {r,_,_} ->
        setelement(3, Val, S)
    end.

After that substitution the 'case' can be simplified to:

  f({r,#{key:=Val},_}=S) ->
    case #{key:=Val} of
      NewVar ->
       setelement(3, Val, S)
    end.

That is the result from case_opt/3. Now eval_case/2 notices
that since there is only one clause left in the 'case', the
'case' can eliminated:

  f({r,#{key:=Val},_}=S) ->
    NewVar = #{key:=Val},
    setelement(3, Val, S).

Since the map construction may have a side effect, it was not
eliminated, but assigned to a variable that is never used.

The problem is that '#{key:=Val}' is fine as a pattern, but in a
construction of a new map, the '=>' operator must be used. So the
map construction will fail, generating an exception.

As a conservative correction for a maintenance release, we will
abort the 'case' optimization if the substitution into the 'case'
expression is anything but data items (tuples, conses, or
literals) or variables.

Reported-by: Dmitry Aleksandrov