* hl/beam_disasm-no_attri_chunk:
  beam_disasm: Handle stripped BEAM files

OTP-9571

beam_disasm:file/1 would crash if asked to disassemble a stripped
BEAM file without an "Attr" chunk.

Since the introduction of improved record optimizations in
1858cb81391d2bce29b4b7620574ca60128cebf7 and
470c91d43eae54f63661645acbce4b92d73287cc, the optimization of
a is_record/3 call with a known correct type in
beam_type:simplify_basic_1/3 has not been covered.

In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform
with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE
was changed to the actual name of the module. That would cause
test_lib:recompile/1 to compile the module with the incorrect
compiler options in cloned modules such as record_no_opt_SUITE,
causing worse coverage.

* hw/call-chmod-without-f:
  Call chmod without the "-f" flag

Conflicts:
	erts/emulator/test/Makefile
	lib/asn1/test/Makefile
	lib/crypto/test/Makefile
	lib/debugger/test/Makefile
	lib/docbuilder/test/Makefile
	lib/edoc/test/Makefile
	lib/erl_interface/test/Makefile
	lib/inviso/test/Makefile
	lib/parsetools/test/Makefile
	lib/percept/test/Makefile
	lib/ssl/test/Makefile
	lib/syntax_tools/test/Makefile
	lib/test_server/test/Makefile
	lib/tools/test/Makefile

OTP-9170

The compiler (sys_core_fold) tries to avoid constructing tuples
in case expressions. The following code:

c(A, B) ->
     case {A,B} of
         {ok,X} -> X;
         {_,_} -> error
     end.

will be rewritten so that no tuple is built. If a clause
requires a tuple to be built as in this code:

c(A, B) ->
     case {A,B} of
         {ok,X} -> X;
         V -> V    %The tuple will be built here
     end.

the tuple will be built in the clause(s) in which it is needed.

If the value returned from the case is not used as in this code:

c(A, B) ->
    case {A,B} of
	V -> V     %Warning: a term is constructed, but never used
    end,
    ok.

there will be an incorrect warning. Basically, what happens is
that the code is reduced to:

c(A, B) ->
    {A,B},         %Warning: a term is constructed, but never used
    ok.

and the optimizer sees that the {A,B} tuple can't possibly be used.

Eliminate the warning by adding a 'compiler_generated' annotation
to the tuple.

Reported-by: Kostis Sagonas

In the following code:

m(<<Sz:8,_:Sz/binary>>) ->
    Sz = wrong.

the Sz variable is supposed to be bound in the function header and the
matching "Sz = wrong" should cause a badarg exception.  But what
happens is that the Sz variables seems to be unbound and the matching
succeds and the m/1 function returns 'wrong'.

If the Sz variable is used directly (not matched), it will have
the expected value. Thus the following code:

m(<<Sz:8,_:Sz/binary>>) ->
    Sz.

will correctly return the value of Sz that was matched out from
the binary.

Reported-by: Bernard Duggan