test: document module name shadowing between stanza and library (#4572)#14031
Conversation
|
@rgrinberg This PR is in response to your leading question on PR #14021 about shadowing. |
2fba4cc to
8ddbad3
Compare
There was a problem hiding this comment.
Pull request overview
This PR adds a new blackbox test suite under per-module-lib-deps/ to document current (coarse) recompilation behavior in Dune’s dependency analysis, plus a focused test documenting module-name shadowing between stanza-internal modules and unwrapped library modules (relevant to ocamldep-based filtering for #4572).
Changes:
- Add baseline tests showing that changes in a dependency (direct, transitive, virtual, wrapped/unwrapped, wrapped-compat) currently trigger broader recompilation than “per-module” would imply.
- Add a test that demonstrates stanza-internal module name shadowing takes precedence over an unwrapped library module of the same name.
- Add an opaque-mode test capturing the difference between release (opaque=false) and dev (opaque=true) recompilation behavior for implementation-only changes.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| test/blackbox-tests/test-cases/per-module-lib-deps/basic-wrapped.t | Baseline for wrapped library interface-change causing recompilation of unrelated executable modules. |
| test/blackbox-tests/test-cases/per-module-lib-deps/lib-to-lib-unwrapped.t | Baseline for coarse recompilation when an unwrapped library depends on an unwrapped multi-module library. |
| test/blackbox-tests/test-cases/per-module-lib-deps/lib-to-lib-wrapped.t | Baseline for coarse recompilation in a wrapped library-to-library dependency. |
| test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t | Documents module name shadowing behavior between an executable’s internal module and an unwrapped library module. |
| test/blackbox-tests/test-cases/per-module-lib-deps/multiple-libraries.t | Baseline for coarse recompilation when an executable depends on multiple libraries and only one changes. |
| test/blackbox-tests/test-cases/per-module-lib-deps/opaque.t | Captures opaque-mode impact on recompilation for implementation-only changes (release vs dev profile). |
| test/blackbox-tests/test-cases/per-module-lib-deps/transitive.t | Baseline for recompilation driven by transitive dependency changes even for independent modules. |
| test/blackbox-tests/test-cases/per-module-lib-deps/unwrapped.t | Baseline for coarse recompilation when a single module in an unwrapped library changes. |
| test/blackbox-tests/test-cases/per-module-lib-deps/virtual-library.t | Baseline for recompilation behavior when a virtual library’s interface changes. |
| test/blackbox-tests/test-cases/per-module-lib-deps/wrapped-compat.t | Baseline for recompilation behavior involving wrapped-compat modules from (wrapped (transition ...)). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t
Outdated
Show resolved
Hide resolved
|
The |
Okay, makes sense. Thanks for helping! |
7a7293a to
386b933
Compare
test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t
Show resolved
Hide resolved
e6a4358 to
673f6db
Compare
test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t
Outdated
Show resolved
Hide resolved
test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t
Outdated
Show resolved
Hide resolved
3f4a328 to
3d1f5ad
Compare
|
@Leonidas-from-XIV Addressed your concerns. Please have a look. |
Leonidas-from-XIV
left a comment
There was a problem hiding this comment.
I have one more concern that I probably missed in the last review.
test/blackbox-tests/test-cases/per-module-lib-deps/module-name-shadowing.t
Outdated
Show resolved
Hide resolved
When an internal module name shadows an unwrapped library's module name, the internal module takes precedence and the library's module is inaccessible. This means ocamldep will report the internal module, not the library's, so dependency filtering that treats stanza-internal names as non-library references is correct. Signed-off-by: Robin Bate Boerop <me@robinbb.com>
3d1f5ad to
aae05cd
Compare
|
@Leonidas-from-XIV Thanks for your review. Much appreciated. I have addressed your concerns. Care to review again (and merge if merited)? |
Add a test documenting module name shadowing behavior between a stanza's
internal modules and an unwrapped library dependency.
When an executable has a module
Helperand also depends on an unwrappedlibrary that exposes a module
Helper, the internal module takes precedence:the build succeeds using the internal module, and the library's
Helperisinaccessible (
Unbound value).This behavior is relevant to #4572 (finer dependency analysis between
libraries), where
ocamldepoutput is used to determine which libraries amodule references. Since the compiler resolves shadowed names to the internal
module,
ocamldepreports the internal name — filtering it out asstanza-internal (rather than treating it as a library reference) is correct.
Ref: #4572