You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Step 2a: run type inference with the input type even if abstract
# and party if we're concrete
@debug"is_stable_method: check against signature (2a)"
try
ifis_stable_call(func, sig_types)
is_stable_call will call code_typed with an abstract input type (potentially), which can return several results and this is not handled at all: is_stable_call will just take the first CodeInfo:
(_ #=code=#, res_type) = ct[1] # we ought to have just one method body, I think
This is sound for a concrete input type, but the shortcut uses an abstract one. So, is_stable_call should make sure that if there are several results from code_typed, it picks the right one.
The text was updated successfully, but these errors were encountered:
I can't see why it would return several results when called with the signature types of a particular method. Only that method will be returned always, I think? I seem to recall that Jan V convinced me that it's a real issue, but now I can't recall how and why. We can run an experiment, of course. But priority High doesn't seem to be justified.
One idea: can it happen if the methods are unlmbiguous? But then the whole program doesn't make sense...
Code in question:
julia-type-stability-checker/src/StabilityCheck.jl
Lines 142 to 146 in ae53bd0
is_stable_call
will callcode_typed
with an abstract input type (potentially), which can return several results and this is not handled at all:is_stable_call
will just take the firstCodeInfo
:julia-type-stability-checker/src/utils.jl
Line 42 in ae53bd0
This is sound for a concrete input type, but the shortcut uses an abstract one. So,
is_stable_call
should make sure that if there are several results fromcode_typed
, it picks the right one.The text was updated successfully, but these errors were encountered: