Adding docstring to constructor leads to ERROR: LoadError: type BottomType has no field name

[helgee]

Loading of one of my packages started to fail when I added a second docstring to one of the constructors. I have boiled the problem down to this minimal example:

module Test

abstract type AbstractType end

# Necessary to trigger the bug.
Base.show{T<:AbstractType}(io::IO, ::Type{T}) = print(io, T.name.name)

struct Struct{T<:AbstractType}
    jd1::Float64
    jd2::Float64
end

""
function Struct{T}(arg1) where T<:AbstractType
end

""
function Struct{T}(arg1, arg2, arg3) where T<:AbstractType
end

end # module

If you comment out either of the docstrings the module will load. Otherwise the following error is raised:

julia> using Test
ERROR: LoadError: type BottomType has no field name
Stacktrace:
 [1] print(::Base.AbstractIOBuffer{Array{UInt8,1}}, ::Core.BottomType) at ./strings/io.jl:29
 [2] #print_to_string#220(::Void, ::Function, ::String, ::Vararg{Any,N} where N) at ./strings/io.jl:102
 [3] print_to_string(::String, ::Vararg{Any,N} where N) at ./strings/io.jl:91
 [4] string(::String, ::Base.Docs.Binding, ::Vararg{Any,N} where N) at ./strings/io.jl:120
 [5] doc!(::Base.Docs.Binding, ::Base.Docs.DocStr, ::Any) at ./docs/Docs.jl:225
 [6] include_from_node1(::String) at ./loading.jl:539
 [7] eval(::Module, ::Any) at ./boot.jl:235
 [8] require(::Symbol) at ./loading.jl:453
while loading /Users/helge/.julia/v0.6/Test/src/Test.jl, in expression starting on line 511

[yuyichao]

The inlining isn't very clear but the error is raised by your code since it overwrite the show of Union{}. Somehow the method you define is more specific than show(::IO, ::Core.BottomType).

[StefanKarpinski]

Somehow the method you define is more specific than show(::IO, ::Core.BottomType).

That does not seem like it should be possible or callable even if defined.

[yuyichao]

Which do you mean? I'm not sure what BottomType is but it's not Bottom.

[helgee]

The equivalent 0.5 version works. Am I correct that there is no Bottom in the old type system?

module Test

abstract AbstractType 

Base.show{T<:AbstractType}(io::IO, ::Type{T}) = print(io, T.name.name)

immutable Struct{T<:AbstractType}
    jd1::Float64
    jd2::Float64
end

""
function Struct{T<:AbstractType}(::Type{T}, arg1)
end

""
function Struct{T<:AbstractType}(::Type{T}, arg1, arg2, arg3)
end

end # module

And I just learned: typeof(Union{}) == Core.BottomType

[yuyichao]

there is no Bottom in the old type system?

There is. With different representation.

The dispatch issue seems new though the definition of show is buggy in either version.

[helgee]

The issue in the doc system seems to be that it cannot extract the signature from the :where expressions and thus cannot distinguish between the two constructors.

[JeffBezanson]

Yep, there's both a specificity issue and a doc system issue here.

[JeffBezanson]

#21023 covers the specificity part.

[helgee]

Currently the doc system does not extract signatres from expressions with UnionAlls at all.

When I enable that code path in Docs.jl like this

@@ -627,7 +630,7 @@ isquotedmacrocall(x) =
     isexpr(x.args[1].value, :macrocall, 1)
 # Simple expressions / atoms the may be documented.
 isbasicdoc(x) = isexpr(x, :.) || isa(x, Union{QuoteNode, Symbol})
-is_signature(x) = isexpr(x, :call) || (isexpr(x, :(::), 2) && isexpr(x.args[1], :call))
+is_signature(x) = isexpr(x, :call) || (isexpr(x, :(::), 2) && isexpr(x.args[1], :call)) || isexpr(x, :where)

 function docm(meta, ex, define = true)
     # Some documented expressions may be decorated with macro calls which obscure the actual

bootstrapping fails

docs/Docs.jl
error during bootstrap:
LoadError(at "sysimg.jl" line 382: UndefVarError(var=:T))
rec_backtrace at /Users/helge/projects/julia/dev/src/stackwalk.c:84
record_backtrace at /Users/helge/projects/julia/dev/src/task.c:239 [inlined]
jl_throw at /Users/helge/projects/julia/dev/src/task.c:565
jl_undefined_var_error at /Users/helge/projects/julia/dev/src/rtutils.c:129
eval at /Users/helge/projects/julia/dev/src/interpreter.c:221
do_call at /Users/helge/projects/julia/dev/src/interpreter.c:74
eval at /Users/helge/projects/julia/dev/src/interpreter.c:230
do_call at /Users/helge/projects/julia/dev/src/interpreter.c:74
eval at /Users/helge/projects/julia/dev/src/interpreter.c:230
do_call at /Users/helge/projects/julia/dev/src/interpreter.c:74
eval at /Users/helge/projects/julia/dev/src/interpreter.c:230
do_call at /Users/helge/projects/julia/dev/src/interpreter.c:74
eval at /Users/helge/projects/julia/dev/src/interpreter.c:230
eval_body at /Users/helge/projects/julia/dev/src/interpreter.c:534
jl_interpret_toplevel_thunk at /Users/helge/projects/julia/dev/src/interpreter.c:679
jl_toplevel_eval_flex at /Users/helge/projects/julia/dev/src/toplevel.c:592
jl_toplevel_eval_in at /Users/helge/projects/julia/dev/src/builtins.c:484
eval at ./boot.jl:235
unknown function (ip: 0x31a528417)
loaddocs at ./docs/Docs.jl:741
unknown function (ip: 0x31a526663)
do_call at /Users/helge/projects/julia/dev/src/interpreter.c:75
eval at /Users/helge/projects/julia/dev/src/interpreter.c:230
eval_body at /Users/helge/projects/julia/dev/src/interpreter.c:530
jl_toplevel_eval_body at /Users/helge/projects/julia/dev/src/interpreter.c:502
jl_toplevel_eval_flex at /Users/helge/projects/julia/dev/src/toplevel.c:571
jl_eval_module_expr at /Users/helge/projects/julia/dev/src/toplevel.c:203
jl_toplevel_eval_flex at /Users/helge/projects/julia/dev/src/toplevel.c:480
jl_parse_eval_all at /Users/helge/projects/julia/dev/src/ast.c:873
jl_load at /Users/helge/projects/julia/dev/src/toplevel.c:616
exec_program at /Users/helge/projects/julia/dev/usr/bin/julia (unknown line)
true_main at /Users/helge/projects/julia/dev/usr/bin/julia (unknown line)
main at /Users/helge/projects/julia/dev/usr/bin/julia (unknown line)

I also do not quite understand why the doc system uses unions of tuples to represent signatures. Union{} is used as a sentinel value for an empty signature which lead to my original issue and does not play well with the new type system. Representing signatures as tuples of tuples works as well and makes more sense IMHO. Any downsides to this?