[Improvement]: Inconsistent resource method names generated for call instruction

[HindujaB]

Description

$subject

Describe your problem(s)

When compiling a ballerina resource method, we generate new method names with the class/object-type name prefix. This is updated in the function invocation symbol name and several other fields contain the method names such as the expression name, and invocation symbol originalName.

But we only need the method name without the type name for the method call. Therefore we filter out the redundant parts during the BIRGen and CodeGen phases.

• ballerina-lang/compiler/ballerina-lang/src/main/java/org/wso2/ballerinalang/compiler/bir/BIRGen.java

  Line 892 in 10fc965

  private Name getFuncName(BInvokableSymbol symbol) {

• ballerina-lang/compiler/ballerina-lang/src/main/java/org/wso2/ballerinalang/compiler/bir/codegen/JvmCodeGenUtil.java

  Line 426 in 10fc965

  static String cleanupObjectTypeName(String typeName) {

When I checked these name fields, the values they assigned were inconsistent for different use cases.

1. ABC.init
- Func expr name: ABC.init
- Func symbol name: ABC.init
- Func original name: init
- ObjectType name from receiver symbol: ABC

2. ABC.start
- Func expr name: ABC.start
- Func symbol name: ABC.start
- Func original name: 'start
- ObjectType name from receiver symbol: ABC

3. Int range iterator
- Func expr name: null
- Func symbol name: $anonType$return$createIntRange$_0.iterator
- Func original name: iterator
- ObjectType name from receiver symbol - null

4. Anontype
- Func expr name: compare
- Func symbol name: ($anonType$Atom$_0 & readonly).compare
- Func original name: compare
- ObjectType name from receiver symbol - null

5. MockListener
- Func expr name: detach
- Func symbol name: MockListener.detach
- Func original name: detach
- ObjectType name from receiver symbol: MockListener

Note that, to filter out the function name from the function symbol name, we use the receiverSymbol at BIRGen and the selfArg argument at CodeGen. This is because in some cases, the receiver symbol becomes null and the type can only be derived from the self-argument.

We need to have a more consistent way of providing the name. If we have a field that contains only the method name without the type prefix, we can directly use it without any filtering. It is not recommended to use string processing in the method names as they are error-prone (the user-defined name can contain special characters.) and can slow down the compilation as well.

Please find the log file with possible type name combinations here.
objectTypeFunctions.log

Describe your solution(s)

No response

Related area

-> Compilation

Related issue(s) (optional)

#42988

Suggested label(s) (optional)

No response

Suggested assignee(s) (optional)

No response