Skip to content

Fix docstring search by signatures revisited #54324

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.

Sign up for GitHub

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

Fix docstring search by signatures revisited #54324

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
fdaf7a7
fixed bug in `Base.Docs.signature!`
matthias314 Mar 22, 2024
5ec358a
fixed signatures in doc files
matthias314 Mar 23, 2024
9e0bb67
Recognize parametric types
projekter Apr 6, 2024
02651c0
Fix documentation issues (remaining error is due to a necessary fix i…
projekter May 8, 2024
53079ae
Merge branch 'master' into m3/docs-signature
fingolfin Oct 22, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 8 additions & 6 deletions base/docs/Docs.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,24 +98,26 @@ function initmeta(m::Module)
return invokelatest(getglobal, m, META)
end

struct TypeParams{T<:Tuple} end

function signature!(tv::Vector{Any}, expr::Expr)
is_macrocall = isexpr(expr, :macrocall)
if is_macrocall || isexpr(expr, :call)
sig = :(Union{Tuple{}})
first_arg = is_macrocall ? 3 : 2 # skip function arguments
if isexpr(expr.args[1], :curly)
push!((sig.args[end]::Expr).args, :($TypeParams{Tuple{$((expr.args[1]::Expr).args[2:end]...)}}))
if isempty(tv)
append!(tv, mapany(tvar, (expr.args[1]::Expr).args[2:end]))
end
end
for arg in expr.args[first_arg:end]
isexpr(arg, :parameters) && continue
if isexpr(arg, :kw) # optional arg
push!(sig.args, :(Tuple{$((sig.args[end]::Expr).args[2:end]...)}))
end
push!((sig.args[end]::Expr).args, argtype(arg))
end
if isexpr(expr.args[1], :curly) && isempty(tv)
append!(tv, mapany(tvar, (expr.args[1]::Expr).args[2:end]))
end
for i = length(tv):-1:1
push!(sig.args, :(Tuple{$((tv[i]::Expr).args[1])}))
end
for i = length(tv):-1:1
sig = Expr(:where, sig, tv[i])
end
Expand Down
12 changes: 4 additions & 8 deletions base/docs/basedocs.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3579,18 +3579,14 @@ Tuple

"""
NamedTuple{names}(args::Tuple)

Construct a named tuple with the given `names` (a tuple of Symbols) from a tuple of values.
"""
NamedTuple{names}(args::Tuple)

"""
NamedTuple{names,T}(args::Tuple)

Construct a named tuple with the given `names` (a tuple of Symbols) and field types `T`
In the first form, construct a named tuple with the given `names` (a tuple of Symbols) from a tuple of values.
In the second form, construct a named tuple with the given `names` (a tuple of Symbols) and field types `T`
(a `Tuple` type) from a tuple of values.
"""
NamedTuple{names,T}(args::Tuple)
NamedTuple{names}(args::Tuple)
# NamedTuple{names,T}(args::Tuple) # redundant because of the same signature
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this, PR, ?NamedTuple{names,T}, ?NamedTuple{names} and ``?NamedTuple` all give the same output, which includes four docstrings,

  NamedTuple(itr)

  NamedTuple{names}(nt::NamedTuple)

  NamedTuple{names}(args::Tuple)
  NamedTuple{names,T}(args::Tuple)

  NamedTuple

Is that intended?


"""
NamedTuple{names}(nt::NamedTuple)
Expand Down
18 changes: 9 additions & 9 deletions doc/src/base/arrays.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,19 +8,19 @@ Base.AbstractVector
Base.AbstractMatrix
Base.AbstractVecOrMat
Core.Array
Core.Array(::UndefInitializer, ::Any)
Core.Array(::Nothing, ::Any)
Core.Array(::Missing, ::Any)
Core.Array{T,N}(::UndefInitializer, ::Any)
Core.Array{T,N}(::Nothing, ::Any)
Core.Array{T,N}(::Missing, ::Any)
Core.UndefInitializer
Core.undef
Base.Vector
Base.Vector(::UndefInitializer, ::Any)
Base.Vector(::Nothing, ::Any)
Base.Vector(::Missing, ::Any)
Base.Vector{T}(::UndefInitializer, ::Any)
Base.Vector{T}(::Nothing, ::Any)
Base.Vector{T}(::Missing, ::Any)
Base.Matrix
Base.Matrix(::UndefInitializer, ::Any, ::Any)
Base.Matrix(::Nothing, ::Any, ::Any)
Base.Matrix(::Missing, ::Any, ::Any)
Base.Matrix{T}(::UndefInitializer, ::Any, ::Any)
Base.Matrix{T}(::Nothing, ::Any, ::Any)
Base.Matrix{T}(::Missing, ::Any, ::Any)
Base.VecOrMat
Core.DenseArray
Base.DenseVector
Expand Down
4 changes: 2 additions & 2 deletions doc/src/base/c.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,11 +13,11 @@ Base.unsafe_store!
Base.unsafe_modify!
Base.unsafe_replace!
Base.unsafe_swap!
Base.unsafe_copyto!{T}(::Ptr{T}, ::Ptr{T}, ::Any)
Base.unsafe_copyto!(::Ptr{T}, ::Ptr{T}, ::Any) where T
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes seem reasonable/good/bugfixes, but I'm worried how breaking they might be to docsystem building across the ecosystem.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to figure this out? From some JuliaCon talks for example I get the impression that it is possible to test many or all packages with a modified Julia version and see what happens. If the documentation of a package would require changes, then this would result in an error during precompilation or when building the docs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is nanosoldier, but that only runs testsuites which often do not include building docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Base, most changes occur in docstrings (as opposed to separate documentation files), and a missing change gives an error during precompilation. So with nanosoldier we might still get an idea of how big the problem really is.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would also have thought that this issue should be detected by Nanosoldier.
The only way to circumvent this possible incompatibility is if we decide to formally allow this syntax for functions. (But then, it should be documented somewhere.)
Then, it should also formally be defined show this syntax is interpreted. If we just say that in the documentation, fun{X}(args) is exactly equivalent to fun(args) where {X}, then it is clear that everything in X is a type variable (with possible subtyping). Apart from the case in which fun is the name of a type/constructor, as then it could also be a concrete type (or some other bitstype). I previously thought that it is not easily possible for the macro-called function determining which is the case, but as I now think of it, I'm no longer so sure. For outer constructors, for sure when the macro is called, the type must already exist. And in order for the Julia compiler to accept fun{X} without X being in the where clause, X must also be well defined (in the context of the calling module, which is available to the macro). I don't know how it is when the docstring is attached to an inner constructor, though.
Then, in the specification of what fun{X}(args) means when fun is a constructor, should we allow mixing actual generic types (coming first?) with parametric types from the arguments (pretty clumsy IMHO)? Or just disallow this shorthand notation?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also concerned about breakage in the ecosystem, on the other hand, there is a also real bug here that keep coming up again and again, and surely we must be able to deal with it somehow?

What are the possible failure modes here? I am a bit confused by the discussion here. Which of these can occur here:

  1. The changes here could lead to makedocs invocations that previously worked now erroring out?
    • I think we could live with that; package authors would be annoyed, but if we give a clear guidance about this change and how to deal with it in the release notes, and why it was necessary, it seems acceptable.
  2. The changes here could lead to Julia code not (pre)compiling anymore?
    • Similar conclusion as in 1, but we can at least get a rough idea about it via NanoSoldier
  3. The changes here could lead to silent breakage, e.g. manuals suddenly don't include certain docstrings
    • that's the annoying kind, it could even lead to projects making several release with broken documentation without realizing.

Any other relevant failure modes I am forgetting here?

Copy link
Member

@fingolfin fingolfin Oct 22, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In Base, most changes occur in docstrings (as opposed to separate documentation files), and a missing change gives an error during precompilation.

This line confuses me: looking at this PR, it's the other way around: most changes here are in the .md files, and one is in a docstring. What gives?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been a while, but here's what I think I remember:

  • The issue is that in the current implementation, generic methods are not identified properly.
  • Therefore it is not always possible to refer to them uniquely. So if you currently want to include a specific method in the documentation (which would be a @docs block) or you want to [...](@ref something(concrete)) a particular method, this might not always work out.
  • By changing how the methods are identified, we fix this problem. However, as a consequence, now Documenter will only understand references that use proper syntax as Julia does and will reject things that would not compile in the normal code.
  • So what will break: Explicit references to methods in a @docs block that used wrong syntax and links within docstrings. I don't think that this will lead to an error in precompilation: The markdown files are irrelevant for precompilation anyways, they are "external" documentation. And if you have links within docstrings, well, they are just strings until you actually want to generate some hypertext out of it. So the links may be broken in the documentation, which might give a warning or an error depending on your makedocs configuration, but it should not affect precompilation, same for markdown.
  • What it will also break: If you explicitly use the Docs module to find the documentation based on a method type signature which uses the previously-used Union structure. Which should be pretty rare. Why would you ever care to programmatically get the docstring of a particular method? Probably only if you want to copy this docstring for another method (which is how I arrived at this bug, as far as I remember). And if you used the previous internal representation, I'm pretty sure that this was an implementation detail and therefore can change without notice. And REPL of course also uses the Docs system, since I have no idea how REPL internally does this, maybe it needs some adjustments.

So indeed, I also don't understand @matthias314's statement about the changes in docstrings in Base.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to admit that don't understand that comment myself anymore!

Regarding breakages: If I understand correctly, @projekter would also prefer to disallow type parameters that are not explicitly specified. I think it would be instructive to see how many packages would break if we did this. We could either take this temporarily out of this PR or by use my original PR and then run nanosoldier.

Base.unsafe_copyto!(::Array, ::Any, ::Array, ::Any, ::Any)
Base.copyto!
Base.pointer
Base.unsafe_wrap{T,N}(::Union{Type{Array},Type{Array{T}},Type{Array{T,N}}}, ::Ptr{T}, ::NTuple{N,Int})
Base.unsafe_wrap(::Union{Type{Array},Type{Array{T}},Type{Array{T,N}}}, ::Ptr{T}, ::NTuple{N,Int}) where {T,N}
Base.pointer_from_objref
Base.unsafe_pointer_to_objref
Base.disable_sigint
Expand Down
2 changes: 1 addition & 1 deletion doc/src/base/parallel.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ Base.Lockable
```@docs
Base.AbstractChannel
Base.Channel
Base.Channel(::Function)
Base.Channel{T}(::Function)
Base.put!(::Channel, ::Any)
Base.take!(::Channel)
Base.isfull(::Channel)
Expand Down
4 changes: 2 additions & 2 deletions test/docs.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -741,7 +741,7 @@ Base.collect(::Type{EmptyType{T}}) where {T} = "borked"
end

let fd = meta(I12515)[@var(Base.collect)]
@test fd.order[1] == (Union{Tuple{Type{I12515.EmptyType{T}}}, Tuple{T}} where T)
@test fd.order[1] == (Tuple{Type{I12515.EmptyType{T}}} where T)
end

# PR #12593
Expand Down Expand Up @@ -1415,7 +1415,7 @@ end

end

@test docstrings_equal(
@test_broken docstrings_equal(
@doc(I21016.Struct),
doc"""
String 1
Expand Down
Loading