[Task]: Cleanup the semtype generic function implementation

[heshanpadmasiri]

Description

With #42512 we are using the nBallerian's function type implementation in jBallerina. However nBallrina's implementation doesn't take @typeParam annotation in to consideration. Therefore in #42622 we are using a hack to make generic's work where we are keeping track of which function semtypes were created by generics and special casing their type checks in functionPathIsEmpty. While this is sufficient to get the internal libraries to work (this is the only place where @typeParam annotation is allowed) this hack is not correct and we can do a better implementation.

Describe your task(s)

To properly type check generics we need to "resolve" the generic at call site. For example assume we have

@typeParam
type F int|boolean;

function foo(F val) returns F {}

int x = 5;
F a = foo(x); <- (1);

At call site (1) we know the actual type of val is int (that is F is int). Then within the context of that call site we can do normal type checking by replacing F with int. This means we don't need to do special cases for the generics in order to support generic function foo here. We'll call this process of replacing generic parameters with specific types at call site "generic resolution". In most cases in the internal library we can resolve the generic purely using the argument types at compile time. When this is not possible (for example in the case of public isolated function 'map(Type[] arr, @isolatedParam function(Type val) returns Type1 func) returns Type1[] = external; function) we can use the static type variable to which we assign the return value to resolve the other generics (Note this prevents using var for this return value). Combination of these two should be sufficient to determine all the generics define in the internal libraries under the ballerina spec.

However we have cases which are not covered under the spec such as helpers.bal. These include generic functions that call other generics functions (example createArray is being called by other generic functions such as toArray and it call other generic functions such as next). Here we can't directly resolve generic type at the call site as I have describe above. Instead I think we need to do something akin to monomorphization at least from a type checking perspective. Each of these nested generic function calls must start at a point where we know the actual parameter type and return type, lets cal this a "resolvable call site". At the resolvable call site we can resolve the generic call. We can also resolve all internal variables of the generic function for that call site. Thus any generic calls inside that function also becomes "resolvable" thus allowing us to recursively apply this logic.

Related area

-> Compilation

Related issue(s) (optional)

Depends on #42512

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response