Mega-issue for packages failing PkgEval for 1.1 release #30374
Comments
KristofferC
added
status:help wanted
|
|
|
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. |
|
#28941 seems to have caused the failure of |
|
As a sanity check I reran WignerSymbols and IterableTables, which both reported failure after passing tests, and both now report success. |
|
AbstractOperators has generated functions that call |
|
LegacyStrings was fixed by JuliaStrings/LegacyStrings.jl#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...) |
|
For @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)) # failshowever 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 $next = iterate($iterator_value, $state)where it looks like 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
endEdit3 there's another (different) problem with the function FWIW I've opened an issue for both over there. (JuliaDynamics/ResumableFunctions.jl#30) |
|
Just a note that for |
|
|
|
using TypedPolynomials
@polyvar x y
p = 2x^2 - 3x + y |
@Keno: any idea about this? I don't recall anything changing here, I wonder if it's a lowering change... |
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:0That is a rather perplexing error message. Is it possible that two different parametric types called |
|
QDates are due to #29404 changing the type of the Issue opened: antimon2/QDates.jl#4 |
|
The AstroLib failure is actually a StaticArrays issue — and there's a fix underway there. JuliaArrays/StaticArrays.jl#568 |
|
SVR.jl failed on my unupdated backport branch with: but rebuilding and running the tests again they pass, so seems this was fixed (maybe #30350). |
|
I can't repro the TypedPolynomials failure: and and Maybe it got fixed by some new backported PR? Can someone else try? |
|
The difference in ResumableFunction is obvious looking at https://www.diffchecker.com/rJ55k9Ac. For some reason, the generated struct has the field: now while before it had causing the conversion error. |
|
W.r.t ResumableFunction I think this is just a bug in the package and now fails because our inference got better. #30374 (comment) should fix the package. The package contains code like which doesn't really follow our stability guarantees, so I don't think we have to do anything about this. |
|
Arrow.jl passes locally. |
|
A further problem exposed by StaticNumbers is that |
|
Anybody know what's going on here? Looks like |
|
That's the same issue as JuliaArrays/StaticArrays.jl#568. The trouble is that both packages are defining their own |
|
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 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 |
|
Seems like the linked issue/PR for OffsetArrays, AxisArrays, AstroLib have been merged/closed. Check status after the action and update the checklist? |
|
Yes, we should rerun PkgEval on the backport branch now. |
|
Newest PkgEval results show the following failures in relation to 1.0.3:
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 |
|
There are no binaries for |
|
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 |
|
Newest run that includes the fix for SparseArrays:
Logs: https://gist.github.com/ararslan/417662b28d8c6ad229083b97d6a0a206 |
|
JuliaIntervals/IntervalArithmetic.jl#246 fixed IntervalArithmetic; just needs a new release I guess. |
|
AbstractOperators: same as before; issue filed BandedMatrices: |
|
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? so if the timing would have been 1.3 it would have passed. OnlineStatsBase, I thought not exporting ONNX, is the solution to this to fix Compat? |
|
Yes, Compat needs to be fixed, but it looks like that can't be done without overwriting a Base method or separating
|
|
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. |
|
|
|
|
|
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). |
|
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? |
|
Any update? |
|
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 |
|
AFAIU that is a real ambiguity that got exposed from bugfixes to the typesystem and will need to be fixed in the package. |
|
Regarding the
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. |
|
I'm fine with 1. Sure it would normally be considered bad practice, but Compat is quite special. |
|
3 seems best to me so that we minimize the amount of time spent with divergent behavior in Compat. |
|
Was this issue identified with the PkgEval runs? JuliaInterop/RCall.jl#289 |
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.
Analysis:
Zygote
LoadError: type StmtRange has no field first.Uses a lot of internal features. Can likely ignore.
WignerSymbols
Testing WignerSymbols tests passedwut?
VT100
ERROR: LoadError: LoadError: MethodError: no method matching Base.TTY(::RawFD; readable=true)Base.TTYis 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
Should investigate
StaticNumbers
SplitApplyCombine
Maybe we just fixed something?
SPH
Package is upper bounded, seems like this is working as intended
ResumableFunctions
should investigate,
QDates
Seems like some state from an iterator has changed. Should investigate.
OffsetArrays
Nullables
Fixed by #30350
MultivariatePolynomials
Fixed by #30360??
MathematicalSystems
Looks weird. Should investigate.
Libtask
Using internal structure of
TaskLegacyStrings
Should investigate
JSONWebTokens
Package is upper bounded, ok.
IterableTables
Testing IterableTables tests passedHmm.
Distances
Improvement, can ignore.
DecFP
Should investigate.
CSTParser
Is quite closely tied to the internals of julia.
BlockArrays
Changed
0 * NaN = NaNin BLAS1. Desired change even though breaking.BandedMatrices
Same as package above.
AxisArrays
AstroLib
Arrow
Should investigate
AbstractOperators
Some parser change?
The text was updated successfully, but these errors were encountered: