Create variable code action not suggested for remote method call expression

[malinthar]

Description: Consider the following scenario where I'm trying to invoke a remote method and assign the response to a variable. The create variable code action is not suggested in this scenario.

import ballerina/http;
import ballerina/io;

configurable string apiKey =  ?;
public function main() returns  error? {

    http:Client cli = check new("https://api.apilayer.com/exchangerates_data");

    cli-> get("convert?to=LKR&from=USD&amount=1&date=2022-05-29",{apiKey});
    
    io:println("Hello, World!");
}

[gayalkuruppu]

Blocked by #36542

[LakshanWeerasinghe]

Currently we are providing the create variable codea action for the variable assignment required (BCE2526). In this case we get the diagnostic of cannot infer type for 'target type' (BCE3934). If we provide create variable code action for this diagnostic it can be confusing to the user.

This diagnostic is logged in the Unifier.java utils class. If we are going to provide the code action for this diagnostic, we may have to show a different diagnostic message to the user for this scenario. WDYT? @mohanvive @imesh @malinthar

[gimantha]

We will change the error message to give proper meaning to the user. The error message should convey the user to define a left hand side variable and it should have the specific type (cannot declare a variable with var)

[MaryamZi]

We actually need to say that the argument cannot be inferred or that the argument has to be specified explicitly.

As an example, for

function fn(typedesc td = <>) returns td = external;

public function main() {
    fn();
}

both

int i = fn();

and

var j = fn(int);

work.

I think we should say something like

cannot infer the 'typedesc' argument for parameter 'paramName': expected a contextually-expected type or an argument for the parameter 'paramName' of the dependently-typed function

Still, I'm not sure it'll be a 100% clear to someone who is not familiar with dependently-typed functions.

[hasithaa]

Yes, I agree with @MaryamZi comment. IMO We can omit the term dependently-type and simply say the function's name.

[MaryamZi]

Yes, I agree with @MaryamZi comment. IMO We can omit the term dependently-type and simply say the function's name.

We may not always have a function name though, right? E.g., when we are using a variable of a function type. We don't seem to support this at the moment.

I think it will be useful to say dependently-typed function though, I think it may at least get the user to look up what a dependently-typed function is, WDYT?

If not should we just say

cannot infer the 'typedesc' argument for parameter 'paramName': expected a contextually-expected type or an argument for the parameter