top-module over-invalidates compile rule with cmi-deps from full (libraries) closure

[robinbb]

Summary

dune ocaml top-module rebuilds the top-module artefact when any library declared in the parent stanza's (libraries ...) field has its interface modified — even libraries that are referenced ONLY from .mli (and therefore dropped by top_module.ml's Module.set_source ~ml_kind:Intf None).

Reproducer

(Same setup as the baseline test in #14476.)

A library mylib with (libraries dep_for_intf dep_for_impl), where m.ml references only Dep_for_impl.value and m.mli references only Dep_for_intf.t. After dune ocaml top-module mylib/m.ml initial build, editing dep_for_intf's .mli triggers a rebuild of _build/default/.topmod/mylib/m.ml/mylib__M.cmo despite no reference from m.ml to Dep_for_intf.

Severity

Soundness is preserved (over-rebuilds, never under-rebuilds). The cost is incremental-rebuild perf in iterative dune utop / dune ocaml top-module workflows on monorepos with libraries that have many (libraries ...) deps.

[ElectreAAS]

For anyone unfamiliar with ocaml top-module, here's the relevant docs passage.

That said, how did you come across this? Do people use dune ocaml top-module? This is my first time even hearing about this command line interface.

[robinbb]

That said, how did you come across this?

I was modifying the code related to dependency management and encountered a corner case where I changed behaviour in a way that I thought should be "correct" and also "unchanged from upstream/main". However, it was only the former, but not the latter. Meaning: 'main' had this bug. So, I document it here.

[robinbb]

Do people use dune ocaml top-module?

I really don't know, myself. Maybe others can chime in.

[robinbb]

At this point, I am going to relinquish this bug, as it is low priority. I have documented what I can here and in the associated test, #14476.