-
-
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
fix #47658, state stack overflow on unions containing typevars #48221
Conversation
fe02b62
to
fce9a3b
Compare
@nanosoldier |
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.)
It's better to use the simplified PkgEval invocation: @nanosoldier That will automatically default to ALL packages, as well as use the merge-base against master for a fairer comparison. |
Your package evaluation job has completed - possible new issues were detected. |
Wow, pretty good results: InformationGeometry and QuantumTomography: looks like numerical issues / random tests |
I'll add that one ( |
* 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).
Ok yeah it's not that hard to fool the greedy algorithm:
Unfortunately this slightly more complicated case is also wrong on master:
Seems to have been that way at least since 1.0. (Edit: simply had to check, and amazingly this works on 0.6.4!!) |
fce9a3b
to
f824845
Compare
I think this is ready to go. |
There was a problem hiding this 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 >:
It is a bit perverse, but I think what's happening is that yes, doing both |
Broken tests were fixed by JuliaLang/julia#48221
Broken tests were fixed by JuliaLang/julia#48221
…ontaining typevars (JuliaLang#48221)"" This reverts commit 7d335a0.
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")