-
Notifications
You must be signed in to change notification settings - Fork 104
Use Unit_info.t
more like upstream
#3926
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use Unit_info.t
more like upstream
#3926
Conversation
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.
Someone else should check alignment with upstream. |
@voodoos You’re probably best poised to check about upstream alignment — do you think this achieves that goal? |
…d-kind-in-unit-info
I don't understand why there is a constraint with upstream alignment. |
No constraint. But my understanding is that the goal of this PR is to increase upstream alignment, and so we may want to check that we've done so. If we can't do that today, then I think we can skip that step. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this does improve alignment with upstream and more importantly it reconciles the parallel evolution of Compilation_unit.t
and Unit_info.t
.
Cleans up some of the awkwardness around
Compilation_unit.t
andUnit_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:
kind
field toUnit_info.t
to track whether the unit is an interface or implementation (aiming toward pulling in [tooling] Distinct uids for interfaces ocaml/ocaml#13286)Compilation_unit.t
in place ofmodname
inUnit_info.t
(see this comment for rationale and alternatives)Unit_info.t
rather than aCompilation_unit.t
, with theEnv
andShape
APIs changing accordingly (again this helps with [tooling] Distinct uids for interfaces ocaml/ocaml#13286).Meant to be reviewed commit by commit.