new subtyping issues

[vtjnash]

these are issues found with subtyping after #18457, and other related punchlist items.

• ambiguity / lack of definition of type-intersection environment (issue Segfault when reinterpreting in a for loop #20847), also needs documentation
• fix subtype in typetree (currently switched to @test_broken) grabbag of subtyping punchlist items #20407
• fix sizeof(Task) grabbag of subtyping punchlist items #20407
• test having TypeMap intersection visitor use (tparam ? jl_isa(t, ty) : jl_subtype(t, ty)) grabbag of subtyping punchlist items #20407
• fix compile-all mode fix compile=all, move code related to static compilation to precompile.c #20820
• improvements to printing TypeVar bounds in show grabbag of subtyping punchlist items #20407
• writing a new equivalent-type-replacement check
• correct ambiguity detection test: typeintersect(ml->sig, types) <: ml->sig grabbag of subtyping punchlist items #20407
• improve check_ambiguous_visitor grabbag of subtyping punchlist items #20407
• insert the right simpletype in the TypeMap so that ::Kind queries get cached correctly
• consider noting in doc/src/manual/types.md that "Float does not exist as a typealias for Float64, since the size of the floating point number is problem dependent, not platform dependent" grabbag of subtyping punchlist items #20407
• define >: function (issupertype) grabbag of subtyping punchlist items #20407
• work through newly detected ambiguities list (c.f. type system revision and new subtype algorithm #18457 (comment) from Jan 4)
• correct printing of where appearing in a Type in a method error
  julia> convert(Type{T} where T<:Int, 1)
  ERROR: MethodError: Cannot convert an object of type Int64 to an object of type Type{T} where T<:Int64
  This may have arisen from a call to the constructor Type{T} where T<:Int64(...),
  since type constructors fall back to convert methods.
• remove deprecation of remaining v0.5 items (since a couple random ones got removed in this PR)
• remove UNION_SPLIT_MISMATCH_ERROR from inference
• fix precise_container_types (it calls unwrap, but not re-wrap)
• consider more aggressive normalization of Tuple{Vararg}, or making Vararg not a type
• fix WeakKeyDict constructor type system revision and new subtype algorithm #18457 (comment) (done in fixes for WeakKeyDict, and some other error checks #20092)
• add list of keywords to Punctuation.md documentation
• add test case for Inconsistent restriction when subtyping using typealias #19414 (Add a test throws an error by invalid subtyping in definition (#19414) #20548)
• add test case for Arbitrary call priority when two methods differ only by presence of type parameter #19413
• add test case for Dispatch on Pair #19159
• add test case for Error in typeassert for type parameters #19041
• add test case for bug in dispatch #18985
• add test case for Parameterized methods can shadow other method without error/warning #18892
• add test case for methods returns wrong result for triangular dispatch #18348 (done in Misc tests for issues fixed by jb/subtype #20097)
• add test case for Expression Int{} should be an error #17943
• add test case for Regression in typealias with Union{} #16922
• add test case for Subtyping bug for complicated type alias #13165 (done in Misc tests for issues fixed by jb/subtype #20097)
• add test case for undetected method ambiguity #12814
• add test case for Dispatch issue with parametric methods where subtype constraint is a Type #12721 (done in Misc tests for issues fixed by jb/subtype #20097)
• add test case for Dispatch broken for containers of objects parametrized with TypeVars #12596
• add test case for Method sorting bug #12580 (done in Misc tests for issues fixed by jb/subtype #20097)
• add test case for missing method-ambiguity warning #11407 (assorted subtyping tests #20627)
• add test case for incorrect method sorting with union in typevar bound #8915 (assorted subtyping tests #20627)
• add test case for parametrized typealias inconsistently creates subtype relation #8625 (assorted subtyping tests #20627)
• add test case for typealias bug ?  #6721
• add test case for typealias bug? #2552 (assorted subtyping tests #20627)
• add test case for 0.5: Illegal instruction 4 #17003
• add test case for missing sub2ind ambiguity detection confuses inference #18307
• fix test_broken case added in Disambiguate sub2ind #18352

---

• intersection failure

julia> A = Tuple{Type{Tuple{Vararg{E, N} where N}}} where E
Tuple{Type{Tuple{Vararg{E,N} where N}}} where E

julia> B = Tuple{Type{Tuple{Vararg{E, N}}}} where N where E
Tuple{Type{Tuple{Vararg{E,N}}}} where N where E

julia> typeintersect(B, A)
Assertion failed: ((jl_value_t*)btemp->var != btemp->ub), function finish_unionall, file /Users/jameson/julia/src/subtype.c, line 1159.

#18457 (comment)

---

• tuple length subtyping inside invariant parameter:

julia> (Ref{Tuple{Int, Vararg{Int, N}}} where N) <: (Ref{Tuple{Vararg{Int, N}}} where N)
false

---

• another intersection failure:

typeintersect(Tuple{Int, Ref{Pair{K,V}}} where V where K,
              Tuple{Any, Ref{Pair{T,T}} where T })

This overflows the union state stack.

---

• subtype environment sub-optimality preventing a dispatch match, and subtyping error

julia> A = Ref{Tuple{T}} where T;
julia> B = Ref{Tuple{VecElement{S}} where S};
julia> ccall(:jl_match_method, Any, (Any, Any), B, A)
svec(Ref{Tuple{VecElement{S}} where S}, svec(T <: (VecElement{S} where S)))

julia> A = Tuple{Ref{Tuple{T}}, Ref{T}} where T;
julia> B = Tuple{Ref{Tuple{VecElement{S}} where S}, Ref{VecElement{Int}}}
julia> B <: A
true # should be false

a possibly related case is:

julia> A = Ref{Tuple{T, T}} where T;
julia> B = Ref{Tuple{S, Any} where S};
julia> B <: A
true # should be false
# a similar case, but that isn't wrong:
julia> A = Pair{Tuple{T, T}, T} where T;
julia> B = Pair{Tuple{S, Any} where S, Any};
julia> B <: A
true # correct

---

• Specificity issue in ColorTypes:

julia> (g(::Type{TC}) where TC <: (TransparentColor{C, T, N} where T where N) where C) = C
g (generic function with 1 method)

julia> g(ColorTypes.TransparentColor{ColorTypes.RGB{Float32}, Float32, 4})
ColorTypes.RGB{Float32}

julia> (g(::Type{TC}) where TC <: TransparentColor) = 1
g (generic function with 2 methods)

julia> g(ColorTypes.TransparentColor{ColorTypes.RGB{Float32}, Float32, 4})
1

julia> methods(g)
# 2 methods for generic function "g":
g{TC<:ColorTypes.TransparentColor}(::Type{TC}) in Main at REPL[16]:1
g{C,TC<:(ColorTypes.TransparentColor{C,T,N} where T where N)}(::Type{TC}) in Main at REPL[14]:1

---

• broken leaftype normalization (relative to codegen / inference assumptions for performance optimization)
  Vector{T} where Int <: T <: Int should return Vector{Int}
  so that isleaftype(T) guarantees isa(T, DataType) and pointer-egal

---

• related to that normalization failure, it doesn't notice that T <: Int describes a Union with exactly two elements:

julia> (Ref{T} where T <: Int) <: Union{Ref{Union{}}, Ref{Int}}
false

---

• Possibly wrong TypeVar serialization with new typesystem Possibly wrong TypeVar serialization with new typesystem #20324

---

• error thrown when trying to fill in sparam bounds with a non-type:

julia> ccall(:jl_match_method, Any, (Any, Any), Tuple{0}, Tuple{T} where T)
ERROR: TypeError: TypeVar: in upper bound, expected Type, got Int64
Stacktrace:
 [1] anonymous at <missing>:0
 [2] eval(::Module, ::Any) at ./boot.jl:236
 [3] eval_user_input(::Any, ::Base.REPL.REPLBackend) at REPL.jl:66
 [4] macro expansion; at REPL.jl:97 [inlined]
 [5] (::Base.REPL.##1#2{Base.REPL.REPLBackend})() at event.jl:73

---

• inconsistent handling of tuple leaftype covariance normalization

julia> (Tuple{S, Int} where S <: Int) <: Tuple{T, T} where T <: Real
false

---

• Specificity: Tuple{Type{Nullable{T}}, Void} where T should be more specific than Tuple{Type{Nullable{T}}, T} where T.

---

type-intersection fails to sufficiently consider that a typevar may match a non-type: issue #20869

[StefanKarpinski]

Is this a list of 0.6-blocking issues?

[vtjnash]

no, it's a summary of bugs that won't be fixed by #18457

[StefanKarpinski]

That doesn't really answer my question.

[JeffBezanson]

It's a list of things he found while reviewing #18457 that don't block merging it. These are generally minor bugs or follow-on work items that don't block 0.6.

[tkelman]

We really shouldn't leave the ambiguity test turned off for very long though. That's the most urgent of these to fix.

[vtjnash]

whoever added "add test cases for all closed issues", can you list the issues that still need test-cases so we can cross them off as we go?

@tkelman there's no ordering in the above list, just a task list to keep track of everything

[tkelman]

Jeff is the one closing them, I've been grepping the test folder for references to each of them but haven't found any hits. (except 18450 and 11840)

edit: any of these cases that are covered by existing tests, should at least cross-reference the relevant issue in a comment / testset description