Description
I was pretty sure there was an issue about this. But I can't find one. So there it is.
I think this should really be acted upon and prioritized as odoc
becomes quickly unusable when working on partial docsets1 and this problem has been here for ages.
Let's take a simple example:
> cat m.mli
(** My doc.
The max [int] value is {!Sys.max_int}. *)
This will typically report this warning:
File "lib/m.mli", line 3, characters 27-41:
Warning: Failed to resolve reference unresolvedroot(Sys).max_int Couldn't find "Sys"
I really don't have the compilation pipeline of odoc in my head right now but I suspect there is a point where we can record this symbol exists despite the fact that no documentation is going to be generated for it by simply providing an appropriate include into the stdlib's library directory or the path to the Sys.cm[i,ti]
file.
I'm pretty sure people working on odoc
have a better idea than I have of when/where in the pipeline this should be done (I vaguely remember a discussion with @trefis a few years ago where he indicated this would be possible and not too hard).
(This will not work as is stands for external references into .mld
but in my case it would, most of the time remove 100% of these warnings).
Footnotes
-
Case in point I have a medium scale project that generates 122 warnings from links into other libraries and the
Stdlib
and it is of course no longer possible to sift through that to find out if a couple of doc strings I just wrote made wrong or ambiguous links. ↩