[Improvement]: Hide Other type from Compiler diagnostics

[hasithaa]

Description

This is not a helpful error message for the end user. Mostly these are generated as a side effect due to an incomplete type checker rule.

Describe your problem(s)

No response

Describe your solution(s)

No response

Related area

-> Compilation

Related issue(s) (optional)

No response

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response

[hasithaa]

One option is to suppress the diagnostics if one of the parameters is a type of other. But we have to make sure at least one other error diagnostic is present, before suppressing such diagnostics.

@MaryamZi @gimantha @pcnfernando thoughts ?

[pcnfernando]

One option is to suppress the diagnostics if one of the parameters is a type of other. But we have to make sure at least one other error diagnostic is present, before suppressing such diagnostics.

@MaryamZi @gimantha @pcnfernando thoughts ?

What if; instead of suppressing, rephrase the error message? Maybe something like the one below. It's useful to know that the actual value is incompatible or type resolving failed

eg:

invalid remote method call: expected a client object, but found 'other' -> invalid remote method call: expected a client object, but the actual type is incompatible.

incompatible types: expected 'error', found 'other' -> incompatible types: expected 'error', but the actual type is incompatible.

[MaryamZi]

+1 to skip logging diagnostics with SymbolTable#semanticError.

What if; instead of suppressing, rephrase the error message? Maybe something like the one below. It's useful to know that the actual value is incompatible or type resolving failed

eg:

invalid remote method call: expected a client object, but found 'other' -> invalid remote method call: expected a client object, but the actual type is incompatible.

incompatible types: expected 'error', found 'other' -> incompatible types: expected 'error', but the actual type is incompatible.

But usually, we don't know anything about the type when it is semantic error, right? We can't say anything additional until the original issue is fixed. So I don't think we should say incompatible.

For example,

import ballerina/http;

public function main() returns error? {
    http:Client cl = check new ("http://localhost:8080");
    json payload = check c->get("/");
}

Here, the error is because of a typo, and this results in the following errors at the moment.

$ bal run temp.bal 
Compiling source
        temp.bal
ERROR [temp.bal:(5:26,5:37)] invalid remote method call: expected a client object, but found 'other'
ERROR [temp.bal:(5:26,5:27)] undefined symbol 'c'

IMO, it is enough to have just "undefined symbol 'c'", because fixing that will resolve both of the (current) errors.