Use Unit_info.t more like upstream
#3926
Open
+249
−149
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
This requires knowing the pack prefix wherever a `Unit_info.t` is created, but generally we're creating a `Compilation_unit.t` and a `Unit_info.t` at the same time so the caller already knows the pack prefix.
This makes downstream and upstream much better aligned, since upstream uses `Unit_info.t` in this way. (Some of the changes here are just copied from upstream, in fact.) There's a bit of awkwardness in that we often need to use dummy unit info because (unlike upstream) our typechecker can't run without a current `Compilation_unit.t` set.
voodoos
reviewed
Apr 24, 2025
Comment on lines
+521
to
+522
| val set_unit_name: Unit_info.t option -> unit | ||
| val get_unit_name: unit -> Unit_info.t option |
There was a problem hiding this comment.
Is there a reason here why you don't stick closer to the upstream signature ?
Having a specialized get_unit_name that returns the Compilation_unit.t directly might reduce the diff a bit?
Upstream signature is:
(* Remember the current compilation unit. *)
val set_current_unit: Unit_info.t -> unit
val get_current_unit : unit -> Unit_info.t option
val get_current_unit_name: unit -> string (* Compilation_unit.t *)There was a problem hiding this comment.
It would've rippled out a bit more than I wanted—this is really just aiming to get the right information in the right places. There's at least one place that calls set_current_unit with the previous value of get_current_unit (), though, so something would have to change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Cleans up some of the awkwardness around
Compilation_unit.tandUnit_info.t, the later of which was recently introduced upstream. This PR is meant to take on a slice of what #3828 is doing (and as such it's admittedly a little scattered).Specifically:
kindfield toUnit_info.tto track whether the unit is an interface or implementation (aiming toward pulling in [tooling] Distinct uids for interfaces ocaml/ocaml#13286)Compilation_unit.tin place ofmodnameinUnit_info.t(see this comment for rationale and alternatives)Unit_info.trather than aCompilation_unit.t, with theEnvandShapeAPIs changing accordingly (again this helps with [tooling] Distinct uids for interfaces ocaml/ocaml#13286).Meant to be reviewed commit by commit.