odoc html-targets is inacurate

[dbuenzli]

(Using odoc master and my PRs)

There are two problems:

1. It reports files it won't write. As far as I can tell these are modules that are hidden by stop comments ((**/**)). This happens for example on uucp, see for example Tmap* below. These are exactly the modules that are between these stop comments.

2. It fails to report some of the files it writes. It seems that written sub-sub modules are not reported. See for example Nfkc_fold below.

Here's are easy steps to reproduce:

opam install uucp
odoc compile --package uucp -o /tmp/uucp.odoc $(opam var uucp:lib)/uucp.cmti 
odoc html-targets -o /tmp/doc /tmp/uucp.odoc | sort > /tmp/uucp.html.targets
odoc html -o /tmp/doc /tmp/uucp.odoc
find /tmp/doc -name '*.html' | sort | diff -u /tmp/uucp.html.targets -
--- /tmp/uucp.html.targets	2019-01-14 21:18:51.000000000 +0100
+++ -	2019-01-14 21:21:08.000000000 +0100
@@ -1,10 +1,13 @@
 /tmp/doc/uucp/Uucp/Age/index.html
 /tmp/doc/uucp/Uucp/Alpha/index.html
 /tmp/doc/uucp/Uucp/Block/index.html
+/tmp/doc/uucp/Uucp/Break/Low/index.html
 /tmp/doc/uucp/Uucp/Break/index.html
+/tmp/doc/uucp/Uucp/Case/Fold/index.html
+/tmp/doc/uucp/Uucp/Case/Map/index.html
+/tmp/doc/uucp/Uucp/Case/Nfkc_fold/index.html
 /tmp/doc/uucp/Uucp/Case/index.html
 /tmp/doc/uucp/Uucp/Cjk/index.html
-/tmp/doc/uucp/Uucp/Cmap/index.html
 /tmp/doc/uucp/Uucp/Func/index.html
 /tmp/doc/uucp/Uucp/Gc/index.html
 /tmp/doc/uucp/Uucp/Gen/index.html
@@ -12,11 +15,6 @@
 /tmp/doc/uucp/Uucp/Id/index.html
 /tmp/doc/uucp/Uucp/Name/index.html
 /tmp/doc/uucp/Uucp/Num/index.html
-/tmp/doc/uucp/Uucp/Rmap/index.html
 /tmp/doc/uucp/Uucp/Script/index.html
-/tmp/doc/uucp/Uucp/Tmap/index.html
-/tmp/doc/uucp/Uucp/Tmap4bytes/index.html
-/tmp/doc/uucp/Uucp/Tmapbool/index.html
-/tmp/doc/uucp/Uucp/Tmapbyte/index.html
 /tmp/doc/uucp/Uucp/White/index.html
 /tmp/doc/uucp/Uucp/index.html

[dbuenzli]

2. It fails to report some of the files it writes. It seems that written sub-sub modules are not reported. See for example Nfkc_fold below.

Does anyone have a hint at what it would need to solve this ? It's a problem for odig's caching mecanism since it doesn't allow it to capture the exact set of files that need to be regenerated in subsequent odoc runs.