feat: make inlay hints insertable

[lowr]

Part of #13812

This PR implements text edit for inlay hints. When an inlay hint contain text edit, user can "accept" it (e.g. by double-clicking in VS Code) to make the hint actual code (effectively deprecating the hint itself).

This PR does not implement auto import despite the original request; text edits only insert qualified types along with necessary punctuation. I feel there are some missing pieces to implement efficient auto import (in particular, type traversal function with early exit) so left it for future work. Even without it, user can use replace_qualified_name_with_use assist after accepting the edit to achieve the same result.

I implemented for the following inlay hints:

• top-level identifier pattern in let statements
• top-level identifier pattern in closure parameters
• closure return type when it has block body

One somewhat strange interaction can be observed when top-level identifier pattern has subpattern: text edit inserts type annotation in different place than the inlay hint. Do we want to allow it or should we not provide text edits for these cases at all?

let a /* inlay hint shown here */ @ (b, c) = foo();
let a @ (b, c) /* text edit inserts types here */ = foo();

[lowr]

We currently render opaque types for DisplayTarget::SourceCode unconditionally, but it should fail unless we're rendering it for function param type or return type. I've looked through every HirDisplay::display_source_code() call sites and passed the flag accordingly, which I'd like to get careful review.

[bors]

☔ The latest upstream changes (presumably #14470) made this pull request unmergeable. Please resolve the merge conflicts.

[Veykril]

One somewhat strange interaction can be observed when top-level identifier pattern has subpattern:

I think its fine if we offer the edit still. The reason we render the hint after the identifier instead of the proper position is because of nesting, if we render it in the correct place we can only actually render @ bind pat hints in top level patterns.

[Veykril]

Overall looks good to me, I am worried about perf now though (especially if we text edits to more inlay hints), ideally we should calculate these in a resolve step (if the client supports it). #13962, it is mainly a question of how. We probably need to restructure this a bit so we can do a resolve step efficiently.

[lowr]

I understand the concern on the performance implication (and I actually gave a bit of thoughts on inlayHint/resolve!). We gotta call hir_def::find_path() for every def in the type being rendered, which can be quite expensive especially when it's some complex type coming from combinators and such.

Do we want to put this feature behind a configuration until #13962 is resolved? Or would it suffice to limit the length of the rendered type and bail on excess (which I haven't implemented but actually thought of and put a FIXME note on)?

[Veykril]

I think its fine to add it as is, since we arent generating edits for all hints yet. But we want resolve support before we add more I think (or before making them more complex)

[Veykril]

@bors r+

[bors]

📌 Commit c978d4b has been approved by Veykril

It is now in the queue for this repository.

[bors]

⌛ Testing commit c978d4b with merge 1ee88db...

[bors]

☀️ Test successful - checks-actions
Approved by: Veykril
Pushing 1ee88db to master...

[lnicola]

insert_inlay_hint.mp4