Skip to content
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

Wrong number of methods after redefinition of function #53814

Open
giordano opened this issue Mar 22, 2024 · 6 comments
Open

Wrong number of methods after redefinition of function #53814

giordano opened this issue Mar 22, 2024 · 6 comments
Labels
bug Indicates an unexpected problem or unintended behavior
Milestone

Comments

@giordano
Copy link
Contributor

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.

@giordano giordano added bug Indicates an unexpected problem or unintended behavior bisect wanted labels Mar 22, 2024
@giordano giordano added this to the 1.12 milestone Mar 22, 2024
@Keno
Copy link
Member

Keno commented Mar 22, 2024

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
Copy link
Contributor

Bisected to #53415

@Keno
Copy link
Member

Keno commented Apr 1, 2024

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
Copy link
Member

vtjnash commented Apr 1, 2024

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
Copy link
Member

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
Copy link
Member

vtjnash commented May 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior
Projects
None yet
Development

No branches or pull requests

5 participants