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

Weird type inference(?) behavior with a type unstable creation of a type wrapping a vector of tuples. #16530

Closed
KristofferC opened this issue May 23, 2016 · 5 comments · Fixed by #17953
Assignees
Labels
compiler:inference Type inference kind:bug Indicates an unexpected problem or unintended behavior kind:regression Regression in behavior compared to a previous version
Milestone

Comments

@KristofferC
Copy link
Sponsor Member

KristofferC commented May 23, 2016

This is a reduced example of some code that started failing for me. I haven't bisected it but my guess is the Vararg changes but it could also be something with when typeof is evaluated, @timholy

type Foo{dim}
    c::Vector{NTuple{dim, Float64}}
end

function f()
    sdim = 1+1
    c = Vector{NTuple{sdim, Float64}}(1)
    c[1] = (1.0, 2.0)
    a = Foo{sdim}(c)
    println(typeof(a.c))
    return a
end

a = f()
println(typeof(a.c))

Executing this on current master gives:

julia> a = f();
Array{Tuple{Vararg},1}

julia> println(typeof(a.c))
Array{Tuple{Float64,Float64},1}

Inside the function, typeof(a.c) is Array{Tuple{Vararg},1} but outside it is Array{Tuple{Float64,Float64},1}. Note that this problem goes away if sdim is made a constant. This also seems to go away if instead of storing a Vector{NTuple} a simple NTuple is stored.

On an old 0.5 commit this gives the expected:

julia> a = f();
Array{Tuple{Float64,Float64},1}

julia> println(typeof(a.c))
Array{Tuple{Float64,Float64},1}
@KristofferC
Copy link
Sponsor Member Author

Will run a bisect now.

@KristofferC
Copy link
Sponsor Member Author

KristofferC commented May 23, 2016

Can't bisect because I keep getting:

/home/kristoffer/julia/src/init.c: In function ‘init_stdio_handle’:
/home/kristoffer/julia/src/init.c:350:48: error: ‘UV_TTY_MODE_NORMAL’ undeclared (first use in this function)
             uv_tty_set_mode((uv_tty_t*)handle, UV_TTY_MODE_NORMAL); //cooked stdio
                                                ^
/home/kristoffer/julia/src/init.c:350:48: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [init.o] Error 1
make: *** [julia-src-release] Error 2

@vtjnash
Copy link
Sponsor Member

vtjnash commented May 23, 2016

bisect shouldn't be needed here, it looks straightforward enough from your examples. in the future, you can do rm usr/lib/libuv* && make to force it to reinstall libuv (otherwise, it gets confused which version it has installed)

@KristofferC
Copy link
Sponsor Member Author

This is a regression so should have a tag + eventually 0.5.0 mark?

@vtjnash vtjnash added the kind:bug Indicates an unexpected problem or unintended behavior label Jun 13, 2016
@vtjnash vtjnash self-assigned this Jun 13, 2016
@KristofferC
Copy link
Sponsor Member Author

Bump.

@JeffBezanson JeffBezanson added the kind:regression Regression in behavior compared to a previous version label Jul 27, 2016
@JeffBezanson JeffBezanson added this to the 0.5.x milestone Jul 27, 2016
@JeffBezanson JeffBezanson added the compiler:inference Type inference label Aug 10, 2016
vtjnash added a commit that referenced this issue Aug 10, 2016
it should trust the return value 'exact' that was meticulously computed for getfield_tfunc,
instead of trying to recompute it (badly)

also make getfield_tfunc monotonic for the case where the type has one field

fix #16530
vtjnash added a commit that referenced this issue Aug 11, 2016
Vararg is only exact if in covariant position

also make getfield_tfunc monotonic for the case where the type has one
field, to avoid the same bug

fix #16530
tkelman pushed a commit that referenced this issue Aug 20, 2016
Vararg is only exact if in covariant position

also make getfield_tfunc monotonic for the case where the type has one
field, to avoid the same bug

fix #16530

(cherry picked from commit aeaff55)
ref #17953
mfasi pushed a commit to mfasi/julia that referenced this issue Sep 5, 2016
Vararg is only exact if in covariant position

also make getfield_tfunc monotonic for the case where the type has one
field, to avoid the same bug

fix JuliaLang#16530
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:inference Type inference kind:bug Indicates an unexpected problem or unintended behavior kind:regression Regression in behavior compared to a previous version
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants