[Semantic API] assignableTo doesn't work for int vs. float

[rasika]

Currently in langserver we have this code-action TypeCast to suggest type cast code-fix whenever there's incompatible types diagnostic message on the code.

For instance, below code snippet will suggest adding <int> into front of 1.0 resulting int x = <int>1.0;

Before Code-Action Execution:

int x = 1.0;

After Code-Action Execution:

int x = <int>1.0;

The initial implementation is a dump type-cast and does not take into account the assignability of the value. However, this might fail/ produce invalid type-casts in some instances. Thus, thought of using semantic api to resolve assignability.

There's typeSymbol.assignableTo(typeSymbol) api and when trying to invoke api for above code snippet it always returns false comparing IntTypeSymbol vs. FloatTypeSymbol.

@pubudu91 @hasithaa What is the correct usage of assignableTo() method? I thought we are solving the above problem with that.

[pubudu91]

assignableTo() is not for the above use case. It's basically an API provided for the internal type checker. More precisely, to the following: https://github.com/ballerina-platform/ballerina-lang/blob/master/compiler/ballerina-lang/src/main/java/org/wso2/ballerinalang/compiler/semantics/analyzer/Types.java#L622

It checks whether a value of a particular type can be assigned to a variable of a particular type. It does not check whether that value can be casted to the contextually expected type. That's a completely different kind of check. In the type checker that functionality is provided by the following:

ballerina-lang/compiler/ballerina-lang/src/main/java/org/wso2/ballerinalang/compiler/semantics/analyzer/Types.java

Line 2069 in 9492cfb

public boolean isTypeCastable(BLangExpression expr, BType sourceType, BType targetType, SymbolEnv env) {

If this is needed, will have to see whether the above mentioned isTypeCastable() method can be refactored to work only with BTypes since we don't have access to the other params within the type symbols.

[nadeeshaan]

When we are going with the type cast code action, it is mandatory to generate semantically correct statements. As mentioned, it is tricky to expose this via the semantic API since the types are being accessed at LS in different approaches and the environment information has to calculate at the semantic API.