Missing dependency for alias to sub-path

[art-w]

I believe codept's -no-alias-deps is slightly too generous for module aliases on sub-paths:

module Lib_x = Lib.X

This doesn't report a dependency on Lib, but I believe the compiler requires it? (to check that X exists in Lib, where lib.ml is e.g. module X = struct end)

Another example in codept itself:

codept/lib/deps.ml

Line 46 in 68ff962

module Pth = Paths.S

codept/tests/run.ml

Line 615 in 68ff962

"deps.ml", (["Name"; "Namespaced"; "Option"; "Pkg"; "Pp"; "Schematic"],["List"],[]);

[Octachron]

You are mostly right indeed: there is a small subtlety that there is split between the type dependencies and value dependencies where Lib.X introduces a dependencies other the Lib cmi, but it does not create a dependency over the corresponding cmo/x.

[art-w]

Ha indeed the dependency is only on lib.cmi here, that's neat! Is there a way to use codept to report the distinction? (note that atm I'm only interested in knowing that "Lib is a dependency" because otherwise compilation is failing to find Lib, the cmi-vs-cmo dependency analysis would be a nice bonus for release builds but it's a secondary concern)

[Octachron]

I am planning to fix in two part: first add the dependency, then retrofits the Epsilon dependency edge type to a Type_only edge since it already tracks type-level dependencies for a different reason. (This edge type was supposedly here to track the dependencies transitively necessary in the typing environment before the introduction of the -H flag.)

[Octachron]

This is should also be fixed in the next release: codept now consider that solving an aliasing forces a lookup on the alias prefix.