Avoid needless dependency on parameter .cmi by introducing Parameter_name.t
#3708
+411
−416
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.
Based on #3172, though a bit more narrow to focus on just putting the new type in all the places.
The new type
Global_module.Parameter_name.t
takes the place of anyGlobal_module.t
orGlobal_module.Name.t
that is known to be the name of a parameter. Can't have parameters. (Notably, even the current half-worked-out plans for parameterized parameters would actually keep this type in many places, so this isn't as much in the way as one might think.)Concretely, the immediate benefit is that we no longer load the .cmi file of a parameter just because it's used in the name of an instance. (All that we actually need to check in
Foo[Bar:Baz]
is (a) thatFoo
expects aBar
, (b) thatBaz
implementsBar
, and (c) thatFoo
andBaz
agree on whatBar
says, none of which requires loadingbar.cmi
.) This is tested in the Dune-like tests by removing-I
flags that shouldn't be necessary.