Inlay hints: traverse ghost locations

[mlasson]

Description

Consider the following code:

let f = fun x -> x ^ ""
let g _ = fun x -> x ^ ""

In this case, an inlay hint appears for x in f, but no hint is shown for g.

In VS Code, this results in the following display:

Issue

The inlay hints implementation includes logic to stop traversing "ghost locations" to avoid annotating generated code. However, a simple definition like:

let f x = ...

is syntactic sugar for:

let f = fun x -> ...

where fun x -> introduces a ghost location. This explains why the ghost location check had to be explicitly disabled in your test.

Proposed Fix

This PR modifies the traversal logic to allow ghost locations even if they originate from "generated code." Instead of blocking traversal, ghost locations are filtered when generating inlay hints.

[mlasson]

I tested my "fix" with generated code and got the following result:

This highlights why simply filtering the output isn't a viable solution. Code generators actively use locations, sometimes reusing them multiple times, which makes it difficult to distinguish between meaningful and redundant hints.

[mlasson]

Here is the PR that introduced the "avoid-ghost-location" ocaml/ocaml-lsp#1290 for context.

[mlasson]

In commit [9a977d7](9a977d7), I reverted my previous fix and implemented a new approach.

The new fix stops traversal for structure items with a ghost location that are likely produced by deriving code generators while still allowing traversal inside expressions with ghost locations.

[mlasson]

In commit 598e863 I proposed yet another fix. We can rely on the merlin.hide attribute introduced by well-behaved code generators !

[voodoos]

Seems reasonnable to rely on merlin.hide attributes for this indeed.

I wonder what happens in other cases were the compiler introduces ghost locations. Standard example of these are the use of punning in record's label names and function labels. Could you add such examples to your test ?

[mlasson]

Closed in favor of #1894

[mlasson]

@voodoos I added the tests #1894 (but they were already broken even when we were not checking for ghost locations)