Nullptr check on etsEnumType · Pull Request !5911 · OpenHarmony/arkcompiler_ets_frontend

1. Nullptr check on etsEnumType
---
### **Issue**
[新需求]: Type name enum crash
[ICADES](https://gitee.com/openharmony/arkcompiler_ets_frontend/issues/ICADES)

### **Reason**
Tests 04.names_declarations_and_scopes/05.accessible/type_name_const_enum.ets
and
Tests 04.names_declarations_and_scopes/05.accessible/type_name_variable_enum.ets

Crashes. It needs to be fixed.

### **Description**

Node of the Type Relation in etsEnumType is returns nullptr when deciding function overload resolution.

There were 3 issues that this code fixed:

**1:**  A crashT the relation node was `nullptr` so it couldn't be compared with other types. In order to fix this, I set the relation to be the current argument of the function call:

funciton.cpp:1142 :
`Relation()->SetNode(arguments.at(i));`
and later set it to `nullptr` again so it resumes it's usual flow.

I've also added an additional `nullptr` check in etsEnumType.cpp:75 just to be sure. That check can be changed to a `ETS2PANDA_ASSERT`.

**2:**  When there are two function overloads with two generic typed calls, the compiler treats them the same even though their generic types are different.

For example in test.ets:

```
function foo(i: int[]){
        return 1;
}

function foo(i: int[][]){
        return 2;
}
```

This is lowered to (roughly):
```
function foo(i: Array<int>){
        return 1;
}

function foo(i: Array<Array<int>>){
        return 2;
}
```

As seen above there are two different parameters with different generic types. To check whether they are the same I made it so that it checks their generic depth. So it knows how many nested generic types there are. The functions `GetGenericDepth` and `CheckTypeArguments` does just that by recursively going through each nested generic typing.

**3:**  The last issue was that the compiler favors int parameters over actual enum types when an enum parameter is passed. For example here:

```
enum MyEnum { a=1 }
function foo(int: i) {
        return 1;
}

function foo(i: MyEnum) {
        return 2;
}

foo(a)
```

Normally without this patch, this would result in the compiler calling the first function with the int parameter and return `1`. This is because the lowering phase EnumpostCheckLoweringPhase changes the line `foo(a)` to be `foo(a.ValueOf())` which results in the call being int. This is because the Relation node we set has the flag GENERATE_VALUE_OF. To fix this, the code checks whether there is an enum signature or not when deciding the most specific parameter and removes the GENERATE_VALUE_OF flag from the node.

Note: to avoid useless loops I changed the order of the two existing loops so that now it checks for enum signatures within the existing loop.

### **Tests**
```
bash ~/arkcompiler/runtime_core/static_core/tests/tests-u-runner/runner.sh --ets-cts --build-dir ~/arkcompiler/build/ --filter "*type_name_variable_enum*" --detailed-report
```

```
bash ~/arkcompiler/runtime_core/static_core/tests/tests-u-runner/runner.sh --ets-cts --build-dir ~/arkcompiler/build/ --filter "*type_name_variable_enum*" --detailed-report
```

![Image description](https://foruda.gitee.com/images/1748206403695931545/ef7ae58d_15623791.png "屏幕截图")

Change-Id: I72ffce817c6ddb38fab2f3bc98b9d675bd4d6dce

类型	指派人员	状态
审查	@egavrin 由 CODEOWNERS 文件第 18 行指派为审查者	进行中 (0/1人)
审查	godmiaozi zhuoli72 gavin1012_hw 徐城 Urakov Alexandr Chernykh Sergey Vsevolod Pukhov	进行中 (0/1人)
测试	openharmony_ci 已测试通过	已完成 (1/1人)

OpenHarmony/arkcompiler_ets_frontend .gitee-modal { width: 500px !important; }

搜索帮助

OpenHarmony/arkcompiler_ets_frontend