incorrect handling of covariant tuple fieldtypes causes crash

[jrevels]

This MWE triggers a crash (written by @vtjnash):

x = 1.0
@noinline bar1(tt::Tuple{T,T}, ::Type{Val{T}}) where {T} = notsame(tt)
@noinline notsame(tt::Tuple{T, T}) where {T} = error()
@noinline notsame(tt::Tuple{T, S}) where {T, S} = "OK"
foo1() = bar1((x, 1.0), Val{_Any})
_Any = Any
foo1()
x = 1
foo1()

This prints:

Unreachable reached at 0x10d5a6de4

signal (4): Illegal instruction: 4
in expression starting at no file:0
foo1 at ./REPL[5]:1
do_call at /Users/jarrettrevels/data/repos/julia7/src/interpreter.c:324
eval_body at /Users/jarrettrevels/data/repos/julia7/src/interpreter.c:559
jl_interpret_toplevel_thunk_callback at /Users/jarrettrevels/data/repos/julia7/src/interpreter.c:798
unknown function (ip: 0xfffffffffffffffe)
unknown function (ip: 0x109b42caf)
unknown function (ip: 0xffffffffffffffff)
jl_interpret_toplevel_thunk at /Users/jarrettrevels/data/repos/julia7/src/interpreter.c:807
jl_toplevel_eval_flex at /Users/jarrettrevels/data/repos/julia7/src/toplevel.c:856
jl_toplevel_eval_in at /Users/jarrettrevels/data/repos/julia7/src/builtins.c:624
eval at ./boot.jl:317 [inlined]
eval at /Users/jarrettrevels/data/repos/julia7/usr/share/julia/stdlib/v0.7/REPL/src/REPL.jl:5
eval_user_input at /Users/jarrettrevels/data/repos/julia7/usr/share/julia/stdlib/v0.7/REPL/src/REPL.jl:85
macro expansion at /Users/jarrettrevels/data/repos/julia7/usr/share/julia/stdlib/v0.7/REPL/src/REPL.jl:116 [inlined]
#28 at ./event.jl:92
jl_fptr_trampoline at /Users/jarrettrevels/data/repos/julia7/src/gf.c:1838
jl_apply at /Users/jarrettrevels/data/repos/julia7/src/./julia.h:1540 [inlined]
start_task at /Users/jarrettrevels/data/repos/julia7/src/task.c:268
Allocations: 2757027 (Pool: 2755329; Big: 1698); GC: 6
[1]    23580 illegal hardware instruction  julia7

So this is perhaps another example where #24614 could make life easier for inference

julia> versioninfo()
Julia Version 0.7.0-DEV.5036
Commit 9de318a (2018-05-07 18:03 UTC)
Platform Info:
  OS: macOS (x86_64-apple-darwin16.7.0)
  CPU: Intel(R) Core(TM) i5-4288U CPU @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, haswell)
Environment:

[JeffBezanson]

methods and _methods_by_ftype seem to know that both methods are applicable here.

[vtjnash]

Yes, this is demonstrating a bug in ‘fieldtype’ (and various versions of it, such as Core.Compiler.compute_arg_types and tuple_type_head) not respecting the potential effect of the diagonal rule when rewrapping the unionall type.