!1770 merge feature_chir_pkg_push_6_2 into main feat: support plugin Created-by: Mr_Kang_Yi Commit-by: kangyi Merged-by: CangjiePL Description: ## Change Details (Required) 编译器插件功能使用cangjie语法实现，替换之前的c++语法 1. 删除之前c++相关代码，主要是MetaTransformation目录里面的，删除c++版本插件管理相关的代码 2. 新增cangjie版本插件运行相关代码，主要放在src/CHIR/Transformation/ExecutePlugin.cpp里面 3. 序列化和反序列化代码支持从内存中读取数据，之前只能从文件中读取 4. 加载插件在CompilerInstance::PerformPluginLoad里面，执行插件在ToCHIR::PerformPlugin里面 ## Change Type (Required) Please describe the type of changes in this Pull Request (reason). **Simply save and click the checkbox, or when editing, change [ ] to [x] for the relevant item.** - [x] Feature - [ ] Bugfix - [ ] Build Process or Auxiliary Tool Changes - [ ] Documentation Update ## Self-Check of Changes (Required) **Please do not modify or delete the following options. Simply save and click the checkbox, or when editing, change [ ] to [x] for the relevant item.** ### Local Compilation Verification Results: - [x] Cangjie Compiler compiled successfully - [x] Cangjie Runtime compiled successfully - [x] Cangjie Standard Library compiled successfully - [ ] Not applicable (select this option for auxiliary tool changes or documentation updates) ### Local Test Case Verification Results: - [x] Pass. Please provide screenshots below. - [ ] Not applicable. Please explain the reasons below.  ## Related Issues (Required) https://gitcode.com/Cangjie/cangjie_compiler/issues/507 See merge request: Cangjie/cangjie_compiler!1770
feat(android): support aarch64-linux-android23 target Register the android23-aarch64 build target (aarch64-linux-android23) in build.py and align the android_aarch64_toolchain.cmake so the API 23 build reuses the existing aarch64 runtime directory layout. This enables cjc ... --target=aarch64-linux-android23 .... Also default the cjc Android API level for aarch64 (no-suffix --target=aarch64-linux-android) to API 23, matching the docs, and use the API 23 toolchain directory. The android-aarch64 target resolved to aarch64-linux-android31, while android23-aarch64 resolved to aarch64-linux-android23. They diverged only in API level, yet all downstream toolchain/toolchain-selection logic keys off the resolved triple. Make android-aarch64 resolve to aarch64-linux-android23 so both inputs produce identical behavior, unifying the default android-aarch64 build on API level 23. Additional cleanups folded in: - OptionAction.cpp: the catch-branch error message still said ">= 26" after MIN_ANDROID_API was lowered to 23; update to 23 to match the floor check. - Option.h: remove the unused DEFAULT_ANDROID_API (formerly DEFALUT_ANDROID_API) constant; it had no references and its rename carried no functional effect. Signed-off-by: zhuhaoran5 <zhuhaoran5@huawei.com>
fix: harden demangler bounds check and GCC version parsing against crashes Signed-off-by: Tghoul-xlx <xujiale10@huawei.com>
docs: 处理Standalone_Build_Guide.md表达问题 表达更多的时候用的更多更多，都处理了。 Signed-off-by: m0_66062719 <546041963@qq.com>
docs: update architecture and readme desc Signed-off-by: xuanjz <xuanjiazhen@huawei.com>
!2083 merge bugfix_enable_chir_opt_case_3 into main fix: refactor devirtualization Created-by: Mr_Kang_Yi Commit-by: Mr_Kang_Yi Merged-by: cangjie-ci Description: ## Change Details (Required) # CHIR 实例虚函数去虚化重构说明 --- ## 1. 背景与目标 原有 Devirtualization pass 存在以下问题： - FindRealCallee 职责过重：同时负责 callee 查找、签名匹配、this 类型推断 - 开放类候选收集依赖递归 CollectCandidates + 复杂签名比对，难以维护 - 分析数据收集（返回类型 map、继承关系、const 成员）与 pass 逻辑耦合在 DevirtualizationInfo 中 - 不支持 TryInvoke；泛型实例化与内联共用 GetInstMapFromApply，语义不清晰 本次重构目标： 1. **简化实 callee 查找**：基于 vtable offset 直接查找，开放类场景 BFS 收集子类型 2. **分离分析层**：Collector 独立，DevirtualizationInfo 仅作数据容器 3. **统一 this 类型计算**：与 callee 查找解耦，使用 GetInstSubType 4. **补齐 TryInvoke、按需泛型实例化** 等能力 --- ## 2. 重构后整体架构 ┌─────────────────────────────────────────────────────────────┐ │ DevirtualizationInfo::Collect() │ │ ┌──────────────────┐ ┌─────────────────────┐ ┌───────────┐ │ │ │ReturnTypeMap │ │InheritanceInfo │ │ConstMember│ │ │ │Collector │ │Collector │ │Collector │ │ │ └────────┬─────────┘ └──────────┬──────────┘ └─────┬─────┘ │ └───────────┼──────────────────────┼──────────────────┼───────┘ │ │ │ ▼ ▼ ▼ returnTypeMap subtypeMap constMemberTypeMap defsMap （仅事实，无闭世界过滤） │ │ └──────────┬───────────┘ ▼ ┌─────────────────┐ │ TypeAnalysis │ ← 推断 Invoke 接收者类型 (EXACTLY / SUBTYPE_OF) └────────┬────────┘ ▼ ┌───────────────────────────────────────────┐ │ Devirtualization │ │ IsSubtypeSetComplete ← 闭世界策略(私有) │ │ CollectAllSubTypes ← 链不封闭则空集 │ │ FindRealCallee / RunOnFunc │ └───────────────────┬───────────────────────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ FindRealCallee GetInstSubType HasUnknownGenericType (Function*) (this 类型) (泛型安全检查) │ │ └──────┬──────┘ ▼ RewriteToApply / RewriteToBuiltinOp (Invoke/TryInvoke → Apply/TryApply/BinaryExpr) │ ▼ CreateInstFuncIfPossible (按需实例化泛型 callee) --- ## 3. 核心算法：FindRealCallee ### 3.1 两路分支 | 路径 | 触发条件 | 策略 | |------|----------|------| | **精确路径** | typeStateKind == EXACTLY，或 !specificType->CanBeInherited() | 在 specificType 上直接调用 SearchRealCalleeInVtable | | **开放类路径** | SUBTYPE_OF 且类型可继承 | CollectAllSubTypes BFS → 各子类型 vtable 查找 → 唯一实现才改写 | **精确路径覆盖范围（相对旧版扩展）：** - 旧版：!specificType->IsClass() || EXACTLY - 新版：!specificType->CanBeInherited() || EXACTLY（含 struct、enum、builtin 等不可继承类型） ### 3.2 SearchRealCalleeInVtable 在类型及其 extend 链（CollectAllDefs）的 vtable 中，按 invoke.GetVirtualMethodOffset() 取方法： 1. 匹配 srcParentType 与 invoke.GetInstSrcParentCustomTypeOfMethod() 的 class def 及实例化类型 2. 跳过 pure abstract 3. 优先返回 WrappedRawMethod，否则返回原 Function* ### 3.3 CollectAllSubTypes 与闭世界提前返回 CheckCustomTypeInternal 已从 InheritanceInfoCollector / DevirtualizationInfo 删除。闭世界策略改由 Devirtualization::IsSubtypeSetComplete 承担，在 CollectAllSubTypes 内检查： cpp // 根不封闭 → 空集，FindRealCallee 不去虚 if (specific.CanBeInherited() && !IsSubtypeSetComplete(*specific.GetClassDef())) { return {}; } std::vector<Type*> allSubTypes{&specific}; // subtypeMap 不含自身，须手动加入 // BFS：subtypeMap[ClassDef*] → InheritanceInfo{parentType, subType} // CalculateGenericTyMapping + ReplaceRawGenericArgType 实例化泛型子类型 // 链路上任一可继承子类型 !IsSubtypeSetComplete(*def) → return {}; // 整体放弃 要点： - subtypeMap **只存父类 → 直接子类**（本包可见边的完整收集，不做 SKIP_ANALYSIS / 闭包 class / 闭世界过滤），不含当前类型自身 - 不再单独判断 abstract；若无 concrete 实现，vtable 查找自然返回 nullptr - **提前返回空集** 是本轮核心：不能把「中间 open 类型」当叶子继续收，否则会漏掉包外子类却误判唯一实现 - FindRealCallee 对空集不改写；非空则各子类型查 vtable，唯一实现才去虚 - IsSubtypeSetComplete 的可见性规则见 §7.3（outputMode == EXECUTABLE，**不要**用 CompileExecutable()） --- ## 4. this 类型与泛型安全 ### 4.1 this 类型（重构后） FindRealCallee **仅返回 Function***，this 类型在 RunOnFunc 中单独计算： cpp auto srcParentType = invoke->GetInstSrcParentCustomTypeOfMethod(builder); auto genericSubType = realCallee->GetParentCustomTypeOrExtendedType(); auto instSubType = GetInstSubType(*genericSubType, *srcParentType, builder); | 重构前 | 重构后 | |--------|--------| | FindRealCallee 返回 (callee, thisType) | 只返回 callee | | thisType 来自候选搜索路径 | thisType = GetInstSubType(callee 声明类型, invoke 虚表父类型) | ### 4.2 泛型安全检查 | 重构前 | 重构后 | |--------|--------| | CheckAllGenericTypeVisible(thisType, func 可见泛型集) | HasUnknownGenericType(srcParentType, instSubType) | HasUnknownGenericType 用于排除「子类引入父类签名中未知泛型参数」的场景，例如： cangjie interface I { func foo() } class CA<T> <: I { public func foo() {} } func goo(a: I) { a.foo() } // CA<T> 为唯一候选但引入自由泛型 T，不应去虚化 --- ## 5. IR 改写（RewriteToApply） ### 5.1 RewriteInfo 结构 cpp struct RewriteInfo { InvokeBase* invoke; // Invoke 或 TryInvoke Function* realCallee; Type* thisType; // instSubType }; - 移除独立 typeArgs 字段，改写时直接使用 invoke->GetInstantiatedTypeArgs() - 移除 newApply 字段；实例化函数在 CreateInstFuncIfPossible 中处理 ### 5.2 改写流程 1. 尝试 RewriteToBuiltinOp（==、!=、<、> 等 → BinaryExpression） 2. 处理 this 参数 upstream TypeCast/Box 3. TypeCastOrBoxIfNeeded 转换 this 到目标类型 4. 构造 FuncCallContext，调用 CreateInstFuncIfPossible 5. 生成 Apply 或 TryApply（TryInvoke 场景） 6. 删除无用的 cast 表达式 ### 5.3 this 引用类型规则（相对旧实现的有意变化） 改写时 **Apply 的 thisType 与 TypeCastOrBoxIfNeeded 的目标类型共用同一套规则**： cpp if (thisType->IsReferenceType() || (thisType->IsValueType() && needThisTypeRef(*realFunc))) { thisType = builder.GetType<RefType>(thisType); } // needThisTypeRef: MUT 方法 / 构造器 / 实例变量初始化 这与 AST2CHIR 的 AddRefIfFuncIsMutOrClass 一致：class/array 始终带 &；值类型仅 mut / ctor / instance-var-init 带 &。 #### 旧 RewriteToApply 在做什么 旧实现把「Apply.thisType」和「TypeCast 目标」拆成两套计算，且默认调用的是 **vtable 里的 wrapper**（builtin 尤其如此）： | 步骤 | 旧行为 | |------|--------| | Apply.thisType 默认 | 一律 Ref<rewriteInfo->thisType> | | 例外 | 仅当 thisType 是 struct/enum **且** callee 带 WrappedRawMethod：改成非 ref，mut/ctor/varinit 再加回 &，并 unwrap 到 raw method | | TypeCast 目标 instThisType | GetInstParentType(thisDeref, callee 第一形参剥 ref)，class/array 或 MUT 再加 & | | builtin 特判 | instThisType = Ref<Any>（覆盖上面的计算结果） | 旧 builtin 特判的原因：值类型虚方法的 wrapper 第一形参是 Any&（见 WrapVirtualFunc::GetWrapperFuncType），旧代码对 builtin **不 unwrap** WrappedRawMethod，改写后仍调用 wrapper，因此 TypeCast 必须落到 Any&。 #### 为什么可以删掉 Ref<Any> 特判和 GetInstParentType 新 SearchRealCalleeInVtable **一律返回 raw method**（有 WrappedRawMethod 就 unwrap）。改写后调用的是 raw method，其 this 形参是： - 非 mut 值类型：S / E / Int64（不带 &） - mut 值类型：S& - class：C& 因此： 1. **TypeCast 目标必须是 raw method 的 this 类型**，不能再是 wrapper 的 Any&。TypeCastOrBoxIfNeeded(I&, Int64) 会生成 UnBoxToValue；mut struct 则是 UnBoxToRef。这正是 wrapper 函数体内部本来要做的事，去虚化后直接做掉即可。 2. **GetInstParentType(this, callee第一形参) 不再需要**：raw method 的第一形参类型与 5.3 算出的 thisType 已经对齐；thisType 本身由 GetInstSubType(callee 声明类型, invoke 虚表父类型) 得到，已经是实例化后的接收者类型。 3. **Apply.thisType 不再默认套 Ref**：旧默认 Ref<Int64> 是「仍在调 wrapper」时的附属产物。CodeGen CreateTypeInfo 会先 DeRef，CHIRChecker 检查前也会 StripAllRefs，真正影响语义的是 **实参类型**（是否 UnBox），不是 thisType 外壳上多一层 Ref。 实测（-O2 --fchir-devirtualization --fno-chir-function-inlining --dump-chir，接口 public 且 executable 下唯一实现）改写结果： text // struct 非 mut %5: Struct-S = UnBoxToValue(%0) // %0: IStruct& %6: Int64 = Apply(Struct-S->S.tag, %5) // struct mut %5: Struct-S& = UnBoxToRef(%0) // %0: IMut& %6: Int64 = Apply(Struct-S&->S.bump, %5) // enum %5: Enum-E = UnBoxToValue(%0) %6: Int64 = Apply(Enum-E->E.tag, %5) // builtin extend（走不到 RewriteToBuiltinOp 的普通方法） %9: Int64 = UnBoxToValue(%0) // %0: I64Face& %10: Int64 = Apply(Int64->extend.tag, %9) // 局部已知 Int64 经 Box 再 invoke：CollectUpstreamTypeCasts 剥掉 Box，不再 UnBox %1: Int64 = Constant(42) %3: I64Face& = Box(%1) %7: Int64 = Apply(Int64->extend.extra, %1) 旧实现在最后一类会变成 Apply(Ref<Int64>->wrapper, TypeCast(obj, Any&))。新实现更短，且与直接调用 raw method 的约定一致。这是有意的行为变化，不是静默回归。 --- ## 6. 泛型 callee 实例化 ### 6.1 CreateInstFuncIfPossible - 在 RewriteToApply 阶段 **按 call-site 按需** 实例化（旧版 InstantiateFuncIfPossible 为批量处理） - 条件：func->IsInGenericContext() 且 thisType / instTypeArgs 均已完全实例化（无 GenericRelated） - 使用 BlockGroupCopyHelper::CloneBlockGroup 克隆函数体 - 实例化后清空 context.instTypeArgs 与 context.thisType ### 6.2 BlockGroupCopyHelper 与 GetInstMapFromApply instMap 只保留 Utils::GetInstMapFromApply（ApplyBase → unordered_map）。BlockGroupCopyHelper 不再提供同名接口。 | API | 用途 | |-----|------| | Utils::GetInstMapFromApply | TypeAnalysis 与 **函数内联** 共用的泛型映射 | | InitInstContext | 把 instMap / thisType 交给后续 CloneBlockGroup（内联还需同 def 时保留 ThisType） | | GetInstMapFromFuncCall | **去虚化** call-site 泛型映射（尚无 Apply，不能走 Utils） | GetInstMapFromFuncCall 通过 GetInstParentCustomTyOfCallee(func, args, thisType, builder) 解析父类型泛型实参。 --- ## 7. 分析层拆分（DevirtualizationInfo） ### 7.1 重构前 cpp class DevirtualizationInfo { void CollectInfo(); void FreshRetMap(); void CollectConstMemberVarType(); const SubTypeMap& GetSubtypeMap() const; // ... 收集逻辑与数据混在一起 }; ### 7.2 重构后 cpp struct DevirtualizationInfo { void Collect(); // 委托三个 Collector（仅事实，无闭世界策略） ReturnTypeMap returnTypeMap; // ReturnTypeMapCollector SubTypeMap subtypeMap; // InheritanceInfoCollector DefsMap defsMap; // InheritanceInfoCollector ConstMemberMapType constMemberTypeMap; }; ### 7.3 Collect 与闭世界判断分工 - **InheritanceInfoCollector::Collect**：遍历 GetAllCustomTypeDef()，记录本包可见的父子边（含 extend）；**不做** SKIP_ANALYSIS / IsClosureConversionEnvClass 过滤 - SKIP_ANALYSIS 类型主要是注解伪定义空壳，通常无父类边，收进 subtypeMap 不产生有效边，也不影响去虚；其它 pass 跳过是为了避免分析残缺 IR，与本 Collect 无关 - 去虚在 `DoClosur See merge request: Cangjie/cangjie_compiler!2083
fix: resolve shell script lint errors and correct cmake file renaming Signed-off-by: Tghoul-xlx <xujiale10@huawei.com>
fix: use virtual method in Invoke and InvokeStatic Signed-off-by: kangyi <kangyi9@h-partners.com>
!2091 merge fix/mock_default_interface_transitive into main fix(unittest): indirect interface default static methods Created-by: iliayar Commit-by: Ilia Iaroshevskii Merged-by: cangjie-ci Description: ## Change Details (Required) Implement default interface methods accessors in classes which are indirect subtypes of interface ## Change Type (Required) - [ ] Feature - [x] Bugfix - [ ] Build Process or Auxiliary Tool Changes - [ ] Documentation Update ## Self-Check of Changes (Required) ### Platform Differences: - [x] No difference - [ ] Difference - [ ] Windows - [ ] Linux - [ ] macOS - [ ] Other (Please explain the reasons below) ### Affected Components: - [x] cjc (Cangjie Compiler) - [ ] LSP (Cangjie Language Server) - [ ] cjfmt (Cangjie Formatter) - [ ] cjlint (Cangjie Lint Tool) - [ ] stdx (Cangjie Standard Library Extensions) - [ ] Other (Please explain the reasons below) ### Local Compilation Verification Results: - [x] Cangjie Compiler compiled successfully - [x] Cangjie Runtime compiled successfully - [x] Cangjie Standard Library compiled successfully - [ ] Not applicable (select this option for auxiliary tool changes or documentation updates) ### Local Test Case Verification Results: - [x] Pass. Please provide screenshots below. - [ ] Not applicable. Please explain the reasons below.  ## Related Issues (Required) https://gitcode.com/Cangjie/cangjie_compiler/issues/1110 See merge request: Cangjie/cangjie_compiler!2091
Update llvmPatch.diff from llvm-project 500af50d Co-authored-by: weinw<weiningwei@h-partners.com>
!2096 merge bugfix_fix_everything3_main into main fix: fix low-probability test case failures Created-by: Augus_Jan Commit-by: Augus_Jan Merged-by: cangjie-ci Description: ## 变更内容（必填） 修复一个随机失败的用例，该用例是生命周期陷阱。 机制链（用探针抓到铁证）： 1. ParseRichFile() 调 Parser parser(RICH_SRC, diag, sm)。RICH_SRC 是 const char*（PrintNodeTest.cpp:35）。 2. Parser::Parser(const std::string& input, ...)（Parser.cpp:44）接收引用——const char* 隐式构造一个 std::string 临时对象绑定到 input。 3. ParserImpl 构造 lexer{make_unique<Lexer>(input, ...)}，Lexer/LexerImpl 存 pInputStart = input.c_str()（LexerImpl.h:40-42），裸指针。 4. 这条语句结束，临时 std::string 析构，pInputStart/pNext 悬垂。 5. 后续 Peek() 读悬垂指针 → 约 9% 读到错误内容（探针抓到首 token 变成 { 而非 enum），preamble 把 lookahead 推到 END，ParseTopLevelDecls 第 0 次迭代 Seeing(END) 退出，file.decls 空。 ## 变更类型（必填） 请描述本次Pull Request变更类型（原因），**请在保存后点击复选框或在编辑时将对应项前面的 [ ] 改为 [X] 。** - [ ] 新增需求 - [x] 问题修复 - [ ] 构建过程或辅助工具变动 - [ ] 文档更新 ## 变更内容自检（必填） **请勿修改或删除以下选项内容，请在保存后点击复选框或在编辑时将对应项前面的 [ ] 改为 [X] 。** ### 平台差异情况： - [x] 不涉及 - [ ] 涉及 - [ ] Windows - [ ] Linux - [ ] macOS - [ ] 其他（请在下方说明情况） ### 影响组件： - [x] cjc（仓颉编译器） - [ ] LSP（仓颉语言服务工具） - [ ] cjfmt（仓颉格式化工具） - [ ] cjlint（仓颉静态检查工具） - [ ] stdx（仓颉扩展库） - [ ] 其他（请在下方说明情况） ### 编译本地自验证结果： - [x] 仓颉编译器编译通过 - [x] 仓颉运行时编译通过 - [x] 仓颉标准库编译通过 - [ ] 不涉及，辅助工具变动或者文档更新可以直接选择此项 ### 测试用例本地自验证结果： - [x] 通过，请在下方提供截图证明 - [ ] 不涉及，请在下方说明情况  ## 关联的issue（必填） https://gitcode.com/Cangjie/cangjie_compiler/issues/1050 See merge request: Cangjie/cangjie_compiler!2096
fix: avoid empty LD_LIBRARY_PATH entry in runtime envsetup Signed-off-by: softfault <givenyoung46@gmail.com>
fix: ffi java and objc remove cjmapping & fix java generator accessors Signed-off-by: dmitriy sokolov <sokolov.dmitriy@huawei-partners.com>
fix: correct docs for --profile-compile-time/--profile-compile-memory Signed-off-by: yanjs <yejiasheng3@huawei.com>
refactor: refector plugin checker dir Signed-off-by: Augus_Jan <zhanguozheng.829268@huawei.com>
feat: add Cangjie SDK integration build scripts and Open Source Software Notice
chore: update version to 1.3.0-alpha.03 Co-authored-by: weinw<weiningwei@h-partners.com>
feat: support plugin Signed-off-by: kangyi <kangyi9@h-partners.com>
feat: support plugin Signed-off-by: kangyi <kangyi9@h-partners.com>
feat(android): support aarch64-linux-android23 target Register the android23-aarch64 build target (aarch64-linux-android23) in build.py and align the android_aarch64_toolchain.cmake so the API 23 build reuses the existing aarch64 runtime directory layout. This enables cjc ... --target=aarch64-linux-android23 .... Also default the cjc Android API level for aarch64 (no-suffix --target=aarch64-linux-android) to API 23, matching the docs, and use the API 23 toolchain directory. The android-aarch64 target resolved to aarch64-linux-android31, while android23-aarch64 resolved to aarch64-linux-android23. They diverged only in API level, yet all downstream toolchain/toolchain-selection logic keys off the resolved triple. Make android-aarch64 resolve to aarch64-linux-android23 so both inputs produce identical behavior, unifying the default android-aarch64 build on API level 23. Additional cleanups folded in: - OptionAction.cpp: the catch-branch error message still said ">= 26" after MIN_ANDROID_API was lowered to 23; update to 23 to match the floor check. - Option.h: remove the unused DEFAULT_ANDROID_API (formerly DEFALUT_ANDROID_API) constant; it had no references and its rename carried no functional effect. Signed-off-by: zhuhaoran5 <zhuhaoran5@huawei.com>