感谢提出新需求。 | Thanks for proposing a new feature.

领域 | Domain

LSP

新需求提供了什么功能？ | What functionality does the new feature provide?

原始问题：自动导包补全项持续重复
工程结构：

• 主工程 workspace，采用 workspace 多模块配置。
• 外部依赖工程 ddd，通过 cjpm.toml 的 dependencies 引入。
• 主工程和外部依赖中都存在名为 boo 的模块。
• 外部 boo 中定义公共变量 boos。
• 在主工程 aoo 中输入 bo，LSP 自动导包补全会提供 boos，确认后生成：import boo.boos
  异常表现：

1. 第一次补全时只有一个 boos。
2. 编辑主工程内部 boo/main.cj，触发一次增量编译。
3. 回到 aoo 再输入 bo，补全列表中多出一个重复的 boos。
4. 每编辑一次内部 boo，重复项就继续增加一个。
   根因：
   根因位于增量索引的符号收集顺序。
   原实现中，SymbolCollector.cpp
   按 package.files 原始顺序处理文件：

• 属于本次增量编译路径的文件：重新收集符号。
• 不属于本次增量编译路径的文件：立即从已有索引继承符号。
  当内部、外部模块同名并被编译器组织到同一个包上下文时，可能先继承未覆盖文件的旧符号，再收集当前文件的新符号。此时用于去重的 symbolRefMap 尚未写入刷新后的 Symbol ID，因此旧符号没有被识别为已存在，重复加入 pkgSymsMap。
  每次增量编译都会再继承一次，最终表现为补全项逐次累加。

新增功能：
当 LSP 能够从实际依赖路径关系确认以下冲突时：
工作区内部模块 boo
│
└── 直接依赖外部模块 boo
会在内部 boo 模块所有 .cj 文件的 package boo 声明位置报告错误：
modules with name 'boo' in dependency tree are conflicted. If existing dependency was updated in cjpm.toml then do cjpm update
诊断属性：
category: 503
code: 503
severity: 1
source: Cangjie
range: package boo 声明范围

该需求带来的价值、应用场景？ | Value and application scenarios of the feature?

带来的价值

• LSP 与 CJPM 对当前冲突场景给出一致的根因提示。
• 用户在编辑器中即可发现依赖树冲突，不必等到执行 cjpm build。
• 修复增量索引顺序后，自动导包补全项不会随编辑次数不断增加。
• 严格依据实际依赖路径判断，不会仅因两个模块名称相同就报错。
• 没有改变已有模块命名规则，也没有禁止互不关联的模块使用相同名称。

新需求涉及的分支版本 | Branch versions involved in the new feature

• main
• release/1.0
• release/1.1
• release/1.2