-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
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
Will run a bisect now. |
Can't bisect because I keep getting:
|
bisect shouldn't be needed here, it looks straightforward enough from your examples. in the future, you can do |
This is a regression so should have a tag + eventually 0.5.0 mark? |
vtjnash
added
the
kind:bug
Indicates an unexpected problem or unintended behavior
label
Jun 13, 2016
Bump. |
JeffBezanson
added
the
kind:regression
Regression in behavior compared to a previous version
label
Jul 27, 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
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
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 whentypeof
is evaluated, @timholyExecuting this on current master gives:
Inside the function,
typeof(a.c)
isArray{Tuple{Vararg},1}
but outside it isArray{Tuple{Float64,Float64},1}
. Note that this problem goes away ifsdim
is made a constant. This also seems to go away if instead of storing aVector{NTuple}
a simpleNTuple
is stored.On an old 0.5 commit this gives the expected:
The text was updated successfully, but these errors were encountered: