-
Notifications
You must be signed in to change notification settings - Fork 118
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
Improve the infer-interface code action and add an update-signature code action #1289
Improve the infer-interface code action and add an update-signature code action #1289
Conversation
502fb5f
to
bb2217d
Compare
Pull Request Test Coverage Report for Build 4268Details
💛 - Coveralls |
LGTM after a couple of changes:
|
| Typedtree.Tsig_include _ | ||
| Typedtree.Tsig_class _ | ||
| Typedtree.Tsig_class_type _ | ||
| Typedtree.Tsig_attribute _ -> None |
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.
If we want to relax ocaml-lsp
's dependency on the Typedtree
on the long term we should really try to put such utilities in merlin-lib
instead...
Also, I am curious about the reason why classes' ids are not needed for the update-signature action ?
This PR improves the
insert-inferred-interface
code-action by restricting the set of signatures inserted to only the names not already present in the interface file. Previously, this code action was only really useful on a completely empty .mli file, since all signaures from the corresponding .ml file were inserted, including duplicates of signatures already present in the .mli.Repeated applications of this code-action will now more appropriately be no-ops.
This PR also adds an
update-signatures
code action that updates the signatures for selected elements of the interface based on types inferred from the corresponding implementation.The code action works by checking for an implementation file corresponding to the current interface and querying Merlin for type analysis on both. It then extracts items from the interface that overlap with the range the user has selected and attempts to identify matching items from the inferred interface of the implementation. For any matching items, it asks Merlin to print signatures for the old and new types, and if those strings differ, it produces a text edit for the interface to make it match the implementation.
Testing
I added a new expect-test that confirms the inserted signatures exclude ones already present in the interface. The existing expect-test that assumed an empty .mli is unaffected.
New expect-tests verify the intended behavior of
update-signatures
in the following situations:This can be slow (~2s) on very large .mli files (~5k lines), but I've confirmed that the pre-existing version of
insert-inferred-interface
took a similarly long time.