-
Notifications
You must be signed in to change notification settings - Fork 8
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
Merge 5.2.0minus 3 #119
Merge 5.2.0minus 3 #119
Conversation
I’m very much on the back foot right now. I nominate @dkalinichenko-js to review. I know she does not have (much?) experience in merlin, but I think the nature of the changes here does not require that much experience. Diana, if there are parts that want further review, please highlight and I can take a look. Thanks! |
The |
@dkalinichenko-js yes, but imo it's best to keep it around incase we ever do a change in the future. I'll leave a comment saying something to this effect. |
@goldfirere could you look at 2d99ac1, especially the |
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.
Quick review, focusing on combine_sigs
. Some style suggestions, but all looks correct.
| Tvar { name = None; _ } | Tunivar { name = None; _ } -> Typ.any () | ||
| Tvar { name = Some s; _ } | Tunivar { name = Some s; _ } -> Typ.var s | ||
| Tvar { name = None; jkind = _ } | Tunivar { name = None; jkind = _ } -> | ||
(* CR modes: do something better here with the jkind *) |
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.
Seems easy enough to do better -- but maybe the point is that we're not sure what we want to display to users? (This doesn't need to hold up the merge.)
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'm not sure what we want to display to the user, and I'd rather print the jkind to little than too often (this is only used for construct), so I think it's best to just not include the kind for now. I also suspect this might be easier to do once ocaml-flambda/flambda-backend#3224 is merged.
This PR merges compiler changes to bring Merlin up to date with 5.2.0minus-3. This was a complicated merge for a number of reasons:
Regarding the dependency cycle: A compiler change made
utils/language_extension.ml(i)
depend onparsing/location.ml(i)
. There are other files inparsing/
that depend on files inutils/
, so there is a mutual dependency between files inparsing/
andutils/
. While this compiles fine in the compiler, this dependency structure is problematic in Merlin because Merlin compiles each directory as an individual library. Rather than performing dune magic to resolve this, I opened a PR on the compiler that movesutils/language_extension.ml(i)
toparsing/language_extension.ml(i)
. The compiler version used for this merge is the tip of that PR rather than the tagged version.Here's my review instructions:
Here's some notes about some of the commits:
Language_extension
module moved locations as a result of this merge (see above note about dependency cycle). This manually ports over some Merlin-specific changes to that file.