Support inlay hints

[HKalbasi]

Inlay hints add additional inline information to source code, like inferred types and parameter names, which language servers can provide. Supporting them in scip (and sourcegraph) would be great.

[varungandhi-src]

I was talking about this with @olafurpg earlier today, and probably the right thing to do here is to attach extra information to source ranges, or occurrences, depending on the exact details. SCIP could encode the information at the semantic level -- track whether the information is an inferred type, a parameter name, or in languages like C++ an implicit conversion. Different UIs could potentially render it differently, e.g. as inlay hints, or as something else.

The other thing to be careful of here is ideally, we would have support for richer structure, e.g. so that we can potentially support clicks, hovers etc instead of just rendering a plain string.

Right now, we're focused on working on different indexers, and this would also require some design and frontend work for the end-to-end experience. Overall, I feel like this feature would be useful for C++ too (and maybe other languages with type inference/method chaining patterns), so it would be nice to support this in the future.

[michaelpj]

I think generally being able to add some kind of unspecified additional annotations to ranges might be nice. Obviously having specified annotations is better, but for the use cases I'm thinking of where SCIP is used as an intermediary format between two tools that can coordinate closely (such as an indexer and language server for the same language), having an unspecified annotation type that can be used to pass application-specific information through might be quite handy.

[varungandhi-src]

@michaelpj for that use case, I think it's probably best to use a fork (I'm guessing you're already doing that). That way, you can add more structure directly, instead of having to stuff everything into a catch-all byte buffer, and having a separate serialization/deserialization step for the byte buffer (per occurrence).

For structured data (and not catch-all fields) where the design has been relatively clear, we've been open to adding new fields to SCIP in the past that we're not yet using at Sourcegraph.

[michaelpj]

(I'm not using it at all yet, I'm just assessing :) )

[varungandhi-src]

One more use case for this: implicit/default initialization. For example, in Go, there is a native notion of initializing field values to default 0; it can be useful to know where a field is being implicitly initialized to the zero value.