-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
fix #9770 (type inference error) #9926
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
Conversation
diff --git a/base/inference.jl b/base/inference.jl
index 3e4f091..c8c0e2d 100644
--- a/base/inference.jl
+++ b/base/inference.jl
@@ -1311,7 +1311,7 @@ function typeinf(linfo::LambdaStaticData,atypes::Tuple,sparams::Tuple, def, cop)
# return best guess so far
f = f::CallStack
f.recurred = true
- f.toprec = !f.rec
+ f.toprec = f.toprec || !f.rec
f.rec = true
r = inference_stack
while !is(r, f)
|
here's my newest attempt at breaking it:
|
Is this causing appveyor to time out with a higher-than-usual probability? OSX Travis too? |
yes, even with the above patch now included, it significantly increases build times |
Rebased. But yes, for me this took the sysimg build time (starting with inference0) from 3 minutes to 4 minutes. |
that's actually not a bad as I feared. initially i think this was at least doubling the build time (appveyor went from 20minutes to > 40 minute). is it worthwhile to switch inference to a queue instead of recursion to do the much faster fix for this while we wait for the green-fairy (which i've been told already handles this case)? |
also fixes #9222 |
test? and more descriptive commit message? |
here's the segfault-enhanced test case for this:
@JeffBezanson i don't like adding all of the
typeinf
function to the "don't-infer" list, but it seemed to suffice to get through type inference