Julia: Mega-issue for packages failing PkgEval for 1.1 release

[KristofferC]

This contains a small analysis of all packages that fail PkgEval.
Gist with the results of packages failing on 1.1 vs 1.0: https://gist.github.com/ararslan/533cf231d32d87a6f80bf47d38de3182

Feel free to look at any of the packages without a cross and investigate why they fail and update this post (or post a reply).
Also, feel free to open dedicated issues for specific packages to discuss a certain bug / breaking change.

Failing packages

Packages that fail but are deemed to do so for acceptable reasons are checked.

• [x] Zygote
• [x] WignerSymbols
• [x] VT100
• [x] SymbolServer
• [x] SVR (fixed by https://github.com/JuliaLang/julia/issues/30374#issuecomment-447079464?)
• [ ] StaticNumbers
• [x] SplitApplyCombine
• [x] SPH
• [x] ResumableFunctions https://github.com/JuliaLang/julia/issues/30374#issuecomment-447087799
• [x] QDates (explanation: https://github.com/JuliaLang/julia/issues/30374#issuecomment-447072581)
• [ ] OffsetArrays (likely fixed by https://github.com/JuliaArrays/OffsetArrays.jl/pull/62)
• [x] Nullables (should be fixed by #30350)
• [x] MultivariatePolynomials (fixed by https://github.com/JuliaLang/julia/pull/30360)
• [ ] MathematicalSystems (maybe fixed https://github.com/JuliaLang/julia/issues/30374#issuecomment-447080821)
• [x] Libtask
• [x] LegacyStrings (also fixed by https://github.com/JuliaStrings/LegacyStrings.jl/pull/36)
• [x] JSONWebTokens
• [x] IterableTables
• [x] Distances
• [x] DecFP: (explanation: https://github.com/JuliaLang/julia/issues/30374#issuecomment-446788652)
• [x] CSTParser
• [x] BlockArrays
• [x] BandedMatrices
• [ ] AxisArrays (likely fixed by JuliaArrays/OffsetArrays.jl#62)
• [ ] AstroLib (PR with fix at JuliaArrays/StaticArrays.jl#568)
• [ ] Arrow (passes locally https://github.com/JuliaLang/julia/issues/30374#issuecomment-447087799)
• [ ] AbstractOperators (explanation: https://github.com/JuliaLang/julia/issues/30374#issuecomment-446789522)

Analysis:

Zygote

LoadError: type StmtRange has no field first.

Uses a lot of internal features. Can likely ignore.

WignerSymbols

Testing WignerSymbols tests passed

wut?

VT100

ERROR: LoadError: LoadError: MethodError: no method matching Base.TTY(::RawFD; readable=true)

Base.TTY is internal and undocumented. Can likely ignore.

SymbolServer

LoadError: MethodError: no method matching getindex(::Pkg.Types.Project, ::String)

Uses Pkg internals that have been refactored. Should help with fixing SymbolServer to work on 1.1 but no need
for change in code,

SVR

signal (11): Segmentation fault
in expression starting at /root/.julia/packages/SVR/OpJky/test/runtests.jl:8
_ZN6KernelD0Ev at /root/.julia/packages/SVR/OpJky/src/../deps/libsvm-3.22/libsvm.so.2 (unknown line)
Allocations: 4829533 (Pool: 4828507; Big: 1026); GC: 10
ERROR: Package SVR errored during testing

Should investigate

StaticNumbers

Error During Test at /root/.julia/packages/StaticNumbers/BglY7/test/runtests.jl:104
  Test threw exception
  Expression: trystatic(2, 1:3) == static(2)
  MethodError: convert(::Type{StaticInteger{0}}, ::StaticInteger{0}) is ambiguous. Candidates:
    convert(::Type{T}, ::Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}}) where {T<:Number, X} in StaticNumbers at /root/.julia/packages/StaticNumbers/BglY7/src/StaticNumbers.jl:108
    convert(T::Type{#s14} where #s14<:Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}}, y::Number) where X in StaticNumbers at /root/.julia/packages/StaticNumbers/BglY7/src/StaticNumbers.jl:104
  Possible fix, define
    convert(::Union{Type{T<:(Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}} where X)}, Type{T<:(Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}} where X)}, Type{T<:(Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}} where X)}}, ::Union{StaticInteger{X}, StaticNumber{X}, StaticReal{X}})
  Stacktrace:
   [1] LengthUnitRange{Int64,StaticInteger{0},StaticInteger{3}}(::StaticInteger{0}, ::StaticInteger{3}) at /root/.julia/packages/StaticNumbers/BglY7/src/LengthRanges.jl:53
   [2] LengthUnitRange(::StaticInteger{0}, ::StaticInteger{3}) at /root/.julia/packages/StaticNumbers/BglY7/src/LengthRanges.jl:59
   [3] trystatic(::Int64, ::UnitRange{Int64}) at /root/.julia/packages/StaticNumbers/BglY7/src/trystatic.jl:53

SplitApplyCombine

 Unexpected Pass
 Expression: isequal(#= /root/.julia/packages/SplitApplyCombine/nrESG/test/product.jl:5 =# @inferred(product(*, [1.0, 2.0], [1, 2, missing]))::Matrix{Union{Missing, Float64}}, [1.0 2.0 missing; 2.0 4.0 missing])
 Got correct result, please change to @test if no longer broken.

Maybe we just fixed something?

SPH

ERROR: Unsatisfiable requirements detected for package SPH [9ea8cd13]:
 SPH [9ea8cd13] log:
 ├─possible versions are: [0.0.1, 0.2.1-0.2.2, 1.0.0] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.0.1, 0.2.1-0.2.2, 1.0.0]
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left
Stacktrace:

Package is upper bounded, seems like this is working as intended

ResumableFunctions

test_for: Error During Test at /root/.julia/packages/ResumableFunctions/YK92O/test/runtests.jl:12
  Test threw exception
  Expression: collect(test_for(4)) == [4, 5, 9, 14, 23, 37, 60, 97, 157, 254]
  MethodError: Cannot `convert` an object of type Nothing to an object of type Tuple{Int64,Int64}
  Closest candidates are:
    convert(::Type{T<:Tuple{Any,Vararg{Any,N} where N}}, !Matched::T<:Tuple{Any,Vararg{Any,N} where N}) where T<:Tuple{Any,Vararg{Any,N} where N} at essentials.jl:274
    convert(::Type{T<:Tuple{Any,Vararg{Any,N} where N}}, !Matched::Tuple{Any,Vararg{Any,N} where N}) where T<:Tuple{Any,Vararg{Any,N} where N} at essentials.jl:275
    convert(::Type{T<:Tuple}, !Matched::CartesianIndex) where T<:Tuple at multidimensional.jl:130
    ...
  Stacktrace:
   [1] setproperty!(::getfield(Main, Symbol("##364")), ::Symbol, ::Nothing) at ./sysimg.jl:19
   [2] (::getfield(Main, Symbol("##364")))(::Nothing) at /root/.julia/packages/ResumableFunctions/YK92O/src/transforms.jl:16
   [3] iterate at /root/.julia/packages/MacroTools/4AjBS/src/utils.jl:84 [inlined]
   [4] _collect(::UnitRange{Int64}, ::getfield(Main, Symbol("##364")), ::Base.HasEltype, ::Base.SizeUnknown) at ./array.jl:553
   [5] collect(::getfield(Main, Symbol("##364"))) at ./array.jl:541

should investigate,

QDates

ERROR: LoadError: LoadError: There was an error during testing
in expression starting at /root/.julia/packages/QDates/qPuFu/test/ranges.jl:3
in expression starting at /root/.julia/packages/QDates/qPuFu/test/runtests.jl:12
start testing: ranges.jl
Test Failed at /root/.julia/packages/QDates/qPuFu/test/ranges.jl:51
  Expression: iterate(dr) == (first(dr), 1)
   Evaluated: (旧2014年01月01日, (1, 1)) == (旧2014年01月01日, 1)

Seems like some state from an iterator has changed. Should investigate.

OffsetArrays

Error During Test at /root/.julia/packages/OffsetArrays/NIuVg/test/runtests.jl:81
  Test threw exception
  Expression: A[:, 3] == S[:, 3] == OffsetArray([1, 2], (A.offsets[1],))
  MethodError: no method matching similar(::OffsetArray{Int64,2,Array{Int64,2}}, ::Type{Int64}, ::Tuple{Base.IdentityUnitRange{UnitRange{Int64}}})
  Closest candidates are:
    similar(::OffsetArray, ::Type{T}, !Matched::Tuple{Vararg{Int64,N}} where N) where T at /root/.julia/packages/OffsetArrays/NIuVg/src/OffsetArrays.jl:85
    similar(::AbstractArray, ::Type{T}) where T at abstractarray.jl:572
    similar(::AbstractArray, ::Type{T}, !Matched::Union{Integer, AbstractUnitRange}...) where T at abstractarray.jl:575
    ...
  Stacktrace:
   [1] similar(::OffsetArray{Int64,2,Array{Int64,2}}, ::Tuple{Base.IdentityUnitRange{UnitRange{Int64}}}) at ./abstractarray.jl:573
   [2] _unsafe_getindex(::IndexLinear, ::OffsetArray{Int64,2,Array{Int64,2}}, ::Base.Slice{UnitRange{Int64}}, ::Int64) at ./multidimensional.jl:654
   [3] _getindex at ./multidimensional.jl:642 [inlined]

Nullables

signal (11): Segmentation fault
in expression starting at /root/.julia/packages/Nullables/Oyo3b/test/runtests.jl:342
jl_intrinsic_cvt at /buildworker/worker/package_linux64/build/src/runtime_intrinsics.c:392
toInt8 at ./boot.jl:627 [inlined]
Type at ./boot.jl:730 [inlined]

Fixed by https://github.com/JuliaLang/julia/pull/30350

MultivariatePolynomials

Unreachable reached at 0x7f51518adc2a

signal (4): Illegal instruction
in expression starting at /root/.julia/packages/MultivariatePolynomials/N5uDO/test/zip.jl:3
Type at ./pair.jl:12 [inlined]
Type at ./pair.jl:15

Fixed by https://github.com/JuliaLang/julia/pull/30360??

MathematicalSystems

Polynomial system in continuous time: Error During Test at /root/.julia/packages/MathematicalSystems/coRVN/test/continuous.jl:121
  Got exception outside of a @test
  TypeError: in typeassert, expected Variable{:y}, got Variable{:y}
  Stacktrace:
   [1] setindex!(::Array{Variable{:y},1}, ::Variable{:y}, ::Int64) at ./array.jl:764
   [2] getindex(::Tuple{Variable{:y}}, ::UnitRange{Int64}) at ./range.jl:293
   [3] merge(::Tuple{Variable{:y}}, ::Variable{:x}) at /root/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:46

Looks weird. Should investigate.

Libtask

ERROR: LoadError: LoadError: type Task has no field parent
Stacktrace:
 [1] getproperty(::Any, ::Symbol) at ./sysimg.jl:18
 [2] copy(::Task) at /root/.julia/packages/Libtask/L5wq8/src/taskcopy.jl:28
 [3] top-level scope at none:0

Using internal structure of Task

LegacyStrings

in expression starting at /root/.julia/packages/LegacyStrings/tkVHE/test/runtests.jl:210
Error During Test at /root/.julia/packages/LegacyStrings/tkVHE/test/runtests.jl:211
  Test threw exception
  Expression: next(str, 15) == ('�', 16)
  UndefVarError: next not defined

Should investigate

JSONWebTokens

ERROR: Unsatisfiable requirements detected for package JSONWebTokens [9b8beb19]:
 JSONWebTokens [9b8beb19] log:
 ├─possible versions are: [0.0.2, 0.1.0] or uninstalled
 ├─restricted to versions * by an explicit requirement, leaving only versions [0.0.2, 0.1.0]
 └─restricted by julia compatibility requirements to versions: uninstalled — no versions left

Package is upper bounded, ok.

IterableTables

Testing IterableTables tests passed

Hmm.

Distances

zero allocation colwise!: Error During Test at /root/.julia/packages/Distances/nLAdT/test/test_dists.jl:548
 Unexpected Pass
 Expression: #= /root/.julia/packages/Distances/nLAdT/test/test_dists.jl:548 =# @allocated(colwise!(z, d, a, b)) == 0
 Got correct result, please change to @test if no longer broken.

Improvement, can ignore.

DecFP

Test Failed at /root/.julia/packages/DecFP/Mxubh/test/runtests.jl:74
  Expression: #= /root/.julia/packages/DecFP/Mxubh/test/runtests.jl:74 =# @sprintf("%7.2f", T("1.2345")) == "   1.23"
   Evaluated: "   @.0\x8f" == "   1.23"

Should investigate.

CSTParser

  Expression: Meta.parse("1,") == Expr(:tuple, 1)
   Evaluated: $(Expr(:incomplete, "incomplete: premature end of input")) == (1,)

Is quite closely tied to the internals of julia.

BlockArrays

lmul!/rmul!: Test Failed at /root/.julia/packages/BlockArrays/DOXjA/test/test_blockarrays.jl:320
  Expression: Array(A) == zeros(6)
   Evaluated: [NaN, NaN, NaN, NaN, NaN, NaN] == [0.0, 0.0, 0.0, 0.0, 0.0, 0.0]

Changed 0 * NaN = NaN in BLAS1. Desired change even though breaking.

BandedMatrices

lmul!/rmul!: Test Failed at /root/.julia/packages/BandedMatrices/kvwBE/test/test_broadcasting.jl:144
  Expression: norm(A) == 0.0
   Evaluated: NaN == 0.0

Same as package above.

AxisArrays

Indexing: Error During Test at /root/.julia/packages/AxisArrays/G6pZY/test/indexing.jl:252
  Test threw exception
  Expression: #= /root/.julia/packages/AxisArrays/G6pZY/test/indexing.jl:252 =# @inferred(A[:, atvalue(2.0)]) == OffsetArrays.OffsetArray([1, 3], 0:1)
  MethodError: no method matching similar(::OffsetArrays.OffsetArray{Int64,2,Array{Int64,2}}, ::Type{Int64}, ::Tuple{Base.IdentityUnitRange{UnitRange{Int64}}})
  Closest candidates are:
    similar(::OffsetArrays.OffsetArray, ::Type{T}, !Matched::Tuple{Vararg{Int64,N}} where N) where T at /root/.julia/packages/OffsetArrays/NIuVg/src/OffsetArrays.jl:85
    similar(::AbstractArray, ::Type{T}) where T at abstractarray.jl:572
    similar(::AbstractArray, ::Type{T}, !Matched::Union{Integer, AbstractUnitRange}...) where T at abstractarray.jl:575
    ...

AstroLib

  MethodError: no method matching similar(::SubArray{Float64,1,StaticArrays.SArray{Tuple{3},Float64,1,3},Tuple{UnitRange{Int64}},true}, ::Type{Float64}, ::Tuple{Base.IdentityUnitRange{StaticArrays.SOneTo{4}}})
  Closest candidates are:
    similar(::SubArray, ::Type, !Matched::Tuple{Vararg{Int64,N}} where N) at subarray.jl:67
    similar(::AbstractArray, ::Type{T}) where T at abstractarray.jl:572
    similar(::AbstractArray, ::Type{T}, !Matched::Union{Integer, AbstractUnitRange}...) where T at abstractarray.jl:575
    ...

Arrow

arrowformat_construct: Test Failed at /root/.julia/packages/Arrow/b4oSO/test/runtests.jl:129
  Expression: typeof(p) == BitPrimitive
   Evaluated: NullableBitPrimitive == BitPrimitive

Should investigate

AbstractOperators

  LoadError: syntax: invalid syntax (incomplete #<julia: "incomplete: premature end of input">)
  Stacktrace:
   [1] mul!(::Array{Float64,2}, ::NonLinearCompose{2,HCAT{1,3,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},NonLinearCompose{2,HCAT{1,2,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},MatrixOp{Float64,Float64,Array{Float64,2}}},Tuple{Int64,Int64},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}},Tuple{Int64,Tuple{Int64,Int64}},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}, ::Tuple{Array{Float64,2},Array{Float64,2},Array{Float64,2}}) at /root/.julia/packages/AbstractOperators/7oLxM/src/calculus/NonLinearCompose.jl:90
   [2] *(::NonLinearCompose{2,HCAT{1,3,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},NonLinearCompose{2,HCAT{1,2,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},MatrixOp{Float64,Float64,Array{Float64,2}}},Tuple{Int64,Int64},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}},Tuple{Int64,Tuple{Int64,Int64}},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}, ::Tuple{Array{Float64,2},Array{Float64,2},Array{Float64,2}}) at /root/.julia/packages/AbstractOperators/7oLxM/src/syntax.jl:16
   [3] test_NLop(::NonLinearCompose{2,HCAT{1,3,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},NonLinearCompose{2,HCAT{1,2,Tuple{MatrixOp{Float64,Float64,Array{Float64,2}},Zeros{Float64,2,Float64,2}},Tuple{Int64,Int64},Array{Float64,2}},HCAT{1,2,Tuple{Zeros{Float64,2,Float64,2},MatrixOp{Float64,Float64,Array{Float64,2}}},Tuple{Int64,Int64},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}},Tuple{Int64,Tuple{Int64,Int64}},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}},Tuple{Array{Float64,2},Array{Float64,2}}}, ::Tuple{Array{Float64,2},Array{Float64,2},Array{Float64,2}}, ::Array{Float64,2}, ::Bool) at /root/.julia/packages/AbstractOperators/7oLxM/test/utils.jl:35
   [4] top-level scope at none:0

Some parser change?

[fredrikekre]

OffsetArrays fixed by https://github.com/JuliaArrays/OffsetArrays.jl/pull/62, and proably AxisArrays too

[JeffBezanson]

DecFP hooks into Printf internals. It will need to be updated after #30373 is merged. Currently it's assuming digits are left in DIGITS, which is no longer true, so it's getting junk.

[fredrikekre]

28941 seems to have caused the failure of OffsetArrays, AxisArrays and AstroLib. OffsetArrays and AxisArrays are probably fixed by https://github.com/JuliaArrays/OffsetArrays.jl/pull/62 but maybe you can comment on AstroLib@mbauman?

[ararslan]

As a sanity check I reran WignerSymbols and IterableTables, which both reported failure after passing tests, and both now report success.

[JeffBezanson]

AbstractOperators has generated functions that call parse (not recommended) on inputs ending with commas, which are now considered incomplete expressions.

[ararslan]

LegacyStrings was fixed by https://github.com/JuliaStrings/LegacyStrings.jl/pull/36, which is in v0.4.1, but PkgEval ran on v0.4.0. So we're good there. (Not sure how it passed on 1.0, but hey...)

[tlienart]

For ResumableFunctions, a bit of investigation based on their runtests.jl

@resumable function test_for(a::Int=0; b::Int=a+1) :: Int
  for i in 1:10
    @yield a
    a, b = b, a+b
  end
end
collect(test_for(4)) # fails

however if you do this

@resumable function test_for(a::Int=0; b::Int=a+1, n::Int=10) :: Int
  for i in 1:n
    @yield a
    a, b = b, a+b
  end
end
collect(test_for(4)) # works

(note: both work on 1.0.x, first one fails on 1.1)

Edit: the problem is in the transform_for function in src/transforms.jl with this line

$next = iterate($iterator_value, $state)

where it looks like iterate($iterator_value, $state) becomes nothing at the end and it should break there instead of trying to feed that to $next (which expects a tuple of Int). Not too sure why the assignment causes an issue here in one case but not the other but I figure someone more Julia savvy will know.

Edit2: the following fixes the problem (though I'm not certain why so it should probably be looked at)

function transform_for(expr, ui8::BoxedUInt8)
  @capture(expr, for element_ in iterator_ body__ end) || return expr
  ui8.n += one(UInt8)
  next = Symbol("_iteratornext_", ui8.n)
  state = Symbol("_iterstate_", ui8.n)
  iterator_value = Symbol("_iterator_", ui8.n)
  quote
    $iterator_value = $iterator
    $next = iterate($iterator_value)
    while $next != nothing
      ($element, $state) = $next
      $(body...)
      tmp = iterate($iterator_value, $state) # <---
      tmp === nothing && break               # <---
      $next = tmp                            # <---
    end
  end
end

Edit3 there's another (different) problem with the function test_try (in runtests.jl) ... syntax: Attempt to jump into catch block, that's beyond my julia.

FWIW I've opened an issue for both over there. (https://github.com/BenLauwens/ResumableFunctions.jl/issues/30)

[tlienart]

Just a note that for QDates, it's also an issue with iterate. Did anything noteworthy change there?

[saschatimme]

MultivariatePolynomials got fixed by #30360.

[mforets]

MathematicalSystems: the error is in the creation of a polynomial from TypedPolynomials. Does this work?

using TypedPolynomials
@polyvar x y
p = 2x^2 - 3x + y

[StefanKarpinski]

Just a note that for QDates, it's also an issue with iterate. Did anything noteworthy change there?

@keno: any idea about this? I don't recall anything changing here, I wonder if it's a lowering change...

[StefanKarpinski]

Does this work?

using TypedPolynomials
@polyvar x y
p = 2x^2 - 3x + y

No, it doesn't:

julia> using TypedPolynomials
[ Info: Precompiling TypedPolynomials [afbbf031-7a57-5f58-a1b9-b774a0fad08d]

julia> @polyvar x y
(x, y)

julia> p = 2x^2 - 3x + y
ERROR: TypeError: in typeassert, expected Variable{:y}, got Variable{:y}
Stacktrace:
 [1] setindex!(::Array{Variable{:y},1}, ::Variable{:y}, ::Int64) at ./array.jl:766
 [2] getindex(::Tuple{Variable{:y}}, ::UnitRange{Int64}) at ./range.jl:293
 [3] merge(::Tuple{Variable{:y}}, ::Variable{:x}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:46
 [4] promote_rule(::Type{Monomial{(y,),1}}, ::Type{Monomial{(x,),1}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:57
 [5] promote_rule(::Type{Monomial{(x,),1}}, ::Type{Variable{:y}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:18
 [6] promote_rule(::Type{Variable{:y}}, ::Type{Monomial{(x,),1}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:20
 [7] promote_type at ./promotion.jl:221 [inlined]
 [8] promote_rule(::Type{Term{Int64,Monomial{(x,),1}}}, ::Type{Variable{:y}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:23
 [9] promote_rule(::Type{Variable{:y}}, ::Type{Term{Int64,Monomial{(x,),1}}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:25
 [10] promote_type at ./promotion.jl:221 [inlined]
 [11] promote_rule(::Type{Polynomial{Int64,Term{Int64,Monomial{(x,),1}},Array{Term{Int64,Monomial{(x,),1}},1}}}, ::Type{Variable{:y}}) at /Users/stefan/.julia/packages/TypedPolynomials/aFic2/src/promotion.jl:69
 [12] promote_type at ./promotion.jl:221 [inlined]
 [13] _promote at ./promotion.jl:260 [inlined]
 [14] promote at ./promotion.jl:284 [inlined]
 [15] +(::Polynomial{Int64,Term{Int64,Monomial{(x,),1}},Array{Term{Int64,Monomial{(x,),1}},1}}, ::Variable{:y}) at /Users/stefan/.julia/packages/MultivariatePolynomials/N5uDO/src/operators.jl:21
 [16] top-level scope at none:0

That is a rather perplexing error message. Is it possible that two different parametric types called Variable are getting created? Or is it possible that there's some new bug with parametric types with symbols as type parameters?

[KristofferC]

QDates are due to https://github.com/JuliaLang/julia/pull/29404 changing the type of the state for that iterator. I think the QDates test are just being too explicit in their tests (package seems to work fine, they are just testing the exact output of an iterate method). One should use the iterator interface to deal with iterators and not check the exact output for the state.

Issue opened: https://github.com/antimon2/QDates.jl/issues/4

[mbauman]

The AstroLib failure is actually a StaticArrays issue — and there's a fix underway there. https://github.com/JuliaArrays/StaticArrays.jl/pull/568

[KristofferC]

SVR.jl failed on my unupdated backport branch with:

ERROR: LoadError: LoadError: ZExt: output bitsize must be > input bitsize
Stacktrace:
 [1] link_pipe at ./boot.jl:682 [inlined]
 [2] link_pipe!(::Base.PipeEndpoint, ::Bool, ::Base.PipeEndpoint, ::Bool) at ./stream.jl:662
 [3] #link_pipe!#490 at ./stream.jl:634 [inlined]
 [4] link_pipe! at ./stream.jl:634 [inlined]
 [5] redirect_stdout at ./stream.jl:1001 [inlined]

but rebuilding and running the tests again they pass, so seems this was fixed (maybe https://github.com/JuliaLang/julia/pull/30350).

[KristofferC]

I can't repro the TypedPolynomials failure:

  | | |_| | | | (_| |  |  Version 1.1.0-DEV.864 (2018-12-12)
 _/ |\__'_|_|_|\__'_|  |  Commit f4d8ce1e73* (0 days old master)
|__/                   |

julia> using TypedPolynomials
[ Info: Precompiling TypedPolynomials [afbbf031-7a57-5f58-a1b9-b774a0fad08d]

julia> @polyvar x y
(x, y)

julia> p = 2x^2 - 3x + y
2x² - 3x + y

and

   Testing TypedPolynomials tests passed

and

   Testing MathematicalSystems tests passed

Maybe it got fixed by some new backported PR? Can someone else try?

[KristofferC]

The difference in ResumableFunction is obvious looking at https://www.diffchecker.com/rJ55k9Ac.

For some reason, the generated struct has the field:

        _iteratornext_1::Tuple{Int64,Int64} 

now while before it had

        _iteratornext_1::Union{Nothing, Tuple{Int64,Int64}}

causing the conversion error.

[KristofferC]

W.r.t ResumableFunction I think this is just a bug in the package and now fails because our inference got better. https://github.com/JuliaLang/julia/issues/30374#issuecomment-446826387 should fix the package.

The package contains code like

function my_code_typed(@nospecialize(f), @nospecialize(types=Tuple))
  types = Core.Compiler.to_tuple_type(types)
  asts = []
  world = ccall(:jl_get_world_counter, UInt, ())
  params = Core.Compiler.Params(world)
  for x in Core.Compiler._methods(f, types, -1, world)
      meth = Core.Compiler.func_for_method_checked(x[3], types)
      (code, slottypes) = my_typeinf_code(meth, x[1], x[2], params)
      code === nothing && error("inference not successful")
      push!(asts, code => slottypes)
  end
  return asts
end

which doesn't really follow our stability guarantees, so I don't think we have to do anything about this.

[KristofferC]

Arrow.jl passes locally.

[JeffBezanson]

A further problem exposed by StaticNumbers is that BigInt(::Integer) now depends on ndigits, which doesn't work on general integers due to this:

# TODO: allow b::Integer
function ndigits0zpb(x::Base.BitUnsigned, b::Int)

[JeffBezanson]

Anybody know what's going on here?

julia> r = LengthStepRange(1,2,static(3))
staticlength(3:2:7)

julia> typeof(ans)
LengthStepRange{Int64,Int64,Int64,StaticInteger{3}}

julia> r .== 3:2:7
ERROR: MethodError: no method matching similar(::Type{BitArray}, ::Tuple{UnitRange{Int64}})
Closest candidates are:
  similar(::AbstractArray{T,N} where N, ::Tuple) where T at abstractarray.jl:573
  similar(::Type{T<:AbstractArray}, ::Union{Integer, AbstractUnitRange}...) where T<:AbstractArray at abstractarray.jl:616
  similar(::Type{T<:AbstractArray}, ::Tuple{Vararg{Int64,N}} where N) where T<:AbstractArray at abstractarray.jl:618
  ...
Stacktrace:
 [1] similar(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1},Tuple{UnitRange{Int64}},typeof(==),Tuple{LengthStepRange{Int64,Int64,Int64,StaticInteger{3}},StepRange{Int64,Int64}}}, ::Type{Bool}) at ./broadcast.jl:198
 [2] copy at ./broadcast.jl:773 [inlined]
 [3] materialize(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{1},Nothing,typeof(==),Tuple{LengthStepRange{Int64,Int64,Int64,StaticInteger{3}},StepRange{Int64,Int64}}}) at ./broadcast.jl:753

Looks like axes(bc) is returning something with a UnitRange instead of a OneTo?

[mbauman]

That's the same issue as https://github.com/JuliaArrays/StaticArrays.jl/pull/568. The trouble is that both packages are defining their own OneTo type. We privilege our OneTo such that slicing and axes preserves its OneTo-ness, assuming other ranges will be offset. I expected OffsetArrays to need to update, but didn't consider the static use cases.

[JeffBezanson]

Got it. I don't think StaticNumbers needs its own OneTo type; it seems to me Base.OneTo{StaticInteger{N}} should work fine. I have a PR.

[StefanKarpinski]

I can't repro the TypedPolynomials failure:
[...]
Maybe it got fixed by some new backported PR? Can someone else try?

Still happens on the release-1.1 branch for me but not on master so something fixes it.

[JeffBezanson]

Oh dear, StaticNumbers are hard. The problem is that when x is a StaticNumber, x+x cannot even be converted to the type of x (StaticInteger{4} can't be represented as a StaticInteger{2}). That makes Base range functions generally not work. Should I add methods to axistype like

axistype(a::StaticOneTo, b::OneTo) = a

?

[perrutquist]

I'm amazed at how much of Julia just works with StaticNumbers, but I just wanted to say, in case something breaks I absolutely don't mind adding wrappers for functions that expect things like (typeof(x))(x+x) to work.

I'm also amazed at how much thought and effort has gone into making a package work that I'm not sure has any active users beside myself. Thank you so much!

For information: My plan for this package is precisely to add methods to the Base range functions and use StaticIntegers to compute things like the sizes of Arrays which would then automatically turn them into StaticArrays.

[Nosferican]

Seems like the linked issue/PR for OffsetArrays, AxisArrays, AstroLib have been merged/closed. Check status after the action and update the checklist?

[KristofferC]

Yes, we should rerun PkgEval on the backport branch now.

[ararslan]

Newest PkgEval results show the following failures in relation to 1.0.3:

• [x] CSTParser
• [ ] FlatBuffers
• [x] JSONWebTokens
• [x] Libtask
• [x] QDates
• [ ] Sched
• [x] SparseArrays (#30519)
• [x] SplitApplyCombine
• [x] SymbolServer
• [x] VT100

Note that packages for which any dependency fails tests are skipped, so the SparseArrays failure may be hiding others.

Logs: https://gist.github.com/ararslan/6d0649080c8f731b583c4699497ed802

[Nosferican]

There are no binaries for v"1.1", right? Is it worthwhile if I investigate using the nightly?

[ararslan]

Nightly is 1.2. Current backport branch binaries at https://julialang-s3.julialang.org/pretesting/bin/linux/x64/1.1/julia-5125952483-linux64.tar.gz. Linux x86-64 only. EDIT: Outdated

[ararslan]

Newest run that includes the fix for SparseArrays:

• [ ] AbstractOperators (see https://github.com/JuliaLang/julia/issues/30374#issuecomment-446789522)
• [ ] AstroLib
• [ ] BandedMatrices
• [ ] BlockArrays
• [ ] Bridge
• [ ] CSTParser
• [x] DistributedArrays
• [ ] FlatBuffers
• [ ] FourierFlows
• [ ] IntervalArithmetic
• [x] JSONWebTokens (version capped)
• [x] Libtask
• [ ] MCMCChain
• [ ] ONNX
• [ ] OnlineStatsBase
• [ ] POMDPs
• [ ] QDates
• [ ] Reactive
• [x] SPH (version capped)
• [ ] SimJulia
• [ ] SplitApplyCombine
• [x] SymbolServer
• [x] VT100

Logs: https://gist.github.com/ararslan/417662b28d8c6ad229083b97d6a0a206

[JeffBezanson]

https://github.com/mschauer/Bridge.jl/pull/40

[JeffBezanson]

https://github.com/JuliaIntervals/IntervalArithmetic.jl/pull/246 fixed IntervalArithmetic; just needs a new release I guess.

[JeffBezanson]

AbstractOperators: same as before; issue filed
AstroLib:

  MethodError: no method matching similar(::SubArray{Float64,1,StaticArrays.SArray{Tuple{3},Float64,1,3},Tuple{UnitRange{Int64}},true}, ::Type{Float64}, ::Tuple{Base.IdentityUnitRange{StaticArrays.SOneTo{4}}})

BandedMatrices: norm returning NaN (change test?)
BlockArrays: NaN behavior of mul! (change test?)
CSTParser: needs update
FlatBuffers: appears to be fixed, needs new release
JSONWebTokens: version capped
Libtask: same as before, changed internals
MCMCChain: can't load libQtGui; testing environment problem I assume?
OnlineStatsBase: name conflict with new eachrow and eachcol functions
ONNX: Compat thinks range(1, n) is defined but it actually throws an error
Reactive: ?
SPH: version cap
SymbolServer: same as before
VT100: same as before

[KristofferC]

I thought AstroLib would have been fixed by now (new StaticArrays release). Anyone know what is up with that, @mbauman?

---

Regarding Reactive it seems like too tight bounds in the test?

   Evaluated: isapprox(1.315094098, 1; atol=0.3)

so if the timing would have been 1.3 it would have passed.

---

OnlineStatsBase, I thought not exporting eachrow and eachcol would have not made this a problem?

---

ONNX, is the solution to this to fix Compat?

[JeffBezanson]

Yes, Compat needs to be fixed, but it looks like that can't be done without overwriting a Base method or separating Compat.range from Base.range.

eachrow and eachcol are still exported. They're in the 1.1 news as new functions. Did we mean to remove them?

[KristofferC]

I guess I misremembered the conclusion of that PR then. I thought we would wait with exporting those functions until 1.2 but apparently not.

[Nosferican]

eachrow and eachcol were decided to be exported and reach out two the few packages that would conflict with (DataFrames and OnlineStatsBase IIRC).

[giordano]

AstroLib.jl passes tests for me on release-1.1 branch.

[mbauman]

Yes, I can confirm AstroLib.jl passes for me, too. In the logs it looks like PkgEval used StaticArrays v0.10.0 and not the v0.10.2 that I have installed. That's why it failed, but I don't know why such would be the case… especially since v0.10.2 was tagged 10 days ago (and, heck, v0.10.1 was a whole month ago).

[JeffBezanson]

https://github.com/JuliaParallel/DistributedArrays.jl/pull/195

[JeffBezanson]

https://github.com/ZacLN/CSTParser.jl/pull/89

[davidanthoff]

This looks like a genuine failure that is caused by 1.1 to me. It seems, though, that FeatherLib.jl never shows up in any of the PkgEval results here. Does that indicate that the PkgEval results might miss some failures?

[Nosferican]

Any update?

[davidanthoff]

The regression that shows up in FeatherLib.jl that I reported above is still present in RC2:

https://travis-ci.org/queryverse/FeatherLib.jl/jobs/474660838

[KristofferC]

AFAIU that is a real ambiguity that got exposed from bugfixes to the typesystem and will need to be fixed in the package.

[martinholters]

Regarding the range issue introduced by Compat (ref. https://github.com/JuliaLang/Compat.jl/issues/640) and afffecting ONNX, I see these options:

1. Let Compat overwrite Base.range to not throw if neither step nor length are given. Changing the behavior of Base like this (i.e. to a state that is different from any released version) is usually not what Compat should do, but it would fix the issue.
2. Change Compat's range (on julia <1.1) to throw an error if neither step nor length are given. While technically, this might be considered a bugfix (we claim range to follow the behavior introduced in #28708), it would be a bit "impolite" and necessitate ONNX to change (which it probably should anyway).
3. Combine 1. and 2.: First do 1. in a patch (or minor?) release, then do 2. in a major (or minor?) release.
4. Rework Base.range to not throw if neither step nor length are given (defaulting to step=1) and backport that to 1.1. (I.e. make range match the behavior of the one from Compat on julia 1.0),

I don't like any of these and can't make up my mind which one I dislike the least, so if anyone wants to chime in (here or at #28708), that would be welcome.

[StefanKarpinski]

I'm fine with 1. Sure it would normally be considered bad practice, but Compat is quite special.

[ararslan]

3 seems best to me so that we minimize the amount of time spent with divergent behavior in Compat.

[Nosferican]

Was this issue identified with the PkgEval runs? https://github.com/JuliaInterop/RCall.jl/issues/289