Comment author: @xavierleroy

I think this is a duplicate of #5870. At any rate, this is a known, long-standing, infamous limitation of ocamldep, and after two decades it is still unclear how to overcome it.

Comment author: @gasche

If I understand correctly, the bug could be fixed as follows: when opening a non-local module, we should forget about the previously known submodule structures, given that any previous module may have been overriden by the unknown open. The code of parsing/depend.ml currently reads:

let open_module bv lid =
match lookup_map lid bv with
| Node (s, m) ->
add_names s;
StringMap.fold StringMap.add m bv
| exception Not_found ->
add_path bv lid; bv

If I am not mistaken, this would correspond to turning the last line into something like:

| exception Not_found ->
add_path bv lid;
(* #7470: forget about known submodules
as this "open" may override them *)
StringMap.empty

Unfortunately, there is a risk of this change significantly worsening the precision of dependency computation, and thus introducing more faulty cycles if people have submodules of the name of a compilation unit.

Comment author: @Octachron

I would argue that this problem is quite different than #5870, since in this case, ocamldep fails to compute an over-approximation of dependencies.

@gasche: It is possible to be a little more precise by forgetting not the current submodules but the submodule structure of the current submodules, i.e in the previous example, the problem appears when the signature of M is inferred to be sig module N:sig end end whereas there is no way to know the signature of the module that was really opened.

But even in this case, fixing this problem may worsen the precision of dependency computation for non-pathological situations.

Comment author: @gasche

Good point.

This is a case where testing on all OPAM packages would be interesting. It's not clear that anyone will bother actually implementing a patch to experiment with that.

Comment author: @xavierleroy

See also https://github.com/Octachron/codept

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.