Type signature abbreviation in method error sometimes hides the information you need to know why it doesn't match

[oxinabox]

Consider for example:

struct Foo{A, B, C} end
bar(::Foo{Tuple{Int}}) = 1
bar(::Foo{Tuple{Float64}}) = 1

bar(Foo{Tuple{Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char}, Dict{Int, Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int, Int}}}}}}}}, Dict{Int, Dict{Int, Dict{Int, Int}}}}())

This is a method error becuase the first arguement is some giant tuple mixing Char and Int,
and there are only methods for if it was a 1-tuple of Int, or of Float64.
The key info you need to find what has gone wrong in your code is that first type parameter.
However, because of type abbreviation in the display of method errors, you do not always see that.
In this case the error is

ERROR: MethodError: no method matching bar(::Foo{Tuple{…}, Dict{…}, Dict{…}})

Closest candidates are:
  bar(::Foo{Tuple{Float64}})
   @ Main REPL[3]:1
  bar(::Foo{Tuple{Int64}})
   @ Main REPL[2]:1

We can't tell what is wrong with the Tuple type param, since its parameters are hidden.
(show(err) does make this display fully as you would hope. in my real world example though show(err) resulted in enough text being displayed from my stacktrace that my terminal started glitching)

As I understand it, the logic in type-signature abbreviation is such that any type parameters that are required to hit the particular dispatch are shown.
That makes sense for display in stacktraces -- you can know why a particular path was followed.
But that logic does not work for MethodError. For method error we want to see enough info to know why no existing method was hit.

I propose that, for now, we should not abbreviate type signatures in method errors,
until we can work out suitable logic for their abbreviation.

[oxinabox]

@timholy basically I am proposing we revert #50809
pending working out a better way of determining which things we can abbreviate.

[rafaqz]

I just hit this too. We should be able to modify the amount of abbreviation until its not longer ambiguous what the problem is given the available method signature?

[timholy]

Why can't one do this:

julia> struct Foo{A, B, C} end

julia> bar(::Foo{Tuple{Int}}) = 1
bar (generic function with 1 method)

julia> bar(::Foo{Tuple{Float64}}) = 1
bar (generic function with 2 methods)

julia> bar(Foo{Tuple{Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char,Int,Char,Char,Char,Char,Char,Char,Char,Char,Int, Char}, Dict{Int, Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int,  Dict{Int, Int}}}}}}}}, Dict{Int, Dict{Int, Dict{Int, Int}}}}())
ERROR: MethodError: no method matching bar(::Foo{Tuple{…}, Dict{…}, Dict{…}})

Closest candidates are:
  bar(::Foo{Tuple{Float64}})
   @ Main REPL[3]:1
  bar(::Foo{Tuple{Int64}})
   @ Main REPL[2]:1

Stacktrace:
 [1] top-level scope
   @ REPL[4]:1
Some type information was truncated. Use `show(err)` to see complete types.

julia> show(err)
1-element ExceptionStack:
MethodError: no method matching bar(::Foo{Tuple{Char, Int64, Char, Char, Char, Char, Char, Char, Char, Char, Int64, Char, Int64, Char, Char, Char, Char, Char, Char, Char, Char, Int64, Char, Int64, Char, Char, Char, Char, Char, Char, Char, Char, Int64, Char}, Dict{Int64, Dict{Int64, Dict{Int64, Dict{Int64, Dict{Int64, Dict{Int64, Dict{Int64, Dict{Int64, Int64}}}}}}}}, Dict{Int64, Dict{Int64, Dict{Int64, Int64}}}})

Closest candidates are:
  bar(::Foo{Tuple{Float64}})
   @ Main REPL[3]:1
  bar(::Foo{Tuple{Int64}})
   @ Main REPL[2]:1

Stacktrace:
 [1] top-level scope
   @ REPL[4]:1

Prior discussion: #50803 (comment)

[timholy]

Ah, I just noticed that you anticipated this, @oxinabox:

(show(err) does make this display fully as you would hope. in my real world example though show(err) resulted in enough text being displayed from my stacktrace that my terminal started glitching)

But if we just revert #50809, your terminal will again glitch, no? So doesn't that leave us with:

• the status quo is better than reverting Limit type-printing in MethodError #50809
• but what we really all want is something more sophisticated

[oxinabox]

The problem is show(err) not only shows the error message itself with this expanded,
But also shows the stacktrace with everything expanded -- which is 1-2 orders of magnitude more printing than just the error message.
It's printing the expanded stack trace that kills my terminal.

One option could be to have a way to control the expansion (or display at all) of the stacktrace separately from the error message.
Either with a separate function or a flag like show(err; stacktrace=false)
but that does have a discoverability problem, but we could maybe mention it in the error message for MethodError ?

[timholy]

Base.showerror(stdout, only(err.stack).exception) is a workaround for the moment.

[oxinabox]

I ran into this again today. Though in this case its merely annoying to use show(err) and see the expanded stacktrace + the expanded error message
I still propose that we revert #50809.
I think it is net worse than not having it, and I suspect its particularly an issue for new users (who are also more likely to run into this)

[rafaqz]

Here's another one from the wild:

Possible fix, define
  similar(::Type{T}, ::Tuple{Union{…}, Union{…}, Vararg{…}}) where T<:AbstractArray

From this issue:
rafaqz/DimensionalData.jl#852

In this case I would have to ask op to repost the error from err or run it myself, adding a small but real barrier to understanding the problem.

[vtjnash]

How about we compromise and change the heuristic to be no less than 5 lines or 500 characters, instead of the current default of 1 line or 20 characters? There are clearly problem cases where we print several kilobytes and multiple screens of info, where even the full info won't be useful. But the current default is now seen to be failing in the wild on many useful cases.

[vtjnash]

Additional, perhaps we update the message text to add "or delete the conflicting method", which appears to be the correct solution in this case where the Union was too large and incorrect to print