Stream: t-compiler/rust-analyzer

Topic: rust-analyzer#963

vipentti (Mar 20 2019 at 12:50, on Zulip):

I was wondering what would be the best way to go about refactoring the building of CallInfo::label, currently we build the label using completion::function_label which preserves the original formatting and information (parameters + including generics and where clauses) and then we extract the parameters separately, which may or may not match exactly since they are turned into a String manually.

Simplest solution would probably be just turning the ast::FnDef params directly into text, and then in conv implementing Conv for ra_ide_api::CallInfo and turning it into lsp_types::SignatureInformation where we ensure the LSP requirements that the parameters are a substring of the label, we could also turn them into offsets here if wanted.

Another possible solution is to change the CallInfo so that it doesn't contain a single label but all the parts that make it and then build the label separately. e.g.

pub struct CallInfo {
    /// Documentation for the function
    pub doc: Option<Documentation>,
    /// Name of the function
    pub name: String,
    /// Parameters of the function
    pub parameters: Vec<String>,
    /// Generic parameters
    pub generic_parameters: Vec<String>,
    /// Predicates
    pub where_predicates: Vec<String>,
    /// Return type
    pub ret: Option<String>,

    pub active_parameter: Option<usize>,

This would make it easy to ensure that the parameters are actual substrings of the label, but it would mean we'd need to implement some sort of pretty printing for creating the output label.

matklad (Mar 20 2019 at 14:28, on Zulip):

The letter approach seems reasonable. In general, we shouldn't rely on FnDef when making a CallInfo

matklad (Mar 20 2019 at 14:28, on Zulip):

Consider the case where you are calling a lambda function

matklad (Mar 20 2019 at 14:28, on Zulip):

It still has parameter types and return type, but they are not present in the source text. We should reconstruct them from type-inference information

matklad (Mar 20 2019 at 14:29, on Zulip):

So, CallInfo indeed should contain abstract pieces of information, and rendering them to whatever representation the client wants should be a consern of a client

Jeremy Kolb (Mar 20 2019 at 15:08, on Zulip):

I prefer the latter approach as well. Whichever way we go I think we should use the same scheme for completion and hover.

vipentti (Mar 20 2019 at 15:16, on Zulip):

Maybe instead of having it being specific to a CallInfo make something like FunctionSignature that contains the information that can be contained in the CallInfo but also be used directly by hover and completion, then make similar structure for other types as well.

vipentti (Mar 20 2019 at 15:18, on Zulip):

Then we can implement some sort of pretty printing that can be used for UI purposes

vipentti (Mar 20 2019 at 15:20, on Zulip):

So some sort of common intermediate structures for types and signatures

struct TypeWithName {
    name: String,
    typ: Option<String>,
    /// const, static etc.
    modifier: Option<String>,
vipentti (Mar 20 2019 at 15:21, on Zulip):

Then displaying would be the responsibility of the client, and we could have functions for turning AstNodes into corresponding intermediate structures

Jeremy Kolb (Mar 20 2019 at 15:34, on Zulip):

Yeah I like the FunctionSignature idea. That would make it easier to say.... switch the presentation of generic arguments if the user wanted

Jeremy Kolb (Mar 20 2019 at 15:34, on Zulip):

between arg1 : T vs where syntax or whatever

Last update: Jul 29 2021 at 07:45UTC