Ruff项目中循环泛型类的类型推断问题分析

问题背景

在Ruff项目的Python语义分析模块中，开发团队遇到了一个关于循环泛型类类型推断的棘手问题。当处理类似class Foo[T: Foo, U: (Foo, Foo)]这样的循环泛型类定义时，系统会抛出"access to field whilst the value is being initialized"的错误。

技术细节

这个问题本质上涉及到Salsa查询系统中的循环依赖处理机制。在类型推断过程中，系统创建了一个TypeVarInstance跟踪结构体，但在后续的循环迭代中，该结构体被释放后又被错误地访问。

具体表现为：

1. 第一次执行infer_definition_types查询时，创建了TypeVarInstance(id(1400))
2. 在循环迭代中，查询重新执行，此时TypeVarInstance(id(1400))变成了输入依赖项
3. 系统随后释放了这个跟踪结构体，导致后续访问失效

根本原因

问题的核心在于Salsa查询系统中跟踪结构体的生命周期管理。当查询在循环中重新执行时，其输出变成了下一次执行的输入，形成了自引用。这种设计使得跟踪结构体的所有权管理变得复杂：

1. 查询A创建了跟踪结构体X
2. 在循环迭代中，查询A重新执行，X成为其输入依赖
3. 系统释放X，因为认为它是旧版本
4. 但查询A的执行过程中又需要访问X，导致冲突

解决方案探索

开发团队考虑了多种解决方案路径：

1. 修改Salsa核心：通过PR调整跟踪结构体的生命周期管理逻辑
2. 重构类型系统：将TypeVarInstance改为interned结构体，避免跟踪结构体的生命周期问题
3. 优化查询设计：重新设计类型推断流程，避免查询输出成为自身输入的情况

技术启示

这个问题揭示了在增量计算系统中处理循环依赖的几个重要原则：

1. 跟踪结构体应有明确的单一所有者查询
2. 循环依赖中的数据结构设计需要特别谨慎
3. 在类型系统实现中，区分可变状态和不可变状态的重要性

后续影响

该问题的解决不仅修复了循环泛型类的类型推断功能，也为Ruff项目中的其他复杂类型场景提供了参考。特别是将TypeVarInstance改为interned结构体的方案，展示了如何通过调整数据结构设计来规避系统限制。

这类问题的分析和解决过程，对于理解现代编译器/静态分析工具中的类型系统实现具有重要参考价值。