Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dispatch error with bound TypeVar argument on a second call to a "recursive" function. #11355

Closed
yuyichao opened this issue May 19, 2015 · 7 comments
Assignees

Comments

@yuyichao
Copy link
Contributor

Repro:

function f{T<:Tuple}(sig::Type{T})
    println(1)
    f(sig.parameters[1])
end
function f(arg::DataType)
    println(2)
    if arg <: Tuple
        error("Dispatch error!")
    end
end

t = Tuple{Type{Dict{TypeVar(:K, true)}}}

println("First time")
f(t)
println("Second time")
f(t)

Mailing list thread
@mauro3

@yuyichao
Copy link
Contributor Author

Output:

yuyichao% JULIA_LOAD_PATH=${PWD}/.. julia -f runtests.jl
First time
1
2
Second time
2
ERROR: LoadError: Dispatch error!
 in f at /home/yuyichao/projects/mirrors/Traits.jl/runtests.jl:10
 in include_from_node1 at ./loading.jl:134
while loading /home/yuyichao/projects/mirrors/Traits.jl/runtests.jl, in expression starting on line 19

Changes that can make the problem disappear:

  1. Do not call f(::DataType) in f{T<:Tuple}(::Type{T})
  2. Make the TypeVar not bound
  3. Call f only once
  4. (Added by @mauro3 , see next comment) Remove ::DataType in the definition of the second method

Maybe some caching issue??

@mauro3
Copy link
Contributor

mauro3 commented May 19, 2015

Leaving away ::DataType in function f(arg::DataType) makes the problem disappear too.

@yuyichao
Copy link
Contributor Author

Yeah you are right. Forgot to check that.

@mauro3
Copy link
Contributor

mauro3 commented May 19, 2015

Although, in Traits.jl that trick doesn't seem to work (a shame, I thought I had a work-around).

@yuyichao
Copy link
Contributor Author

You have another definition below that rigth?

@mauro3
Copy link
Contributor

mauro3 commented May 19, 2015

Yes, but adding that other definition doesn't change the behavior of your example. It doesn't matter though, there are other workarounds.

mauro3 added a commit to mauro3/Traits.jl that referenced this issue May 24, 2015
@mauro3
Copy link
Contributor

mauro3 commented May 24, 2015

This test case still errors in the last line:

function f{T<:Tuple}(sig::Type{T})
    println(1)
    f(sig.parameters[1])
end
function f(arg::DataType)
    println(2)
    if arg <: Tuple
        error("Dispatch error!")
    end
end

t = Tuple{Type{Array{Int,1}}}
f(t)
t = Tuple{Type{Dict{TypeVar(:K, true)}}}
f(t)

with

2
ERROR: Dispatch error!
 in f at none:4

Please re-open.

@JeffBezanson JeffBezanson reopened this May 24, 2015
@JeffBezanson JeffBezanson self-assigned this May 24, 2015
mauro3 added a commit to mauro3/Traits.jl that referenced this issue May 25, 2015
mbauman pushed a commit to mbauman/julia that referenced this issue Jun 6, 2015
mbauman pushed a commit to mbauman/julia that referenced this issue Jun 6, 2015
tkelman pushed a commit to tkelman/julia that referenced this issue Jun 6, 2015
tkelman pushed a commit to tkelman/julia that referenced this issue Jun 6, 2015
vtjnash added a commit that referenced this issue Apr 3, 2016
this allows us to correct the type signature before passing it to the generated function
or returning it from ml_matches
this also improves the fix for #11840 to cover Union
but breaks the fix for #11355 -- fortunately, our improved cache should soon be up to the challenge of fixing it too
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants