Fix restparam/optional/type scene in declgen_ets2ts · Pull Request !6437 · OpenHarmony/arkcompiler_ets_frontend

1. Fix restparam/optional/type scene in declgen_ets2ts
---
### 关联的Issue
Issue: https://gitee.com/openharmony/arkcompiler_ets_frontend/issues/ICHL3R
Change-Id: I968e344bb3d87b4e75d9db9b4df4b8dc09905437
### 提交类型
- [ ] 需求
- [x] bugfix

### 需求背景/Description

### 问题现象&&分析/Reason 
Fix restparam/optional/type scene in declgen_ets2ts

### 修改方案/Scheme
1. generate rest and optional param
ArkTS1.2
```
export let foo7: (...nums: number[]) => number = (...nums: number[]): number => {
  return nums.length;
}
export let foo8: (nums?: number[]) => number = (nums?: number[]): number => {
  return 1;
}
```

Current Decl
```
export declare let foo7: (nums: Array<number>) => number;
export declare let foo8: (nums: Array<number>) => number;
```

Expected Decl
```
export declare let foo7: (...nums: Array<number>) => number;
export declare let foo8: (nums?: Array<number>) => number;
```

2. add type in glue code when import/export interface

ArkTS1.2
export.ets
```
export interface A {}
```

test.ets
```
import { A } from "./export"
export { A } from "./export"
```

Current Glue Code
```
import { A } from "./export";
let ETSGLOBAL = (globalThis as any).Panda.getClass('Ltest/ETSGLOBAL;');
ETSGLOBAL._$init$_();
export { A } from "./export";
```

Expected Glue Code
```
import type { A } from "./export";
let ETSGLOBAL = (globalThis as any).Panda.getClass('Ltest/ETSGLOBAL;');
ETSGLOBAL._$init$_();
export type { A } from "./export";
```

考虑以下纯ArkTS 1.1版本的代码示例：
// file1.ets
export interface X {}
// file2.ets 
import {X} from "./file1"
export {X} from "./file1"
在1.1版本的编译流程中，ets文件会先被转换为ts文件，再交由es2abc处理。转换后的ts文件会变为：
// file1.ts
export interface X {}
// file2.ts
import type {X} from "./file1"
export type {X} from "./file1"
可以看到，编译器会自动为interface添加type关键字。es2abc能够识别这些type声明，并过滤掉它们，不会将import type/export type生成到moduleRequest中。这是因为在1.0架构中，interface在运行时没有实际实体，如果将这些类型声明包含在moduleRequest中，运行时就会报错提示找不到导出的符号X。

现在考虑纯ArkTS 1.2版本的相同代码：

// file1.ets
export interface X {}
// file2.ets
import {X} from "./file1" 
export {X} from "./file1"
生成的中间ts代码为：
// file1.ts
export interface X {}
// file2.ts
import {X} from "./file1"
export {X} from "./file1"
注意到针对interface并没有自动添加type关键字。当这些代码被输入到es2abc时，编译器不会进行过滤操作，导致这些类型声明被包含在moduleRequest中，最终在运行时抛出"找不到导出的符号X"的错误。

Consider the following pure ArkTS 1.1 code example:
// file1.ets
export interface X {}
// file2.ets
import {X} from "./file1"
export {X} from "./file1"
In the 1.1 compilation process, .ets files are first converted to .ts files before being processed by es2abc. The converted ts files become:
// file1.ts
export interface X {}
// file2.ts
import type {X} from "./file1"
export type {X} from "./file1"
We can observe that the compiler automatically adds the 'type' keyword for interfaces. es2abc can recognize these type declarations and filters them out, preventing import type/export type from being included in moduleRequest. This is because in the 1.0 architecture, interfaces have no runtime representation. If these type declarations were included in moduleRequest, the runtime would report an error about not being able to find the exported symbol X.

