-
Notifications
You must be signed in to change notification settings - Fork 147
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 method ambiguity for qr
(#931) and lingering ambiguities for lu
#932
Conversation
The failure on nightly is unfortunately related to the strategy for resolving these ambiguities: f(x::Float64; kw=2) = x+kw
f(x::Int; kw=2) = x+kw
fInt(x; kw=2) = Base.@invoke f(x::Int; kw)
fFloat(x; kw=2) = Base.@invoke f(x::Float64; kw) where neither So the crux of the problem seems to be that using What would be a good way to sidestep this? Not inferring on |
The issue with |
Okay, to fix this, I just dropped the Locally, all tests pass for me on nightly now. |
Thanks for investigating it, this approach looks fine. Could you bump the patch version? |
Sure: done! |
…ties for `lu` (JuliaArrays#932) * fix `qr` method ambiguities (JuliaArrays#931) and lingering `lu` ambiguities (JuliaArrays#920) * fix inferrence issues due to using `@invoke` for `lu` keyword arguments * bump version
This basically does just what #921 did to fix #920 for #931; i.e., removes the ambiguity for
qr
.While doing that, I noticed that #921 hadn't completely resolved the ambiguity for
lu
; e.g., if called aslu(A, Val(false))
there would still be an ambiguity error; so I fixed that as well. Similarly, I believe it would previously have been ambiguous if provided with acheck
keyword argument.Added a few tests as well.