Skip to content

Conversation

@fantazio
Copy link
Collaborator

This is an initial work for #18, which clearly states the issue.

The new wrapped_lib shares the same code as unwrapped_lib by having both symlink to the same source directories located in lib. The only relevant difference between the 2 is the (wrapped <boolean>) field in their dune files.
The use_* files in bin are moved to the bin/use_unwrapped_lib directory. The new bin/use_wrapped_lib directory is a copy of the unwrapped version, with an extra module indirection (Wrapped_lib) to access elements in the lib's modules.

The expected reports for unwrapped_lib and wrapped_lib and their bin/use_*_lib companion are identical. In the future, new examples should be added in a subdir of lib, symlinked in both unwrapped_lib and wrapped_lib. Consequently, the "copy" property of their reports should hold. Similarly, an update in bin/use_*_lib is expected to be replicated in the other, and the property would hold for their reports too.

The updated .ref files show that dune's wrapping is not an issue for the tracking of optional arguments and stylistic issues. It is only an issue for the default reports.

@fantazio fantazio force-pushed the wrapped branch 2 times, most recently from d31467a to 07c98a6 Compare November 27, 2025 22:29
This is in preparation of adding a `wrapped_lib` that will follow the
same architecture and usage as `unwrapped_lib`. Having both mixed
together in `bin/` would be too noisy. Hence, creating a
`bin/use_unwrapped_lib` subdir will isolate their use. Later, a
`bin/use_wrapped_lib` will do as well.
This is in anticipation of the upcoming `wrapped_lib` directory that
would contain the same code as `wrapped_lib` with a different `dune`.
To avoid a large copy of all the code, they would both contain symlinks
to the `lib`'s subdirs (which actually contain the code).
It was referencing a value from `Values` instead of `Values_no_intf`.
This value is not included in the results because it is used too often
to be reported with the tested thresholds.
`wrapped_lib` is a copy `unwrapped_lib` with a change in the `dune`
fields: `(wrapped true)` (instead of `false`).
The `use_wrapped_lib` is also a copy of `use_unwrapped_lib` with an
extra module indirection to access elements in each `.ml` file.

The `.exp` files have been updated by copying the expected reports for
the `unwrapped_lib` to define expected reports for the `wrapped_lib`.
In the future, new examples should be added in a subdir of `lib`,
symlinked in both `unwrapped_lib` and `wrapped_lib`. Consequently,
the "copy" property of their reports should hold.

The new `.ref` files show that dune's wrapping of module is not an issue
for the tracking of optional arguments and stylistic issues. It is only
an issue for the default reports.
@fantazio
Copy link
Collaborator Author

fantazio commented Dec 2, 2025

If that's OK with LexiFi, in order to maintain the project's momentum, I'll merge non-critical PRs (tests, doc, ...) after 1 week if they don't get any review, and more involved ones (features, improvements, ...) after 10-14 days. Critical changes (breaking change, version update, ...) will still expect a review.

@nojb
Copy link
Contributor

nojb commented Dec 2, 2025

Sounds good @fantazio. At this point you are the main driving force behind this project, and we appreciate that! Thanks!

@nojb
Copy link
Contributor

nojb commented Dec 2, 2025

(Incidentally, we have some users inside LexiFi who are are looking forward to using the tool, once it works on 5.3.0 :))

@fantazio fantazio merged commit 4062356 into LexiFi:master Dec 2, 2025
5 checks passed
@fantazio
Copy link
Collaborator Author

fantazio commented Dec 2, 2025

I am aiming at OCaml 5.3 before 2026.

@fantazio
Copy link
Collaborator Author

fantazio commented Dec 16, 2025

(Incidentally, we have some users inside LexiFi who are are looking forward to using the tool, once it works on 5.3.0 :))

A preview of the OCaml 5.3 compatibility is available here #38. There is still some work to do but feel free to play with it and comment or open issues (or sub-issues of #39). Feedback is always helpful.

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.

2 participants