这是indexloc提供的服务,不要输入任何密码
Skip to content

Conversation

@dvulakh
Copy link
Contributor

@dvulakh dvulakh commented Oct 29, 2024

This PR adds some special cases to stack-or-heap so that it more consistently reports the same location as a type-enclosing query at the same position (even if that location less accurately describes the allocating expression). Once the locations coincide in more cases, it will be easier to expose stack-or-heap in a hover-based interface via the LSP.

This less precise location reporting is gated behind the -lsp-compat true command-line flag, so editors that query the stack-or-heap RPC directly can still get the maximally descriptive ranges.

Here are the two special cases we consider:

  1. Querying the stack-or-heap of a (non-polymorphic variant) constructor now reports the location of just the constructor (not the constructed expression) when -lsp-compat true is passed. This better matches the behavior of type-enclosing, which e.g. reports 'a -> 'a option for the type of Some in Some 5. Polymorphic variants don't have this behavior in type-enclosing, so we also don't special-case them in stack-or-heap.
  2. Querying the stack-or-heap of an identifier pattern that is the left-hand side of a function binding reports the stack-or-heap of that function. The associated location is the entire binding, unless -lsp-compat true is passed, in which case it is just the identifier.

The new test file lsp_compat.ml demonstrates these special cases and how the -lps-compat flag affects their treatment.

Signed-off-by: David Vulakh <dvulakh@janestreet.com>
Signed-off-by: David Vulakh <dvulakh@janestreet.com>
gated behind [-lsp-compat] flag

Signed-off-by: David Vulakh <dvulakh@janestreet.com>
report the entire value binding when not in the lsp-compat regime

also move all the lsp-compat tests to a separate file to group them
together

Signed-off-by: David Vulakh <dvulakh@janestreet.com>
clean up some artifacts of intermediate states to make the total PR
diff cleaner

Signed-off-by: David Vulakh <dvulakh@janestreet.com>
@dvulakh dvulakh requested a review from ncik-roberts October 29, 2024 19:18
@dvulakh dvulakh requested review from liam923 and removed request for ncik-roberts November 5, 2024 19:54
Copy link
Contributor

@liam923 liam923 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Has an lsp dev has verified that the new functionality interacts well with the lsp? If so, lgtm

Comment on lines 14 to 17
let[@tail_mod_cons] rec tails = function
| hd :: tl -> (hd, tl) :: tails tl
| [] -> []
in
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function seems a bit more general than necessary - I think it might be a bit clearer if it were something like:

let[@tail_mod_cons] rec with_parents = function
| hd :: next :: tl -> (hd, Some next) :: tails (next :: tl)
| [ hd ] -> [hd, None]
| [] -> []

Signed-off-by: David Vulakh <dvulakh@janestreet.com>
Signed-off-by: David Vulakh <dvulakh@janestreet.com>
@liam923 liam923 merged commit 37e13d0 into main Nov 7, 2024
2 checks passed
@liam923 liam923 deleted the dvulakh.stack-or-heap-usability-fixes branch November 7, 2024 17:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants