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

fix #47658, state stack overflow on unions containing typevars #48221

Merged
merged 1 commit into from
Jan 24, 2023

Conversation

JeffBezanson
Copy link
Sponsor Member

I intended this to be a starting point for experimenting, and was astonished that it actually worked well. It may be subtly wrong; in particular I think that when this heuristic check returns true we need to come back and try the less efficient algorithm if subtyping later fails to hold. I'll try to construct a counterexample. In the meantime it's nice to see so many tests newly passing.

@nanosoldier runtests(ALL, vs=":master")

@JeffBezanson JeffBezanson added the domain:types and dispatch Types, subtyping and method dispatch label Jan 11, 2023
@JeffBezanson
Copy link
Sponsor Member Author

@nanosoldier runtests(ALL, vs=":master")

N5N3 added a commit to N5N3/julia that referenced this pull request Jan 11, 2023
They might be recreated in `finish_unionall`, (thus `lookup` returns false.)
But their bounds might still live in the current env.

close JuliaLang#44395.
(JuliaLang#44395 could also be fixed by the fast path added in JuliaLang#48221.
This commit would skip more `intersect_var` under circular constraint.)
@JuliaLang JuliaLang deleted a comment from nanosoldier Jan 11, 2023
@maleadt
Copy link
Member

maleadt commented Jan 11, 2023

It's better to use the simplified PkgEval invocation:

@nanosoldier runtests()

That will automatically default to ALL packages, as well as use the merge-base against master for a fairer comparison.

@nanosoldier
Copy link
Collaborator

Your package evaluation job has completed - possible new issues were detected.
A full report can be found here.

@JeffBezanson
Copy link
Sponsor Member Author

Wow, pretty good results:

InformationGeometry and QuantumTomography: looks like numerical issues / random tests
Unitful: unexpected pass, fixes actual bug
Zarr: network issue?

@maleadt
Copy link
Member

maleadt commented Jan 11, 2023

Zarr: network issue?

I'll add that one (connect: connection refused) to the network issue regex.

N5N3 added a commit that referenced this pull request Jan 12, 2023
* Add missing var-substitution in omit_bad_union.

follow up 3037342

* Also check free typevar's bounds in `reachable_var`

They might be recreated in `finish_unionall`, (thus `lookup` returns false.)
But their bounds might still live in the current env.

close #44395.
(#44395 could also be fixed by the fast path added in #48221.
This commit would skip more `intersect_var` under circular constraint.)

* Disallow more circulation once we set `lb`==`ub`.

close #26487.
This should be valid as we never set `X<:Y<:X` (assuming `Y` is the outer var).
@JeffBezanson
Copy link
Sponsor Member Author

JeffBezanson commented Jan 13, 2023

Ok yeah it's not that hard to fool the greedy algorithm:

julia> Tuple{Ref{Union{Int,String}}, Ref{Union{Int,String}}} <: Tuple{Ref{Union{X,Y}}, Ref{X}} where {X,Y}
false

Unfortunately this slightly more complicated case is also wrong on master:

julia> Tuple{Ref{Union{Int,String,Missing}}, Ref{Union{Int,String}}} <: Tuple{Ref{Union{X,Y}}, Ref{X}} where {X,Y}
false

Seems to have been that way at least since 1.0. (Edit: simply had to check, and amazingly this works on 0.6.4!!)

@JeffBezanson JeffBezanson changed the title WIP: fix #47658, state stack overflow on unions containing typevars fix #47658, state stack overflow on unions containing typevars Jan 19, 2023
@JeffBezanson
Copy link
Sponsor Member Author

I think this is ready to go.

Copy link
Sponsor Member

@vtjnash vtjnash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good to me. But why isn't forall_exists_equal being strictly more expensive than <:, when it supposedly calls both <: and >:

@JeffBezanson
Copy link
Sponsor Member Author

It is a bit perverse, but I think what's happening is that yes, doing both <: and >: is more expensive, but that makes it worthwhile to put in a fast path, so in this case it gets faster. We could probably add more fast paths like this elsewhere too.

@JeffBezanson JeffBezanson merged commit 596ce65 into master Jan 24, 2023
@JeffBezanson JeffBezanson deleted the jb/fix47658 branch January 24, 2023 14:05
sostock added a commit to sostock/Unitful.jl that referenced this pull request Feb 1, 2023
sostock added a commit to PainterQubits/Unitful.jl that referenced this pull request Feb 2, 2023
@JeffBezanson JeffBezanson added the backport 1.9 Change should be backported to release-1.9 label Feb 8, 2023
@KristofferC KristofferC mentioned this pull request Feb 20, 2023
50 tasks
KristofferC pushed a commit that referenced this pull request Feb 20, 2023
@KristofferC KristofferC removed the backport 1.9 Change should be backported to release-1.9 label Mar 6, 2023
KristofferC pushed a commit that referenced this pull request Mar 15, 2023
N5N3 added a commit to N5N3/julia that referenced this pull request Mar 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:types and dispatch Types, subtyping and method dispatch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants