Wrong number of methods after redefinition of function

[giordano]

On latest master (52fc796) the number of methods for a function for which we redefine the same method multiple times increases steadily:

julia> f() = nothing
f (generic function with 1 method)

julia> f() = nothing
f (generic function with 2 methods)

julia> f() = nothing
f (generic function with 3 methods)

julia> methods(f)
# 3 methods for generic function "f" from Main:
 [1] f()
     @ REPL[1]:1
 [2] f()
     @ REPL[1]:1
 [3] f()
     @ REPL[1]:1

julia> length(methods(f)) == 1
false

length(methods(f)) would be a good test for the resolution of this bug, or for a bisection script (can't run it myself now). This doesn't happen in v1.10 nor v1.11, so it should be somewhat recent.

[Keno]

IIRC @vtjnash said this was intentional, but there was much complaining from pretty much anyone, so I think we need to think about this again, possibly by tweaking the display code to only display methods that are reachable in the current world.

[christiangnrd]

Bisected to #53415

[Keno]

How about the following: We change the display code to only count methods which are reachable in the current world for some signature. Now, I don't believe we have that exact query in the type system, but I think something along the lines of typesubtract(m.sig, mapreduce(m2->m2.sig, Union, filter(!=(m), methods(m.sig)) !== Union{} would be pretty close. It's a little expensive to compute, but probably doesn't matter for interactive showing.

[vtjnash]

I don't believe we have that exact query in the type system

It is exactly the query you get if specifying lim != -1, though it indeed is expensive. Of note though that this can be approximated quite well with a O(1) pair-wise check (and which is an exact if there is no ambiguities), as two type-egal methods must be adjacent in the output list, per the definition of morespecific, after filtering ambiguities.

[JeffBezanson]

This also seems unexpected:

f() = 1
f() = 2

julia> methods(f, Tuple{})
# 1 method for generic function "f" from Main:
 [1] f()
     @ REPL[15]:1

julia> methods(f, Tuple{Vararg{Any}})
# 2 methods for generic function "f" from Main:
 [1] f()
     @ REPL[15]:1
 [2] f()
     @ REPL[14]:1

[vtjnash]

The behavior of lim==-1 has always been that way for whether it chooses to filter out supertypes. I suppose because it happens to be O(n) whereas the filter for the general case is O(n^3), where n is the number of methods that matched

[vtjnash]

Thinking about this today, I think the question is which point do we want to "lie" about this result: should it be a change to ml_matches itself (for lim==-1) or a filter call in julia of the ml_matches result afterwards