Now consider the same code in pure ArkTS 1.2:
// file1.ets
export interface X {}
// file2.ets
import {X} from "./file1"
export {X} from "./file1"
The generated intermediate ts code is:
// file1.ts
export interface X {}
// file2.ts
import {X} from "./file1"
export {X} from "./file1"
Note that the 'type' keyword is not automatically added for interfaces. When this code is fed to es2abc, the compiler doesn't perform filtering, causing these type declarations to be included in moduleRequest, which ultimately leads to a runtime error "Cannot find exported symbol X".

### 测试结果（测试截图直接贴在对应测试项，主干已知问题需明确引入pr/责任人）
OK
#### 功能测试（除仅涉及文本外必测项）[wiki](https://gitee.com/openharmony/arkcompiler_ets_frontend/wikis/%E4%BB%A3%E7%A0%81%E6%8F%90%E4%BA%A4%E8%A6%81%E6%B1%82%E5%8F%8A%E6%B5%8B%E8%AF%95%E9%AA%8C%E8%AF%81%E6%B5%81%E7%A8%8B)
1. es2abc测试用例（Debug模式）
- [ ] 已通过
- [ ] 不涉及，无需验证

2. Verifier测试
- [ ] 已通过
- [ ] 不涉及，无需验证

3. 64位RK编译
- [ ] 已通过
- [ ] 不涉及，无需验证

4. 编译mac平台sdk
- [ ] 已通过
- [ ] 不涉及，无需验证

#### 混淆测试（涉及arkguard改动时必测项）[wiki](https://gitee.com/openharmony/arkcompiler_ets_frontend/wikis/%E6%B7%B7%E6%B7%86%E6%B5%8B%E8%AF%95%E9%AA%8C%E8%AF%81%E6%B5%81%E7%A8%8B?sort_id=11451209)
1. 单元测试
    - [ ] 已通过
    - [ ] 不涉及，无需验证

2. Compiler测试套
    - [ ] 已通过
    - [ ] 不涉及，无需验证

3. TSC extra测试套
    - [ ] 已通过
    - [ ] 不涉及，无需验证

4. Test262测试套
    - [ ] 已通过
    - [ ] 不涉及，无需验证

5. Benchmark测试
    - [ ] 已通过
    - [ ] 不涉及，无需验证

6. 应用自动化测试套
    - [ ] 已通过
    - [ ] 不涉及，无需验证

7. 是否创建全局变量，若创建全局变量，是否有清空操作
    - [ ] 创建了全局变量，且已清空
    - [ ] 创建了全局变量，未清空
    - [ ] 未创建全局变量

#### 兼容性测试（指令生成、文件格式修改时）
1. 小版本兼容性测试 
    - [ ] 已增加版本号
    - [ ] 已通过
    - [ ] 不涉及，无需验证

2. 大版本兼容性测试 
    - [ ] 已通过
    - [ ] 不涉及，无需验证

3. es2abc版本兼容性测试 
**说明：如PR涉及版本控制用例的变更，需同步检查修改对其他分支的影响，并确认是否要同步受影响的分支**
    - [ ] 涉及，变更影响 API/字节码 版本， 需同步修改到其他分支
    - [ ] 涉及，变更影响 API/字节码 版本， 无需同步到其他分支
    - [ ] 不涉及，变更不涉及 API/字节码 版本

#### 性能测试 (新增语法检查等场景)
- [ ] 已通过
- [ ] 不涉及，无需验证

#### 指令/abc格式修改自检，需联系下方邮箱，同步至相关领域
**重要：涉及runtime_core仓abc2program、libpandafile、isa目录下的修改，必须提供一个编译helloworld项目的hap包给对应领域，并联系下方邮箱**
- [ ] 涉及，已同步
- [ ] 不涉及

**Email:** wutao185@huawei.com

### L0新增用例自检结果
- [ ] 是，有新增L0用例，且完成自检
- [ ] 否

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

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

搜索帮助

OpenHarmony/arkcompiler_ets_frontend