make `@which` never return kwcall

[oxinabox]

kwcall is an implementation detail of how keyword arguments are implemented.

But if you write a function with keyword arguments and call @which on it, it is reported as the method being hit.
though it does get the file/line number correct for the user facing method.

julia> @which foo(1; a=1)
kwcall(::Any, ::typeof(foo), x)
     @ Main REPL[1]:1

[vchuravy]

What method should be shown instead? The answer currently given is correct.

julia> foo(b; a=1) = a + b
foo (generic function with 1 method)

julia> Core.kwcall((;a=2), foo, 1)
3

julia> Core.kwftype(foo)
typeof(Core.kwcall) (singleton type of function kwcall, subtype of Function)

[KristofferC]

I don't think which can be made to lie, it really has to return the method being called. But there could be alternative versions that step through these generated "wrappers". JuliaInterpreter.jl has quite a bit of code to do that.

[vtjnash]

This is not which that lies though, it is InteractiveUtils.gen_call_with_extracted_types that injects Core.kwcall to make the lookup more accurately useful for the code_* macros. This might be a question of whether to use the internal syntax or a more natural syntax with ; kwargs... when printing methods on Core.kwcall

[oxinabox]

@which in InteractiveUtils. It's for interactive use by the user.
(Base.which on the other hand maybe we need to be more careful with.)

What method should be shown instead?

I see no reason not to just show the signature of the method the user would hit.

So considering:

julia> foo(x; kwargs...) = x
foo (generic function with 1 method)

julia> @which foo(1)
foo(x; kwargs...)
     @ Main REPL[5]:1

julia> @which foo(1; a=1)
kwcall(::NamedTuple, ::typeof(foo), x)
     @ Main REPL[5]:1

we can have both of them show the same. Keyword arguments don't effect dispatch.

foo(x; kwargs...)
     @ Main REPL[5]:1

This, for reference is the special case that would need to be changed:
https://github.com/JuliaLang/julia/blob/5d82d8095042935be0eb044259098e0d7c695922/stdlib/InteractiveUtils/src/macros.jl#L96C1-L103
I think it might just be as simple as discarding the kwargs after they are split out.
Possibly after also checking that with kwargs it doesn't error.

We could go further and change how kwcall is printed everywhere by special casing it in the method_show code. Which might be nice, if we wanted to also hide it in stack-traces.
But seems out of scope for this issue.

[BioTurboNick]

I want to +1 addressing this.

As of today, the stack trace display pathway removes kwcall frames, so it seems the intent is to hide them from the user in most cases.