Rls: Signature help request

[nrc]

Common IDE feature that we should support.

[nrc]

https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#signature-help-request

[jntrnr]

@nrc - do we have support for this in the save-analysis side?

[nrc]

No. I don't think it will be super-hard, but there's probably a lot to do. Should be post-alpha too. But it is important and I don't want to forget to look into it.

[KalitaAlexey]

@nrc,
I'd like to help with it.
Unfortunately I have no idea how.
Could you write a short description what I should look at?

[jntrnr]

The logic to do a simple form of this is in RustyCode

https://github.com/saviorisdead/RustyCode/blob/5ee3f34db89c3c76d7d69b524cd0714e24432f01/src/services/suggestService.ts#L397-L439

But I think ultimately, we'd like the compiler to answer this request and be able to give more precise signature help. I.e., be able to specialise as we know more about the function being called as each argument is provided.

[nrc]

The steps for implementing this are:

• [ ] decide on what data to present, based on the LSP message (we don't have per-arg docs in Rust, but we could use a string representation of the type there. I'm not sure where a signature label is used)
• [ ] add this data to the save-analysis information in the compiler. We'd add a field to a Def for signature_help info or something (note that there is already Signature info, but we don't use it for the RLS because it is too large and causes slowdown, it is only used for Rustdoc). We'd probably need to modify save-analysis in the compiler and the rls-data crate
• [ ] pipe this date through rls-analysis
• [ ] add a handler for handling the LSP message to the RLS, see https://github.com/rust-lang-nursery/rls/blob/master/src/actions/requests.rs
• [ ] add a test, update docs, check this works in VSCode

[DSpeckhals]

I'd like to work on this. It might take me a couple of weeks, but after looking at all of the different integration points, I think I can manage it.

Edit: After looking at this more thoroughly, there is one main obstacle I see. A request for "signatureHelp" is sent to the RLS with trigger characters (which would probably be "(" and ","). The RLS -- or perhaps rls-analysis -- then has to figure out which signature needs to have help based on a line/column cursor position. The problem is that we don't currently have a "function signature" Def that spans the whole signature. Yes, there are defs with spans for the function identifier (which can then be linked back to the actual function declaration with its metadata), but there is no way of asking the RLS , "Which function signature (parameter list) am in in?"

I thought of just extending the span for function invocations to include the identifier and the parameters, but this would cause overlaps on top of actual parameter values. That would not be good.

Instead, would it be possible to create extra data about the full span of the parameter list? I would imagine that the save-analysis would do this, then the RLS could look up the "enclosing closest previous" of these defs (via rls-analysis) based on the cursor position and a new field (maybe "signature_span") in the def.

[nrc]

@DSpeckhals the RLS has access to the current state of the source code. Could you walk back through the text to find the function name, and thus the def for the signature?

E.g., given foo(bar(), where the RLS gets called after the ,, you can look at the text and work backwards to find the foo identifier, which should be a ref to a def with the right signature info (to start with, we could trigger only on ( which should make that really easy).

[DSpeckhals]

@nrc I see. I've actually done something similar to what you describe in a simple parser for Python indentation. It isn't too difficult. It's mainly keeping track of open parens. The things you have to watch for are:

• Comments
• String literals
• Regex

Perhaps we could do this for stucts also. That would be not too dissimilar from function signatures. I will look to see if this is "legal" in the LS standard.

[vhakulinen]

Whats the status with this?