What
Three docstrings in the plotting extensions cross-reference the public plotting
method by signature:
[`Plots.plot(::CTModels.Solutions.Solution)`](@extref)
ext/CTModelsPlots.jl:128 — in the Plots.plot! docstring
ext/CTModelsMakie.jl:79 — in the Makie.plot docstring
ext/CTModelsMakie.jl:100 — in the Makie.plot! docstring
None of these can resolve. Plots.plot(::CTModels.Solution) / Makie.plot(::CTModels.Solution)
are defined in weak-dependency extensions, so they are not part of any package the
InterLinks inventory indexes. The generated objects.inv (checked against the local build,
the published stable site, and the published dev site) registers only the internal
helpers — CTModelsPlots._plot / _plot!, CTModelsMakie._plot / _plot!,
CTModels.PlotCase.* — plus CTModels.Solutions.Solution jl:type. There is no Plots.plot
or Makie.plot binding in the docs to anchor to.
This is the residue of #416: that issue fixed the type path (CTModels.Solution →
CTModels.Solutions.Solution) but the Plots.plot(::…) method self-reference was never
addressed.
Where it fires
- CTModels' own docs build.
- Downstream in OptimalControl.jl's docs build, where these docstrings are transcluded via
@docs blocks onto results/plot.md, results/plot-makie.md and the generated
api/io.md — 4 of the 6 @extref errors in that build
(control-toolbox/OptimalControl.jl docs/make.jl warnonly backlog).
Suggested fix
Drop the link; keep the prose. These docstrings only say "same keyword arguments as the
other plot method", which does not need to be a hyperlink:
| file:line |
to |
ext/CTModelsPlots.jl:128 |
… keyword arguments as plot (documented above); |
ext/CTModelsMakie.jl:79 |
Same descriptionand keyword arguments as the Plots-backendplot`` |
ext/CTModelsMakie.jl:100 |
… behaviour and keyword arguments as the Plots-backend plot; an |
Leave the [CTModels.Solutions.Solution](@extref) links (CTModelsPlots.jl:84,
CTModelsMakie.jl:76) — those resolve fine.
Documentation-only; no runtime or public-API change.
What
Three docstrings in the plotting extensions cross-reference the public plotting
method by signature:
ext/CTModelsPlots.jl:128— in thePlots.plot!docstringext/CTModelsMakie.jl:79— in theMakie.plotdocstringext/CTModelsMakie.jl:100— in theMakie.plot!docstringNone of these can resolve.
Plots.plot(::CTModels.Solution)/Makie.plot(::CTModels.Solution)are defined in weak-dependency extensions, so they are not part of any package the
InterLinks inventory indexes. The generated
objects.inv(checked against the local build,the published
stablesite, and the publisheddevsite) registers only the internalhelpers —
CTModelsPlots._plot/_plot!,CTModelsMakie._plot/_plot!,CTModels.PlotCase.*— plusCTModels.Solutions.Solution jl:type. There is noPlots.plotor
Makie.plotbinding in the docs to anchor to.This is the residue of #416: that issue fixed the type path (
CTModels.Solution→CTModels.Solutions.Solution) but thePlots.plot(::…)method self-reference was neveraddressed.
Where it fires
@docsblocks ontoresults/plot.md,results/plot-makie.mdand the generatedapi/io.md— 4 of the 6@extreferrors in that build(control-toolbox/OptimalControl.jl
docs/make.jlwarnonlybacklog).Suggested fix
Drop the link; keep the prose. These docstrings only say "same keyword arguments as the
other plot method", which does not need to be a hyperlink:
ext/CTModelsPlots.jl:128… keyword arguments asplot(documented above);ext/CTModelsMakie.jl:79Samedescriptionand keyword arguments as the Plots-backendplot``ext/CTModelsMakie.jl:100… behaviour and keyword arguments as the Plots-backendplot; anLeave the
[CTModels.Solutions.Solution](@extref)links (CTModelsPlots.jl:84,CTModelsMakie.jl:76) — those resolve fine.Documentation-only; no runtime or public-API change.