Skip to content
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

feature request: text edits for bind_pat inlay hints. #13812

Open
jhgg opened this issue Dec 21, 2022 · 1 comment
Open

feature request: text edits for bind_pat inlay hints. #13812

jhgg opened this issue Dec 21, 2022 · 1 comment
Labels
A-inlay-hints inlay/inline hints C-feature Category: feature request

Comments

@jhgg
Copy link
Contributor

jhgg commented Dec 21, 2022

Inlay hints can have text edits which can be provided to "apply" the inlay hint when double clicked on. I noticed this recently in the python language server's inlay hints, that I could do:

image

We could provide text edits which would auto-import any type that is referred to, and insert the type annotation, where syntactically valid.

For example:

fn foo() {
   let eligible = "hello".starts_with(|c| c.is_uppercase());
   //         ^ `: bool `              ^ `: char`
   match Some(eligible) {
        Some(n) => { }
        //   ^ not eligible, because inserting `: bool` here would not be valid syntax.
        None => { }
   }
}
@Veykril Veykril added C-feature Category: feature request A-inlay-hints inlay/inline hints labels Dec 21, 2022
bors added a commit that referenced this issue Apr 12, 2023
feat: make inlay hints insertable

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 its 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?

```rust
let a /* inlay hint shown here */ @ (b, c) = foo();
let a @ (b, c) /* text edit inserts types here */ = foo();
```
@lowr
Copy link
Contributor

lowr commented Apr 16, 2023

For anyone interested (and reminder for myself): #14533 implemented text edits for some inlay hints (including bind_pat) without auto imports. Auto imports would be really cool, but as discussed in the PR, we want to solve #13962 beforehand.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-inlay-hints inlay/inline hints C-feature Category: feature request
Projects
None yet
Development

No branches or pull requests

3 participants