Add tests with API "re-exports" #53
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When designing a lib, one may want to explictly expose some submodules as part of its API. While doing so, some parts of these submodules may remain hidden from the API but exposed by the submodules for internal use. Reporting on values in a library API and submodules must remain actionable. Therefore, the semantic is: - For a value defined in the submodule, account for all the uses internal to the library but the ones in the submodule itself (unless there is no interface or the `--internal` option is used, as usual). Among those uses, re-expositions count. I.e. if the value is exposed by the API, then this counts as a use because it is required. - For a submodule's value exposed in the API, account for all the uses external to the library. Uses of an API value may be propagated to the submodule's value. This is currently the case e.g. in the threshold-3-0.5 test scenario which expects `./examples/using_dune/reduced_lib/values.mli:1: used` in the exported values used 3 times. It is used inside `Value`, by requirement for `Reduced_lib.Values` API and outside the library transitively by the use of `Reduced_lib.Values.used` in `examples/using_dune/reduced_lib/values.ml`. Hence, a submodule's value explicitly exposed in the API cannot be reported as unused while the API's value may be. This is coherent with the general value reporting semantic.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When designing a lib, one may want to explictly expose some submodules as part of its API. While doing so, some parts of these submodules may remain hidden from the API but exposed by the submodules for internal use.
Reporting on values in a library API and submodules must remain actionable. Therefore, the semantic is:
--internaloption is used, as usual). Among those uses, re-expositions count. I.e. if the value is exposed by the API, then this counts as a use because it is required.Uses of an API value may be propagated to the submodule's value. This is currently the case e.g. in the threshold-3-0.5 test scenario which expects
./examples/using_dune/reduced_lib/values.mli:1: usedin the exported values used 3 times. It is used insideValue, by requirement forReduced_lib.ValuesAPI and outside the library transitively by the use ofReduced_lib.Values.usedinexamples/using_dune/reduced_lib/values.ml.Hence, a submodule's value explicitly exposed in the API cannot be reported as unused while the API's value may be.
This is coherent with the general value reporting semantic.