"error occurred during inference" MethodError on 0.6RC1 #21848
Comments
JeffBezanson
added
compiler:inference
|
Try applying this patch and seeing what output we get: |
|
Thanks very much for taking a look at this. Here's the output I get after adding that patch in, it definitely hit your print statement. (minor note but I ran this from the REPL as opposed to from Atom like above, just since it seemed to multiplex the output nicer, but I don't think that made any any difference) I guess one thing that stands out is that both my If its any help, here's their definition, struct LazyBinaryOp{F,A<:Union{LinOp,Scalar},B<:Union{LinOp,Scalar}} <: LinOp{Pix,Spin,Basis}
a::A
b::B
LazyBinaryOp(op,a::A,b::B) where {A,B} = new{op,A,B}(a,b)
end
@with_kw struct FuncOp{F<:Union{Function,Void},Fᴴ<:Union{Function,Void},F⁻¹<:Union{Function,Void},F⁻ᴴ<:Union{Function,Void}} <: LinOp{Pix,Spin,Basis}
op ::F = nothing
opᴴ ::Fᴴ = nothing
op⁻¹::F⁻¹ = nothing
op⁻ᴴ::F⁻ᴴ = nothing
end |
|
Wow, that are impressively complicated types! And it really makes me wish they would parse as they were printed. With all typevars just |
Yea, its mostly coming from that I essentially parse a complicated arithmetic expression into a recursive bunch of those Just throwing this out there, but since I'm still unable to come up with a good reduced example, would it be helpful if I e.g. sent you guys a Docker container that just has my whole code running and triggers this bug? The codes not public yet, and you probably wouldn't want to waste time getting the dependencies anyway, which is why I'd do it this way and just send privately. Let me know if that's something that'd be useful. |
|
I see a possible bug in that assertion, which might be avoided by the following patch. However, I don't know that this is what you are seeing. diff --git a/base/inference.jl b/base/inference.jl
index 9dab296025..03a7f2e5f0 100644
--- a/base/inference.jl
+++ b/base/inference.jl
@@ -704,8 +704,14 @@ function limit_type_depth(t::ANY, d::Int, cov::Bool, vars::Vector{TypeVar}=TypeV
P = t.parameters
isempty(P) && return t
if d > MAX_TYPE_DEPTH
- cov && return t.name.wrapper
- var = TypeVar(:_, t.name.wrapper)
+ widert = t.name.wrapper
+ if !(t <: widert)
+ # oops, this'll trigger our subtype assertion
+ # widen even faster to something safe
+ widert = Any
+ end
+ cov && return widert
+ var = TypeVar(:_, widert)
push!(vars, var)
return var
endIf not, a docker example sounds like a good idea and you can PM me a link. Test case for triggering above error: julia> Core.Inference.limit_type_depth(Ref{Complex{T} where T}, Core.Inference.MAX_TYPE_DEPTH)
ERROR: AssertionError: !(t isa Type) || t <: r |
|
Thanks. With both patches applied now, it does change the types that get printed to the much shorter, The full output is here. You can also see a second error that actually kills the program, which I realize I had missed when I posted my original output (and when I said that the program continued OK otherwise), not sure if there's anything useful there. I'm packaging up stuff in Docker now and will send shortly. Also, I think I've found a workaround for me which was basically to go through and make the relevant parts of the code more type stable, which perhaps was to be expected. |
|
@marius311 see if #21907 fixes the original code. |
|
Yep! That looks like it fixes my original bug. FWIW I rebased that commit onto 0.6rc1 b/c other stuff was broken otherwise, so I didn't technically check if it interacts with anything else that might be on master now. But in any case, thanks! |
fix #21848, bug in widening done by limit_type_depth
Apologies I don't have a reduced code snippet, but this is happening in a pretty big chunk of code and it requires restarting Julia every time to narrow down the actual source of the error. Instead, I thought maybe just maybe someone knowledgeable enough can guess what's happening from the stack trace below, or offer guesses as to what to look for in narrowing it down.
Basically, once I execute the offending code, the below error/warning is printed, although the program continues seemingly without error. Its reproducible every time. This is on 0.6rc1.
The text was updated successfully, but these errors were encountered: