test: cross-library .cmi baseline for dotted -open path

[robinbb]

Summary

A fifth sibling to the cross-library .cmi regression baselines from #14584, covering an intermediate library compiled with (flags (-open Prelude.Color)) — a dotted module path naming a submodule of a wrapped dependency, rather than a bare top-level module.

The fixture asserts build success under --sandbox=copy. It builds on main today (no per-module narrowing) and pins behaviour that the per-module narrowing work in #14492 must preserve: the effective--open detection has to key on the head component of the path (Prelude from Prelude.Color), since only top-level module names map to libraries. Without that, the dotted open is dropped from the cross-library frontier and the sandboxed build regresses.

Test-only; no changelog.

[Copilot]

Pull request overview

Adds a new blackbox regression fixture to the per-module-lib-deps test suite to pin cross-library .cmi dependency behavior when an intermediate library is compiled with a dotted -open module path (Prelude.Color). This specifically safeguards the per-module dependency narrowing work by ensuring Dune attributes -open Prelude.Color to the dependency library keyed by the head component (Prelude).

Changes:

• Add a new cross-library .cmi baseline fixture covering (flags (:standard -open Prelude.Color)) in an intermediate library.
• Assert the build succeeds under --sandbox=copy for a consumer whose compilation implicitly requires the dependency library’s .cmis via the -open effect.

[Alizter]

Here is another complication that OCaml gives us:

-open Prelude -open Color

Is also the same as:

-open Prelude.Color

but this means that args to -open cannot be assumed to be compilation units. IIUC this is being done in L5.

[robinbb]

You're right that -open arguments are longidents resolved against the accumulating open scope, not compilation units — -open Prelude -open Color makes Color mean Prelude.Color, so the second argument names a submodule. (They aren't quite the same as -open Prelude.Color, since the sequential form also opens Prelude's top level, but that doesn't change the point.)

The detection doesn't rely on the arguments being compilation units, though — it's a conservative over-approximation of which libraries an -open can make referenceable, not a precise resolver, and it stays sound under your example. The root of any -open chain is a compilation unit (or a default-scope module like Stdlib), and that root's head maps to its library, so the library gets reached; a submodule argument's contents live in that same library (or are a re-export, which the wrapped/re-export recoveries already cover). A bare argument that isn't a unit (Color) is added to the BFS frontier and then either maps to no library (a no-op) or collides with an unrelated same-named library (over-conservative — it keeps an extra .cmi, it never drops a needed one). Neither case under-tracks.

For your exact example: -open Prelude reaches lib prelude, which covers Color's contents, so it's sound — I confirmed -open Prelude -open Color builds under --sandbox=copy. This is also independent of the dotted-path handling, which only rewrites dotted arguments (Foo.Bar → head Foo); a bare -open Color is added as Color either way.

(Small pointer: extract_open_module_names is actually introduced and first used in #14516 — seeding the initial BFS frontier — rather than in L5; L5 only adds the dep-lib stanza -open call site.)

[Alizter]

Thanks for the explanation.

[robinbb]

@Alizter I'll add some testing for that, here, too.