Skip to content

Conversation

@fantazio
Copy link
Collaborator

@fantazio fantazio commented Jan 26, 2026

It is not uncommon to use a .ml (without .mli) to expose module types and include these in other module's .mli. A minimal example of this pattern is reproduced in examples/using_dune/lib/values/include_modtype. An "internal" version of this pattern, with a single module defining and including a module type, is also added to the tests.

A more complex pattern, found in Frama-C, is reproduced in examples/using_dune/lib/values/builder_sig_api. This is an extension of the above, with intermediate functors.

The FP and FN introduced are tracked by #50. Expected reports reflect "the easy way" described in #50.

The new pattern was observed on Frama-C. It is described in
`examples/using_dune/lib/values/builder_sig_api/README.md`.
It uses a mix of module types, functors and includes dispatched in
multiple files.

It is not uncommon to use a `.ml` (without `.mli`) to expose module
types and reuse these in other module's `.mli`. This pattern will need
to be tested more specifically.

The current report semantic for the values in module types is to not
report them.
It is not uncommon to use a `.ml` (without `.mli`) to expose module
types and include these in other module's `.mli`.
The new tests specifically target this pattern with a toplevel `include`

The current report semantic for the values in module types is to not
report them.
Instead of including a modtype from an external module in the signature,
the same module both defines and includes a modtype in its signature.

The current report semantic for the values in module types is to not
report them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant