improve method name printing in edge cases

[vtjnash]

this fixes method printing for errors and a few edge cases.
fixed printing includes:

julia> Base.Symbol() = 1
julia> (::Symbol)() = 2
julia> Base.Int() = 3
julia> (::Int)() = 4

julia> which(Symbol, Tuple{})
Symbol() at none:1

julia> which(:a, Tuple{})
(::Symbol)() at none:1

julia> which(Int, Tuple{})
Int64() at none:1

julia> which(3, Tuple{})
(::Int64)() at none:1

julia> function f(x)
                g() = x
              end
f (generic function with 2 methods)

julia> which(f(1), Tuple{})
g() at none:2

these fixes are repeated for stacktrace, MethodError, and writemime

[yuyichao]

Corner case:

julia> type A
       end

julia> type B <: Function
       end

julia> (::A)(x) = throw(x)

julia> (::B)(x) = throw(x)

julia> A()(1)
ERROR: 1
 in (::A)(::Int64) at ./none:1
 in eval at ./boot.jl:267

julia> B()(1)
ERROR: 1
 in B(::Int64) at ./none:1
 in eval at ./boot.jl:267

Not sure how to distinguish between a user defined (singleton) Function type and a plain old generic function...

[yuyichao]

This appears on both master and this branch:

julia> type B <: Function
       end

julia> B()
B (generic function with 0 methods)

[vtjnash]

some other possible conditionals that might help:
ft.name.name != ft.name.mt.name
ft == typeof(getfield(ft.name.module, name)) == getfield(ft.name.module, ft.name.name)

[yuyichao]

ft.name.name !== ft.name.mt.name (with a comment) sounds good. Would also be nice to add some tests since these feels fairly fragile....

[vtjnash]

hm, and here i was going to go with ft == typeof(getfield(ft.name.module, name))

either should fix your example, but may make closures and the kwsorter less optimal:

julia> (typeof(sum).name.mt.kwsorter)
#sum (generic function with 1 method)

julia> methods(typeof(sum).name.mt.kwsorter)
# 1 method for generic function "#sum":
(::Base.#kw##sum)(::Array{T<:Any,N<:Any}, ::Base.#sum)

however, the kwsorter doesn't have line-numbers, so it is hidden from backtraces anyways

[yuyichao]

(::Type{Base.DFT.FFTW.r2rFFTWPlan{Complex{Float64},ANY,false,2}})(::Array{Complex{Float64},2}, ::Base.DFT.FFTW.FakeArray{Complex{Float64},2}, ::UnitRange{Int32}, ::Int32, ::UInt32, ::Float64) at ./fft/FFTW.jl:552: Should be Base.DFT.FFTW.r2rFFTWPlan{Complex{Float64},ANY,false,2}(.....)?

[vtjnash]

yes, although i forgot in 0a9e6f9 why i initially hadn't done that. should be better now.

[yuyichao]

Showing a custom Function type as generic function is still a little bit strange, especially if it is not a singleton.

julia> type B <: Function
       end

julia> B()
(::B) (generic function with 0 methods)

julia> type C <: Function
           x
       end

julia> C(1)
(::C) (generic function with 0 methods)

[vtjnash]

The way I see it, <: Function is explicitly opting in to this representation. The representation issue is that we don't know the name for it, whereas with normal functions, we have (sin::#sin).

[yuyichao]

Fair enough given that we don't print the captured variables for closures either.

[yuyichao]

Test failure is #14592

[yuyichao]

Looks like some test infrastructure is also confused though.

[yuyichao]

From the code it looks like we neither recompile the function nor trying to get it from the sysimg?

Seems that OSX CI passes since we are not running the reflection test and windows tests passes since we don't have a sysimg library....

[vtjnash]

rebased to try again on CI -- and all looks good (other than the travis worker that failed to start)

[tkelman]

should we be touching base methods on base types in the tests like this?

[vtjnash]

if it comes up, we can add a dummy argument (perhaps EightBitType). but for now, i specifically want to test Symbol since it has a special and unique representation.

[tkelman]

Travis issue was a problem during the initial apt-get install of the ppa gcc version that we need due to recent llvm.

I guess Symbol() is already a MethodError so maybe not too bad to mess with it in the tests, for now.