#2207 跨语言的Stub 重连: 尚未解决的基类Stub 可以绑定到不同语言中的无关节点

□ 总结

rewire unique stub nodes' inextract.py'可以悄悄地将一个未解决的同义词"stub"节点(例如没有本地定义的继承目标)再接到不同语言的完全无关的节点,只要标签恰好吻合,而且整个体中任何地方还有一个"真正的"候选人. 这会产生虚假的跨语言边缘,并且可以将一个不相干的变量变成人造的"神之节点"桥接社区,这些社区彼此无关.

□ 重现

重传/
后端/ 模式. py
前端/ widget. test.tsx

后端/型号。 py : [Python] 从 sqlalchemy.orm 导入声明碱

Base = 声明 base () # 不是‘类'语句,所以它从未注册为"真实"定义.

类用户( Base) : 表名 ="用户"


“前端/前端.tsx”:
时间轴 :
const base = { id: 1, 名称:"test"};

测试( “提交” ), () {{{}
渲染( < Widget acject %base} / > );
* ;

运行 :

从图解中取出。提取导入摘要
从 pathlib 导入路径

结果=取出 ([Path ("后端/模型.py"),Path ("前端/widget.test.tsx")],缓存 root=Path ("""").
print ([e for e in results ["edges"] 如果e ["来源"]"后端 模型 用户"和e ["关系"]"内生").

** 预计:** 未解决的 " 基准 " 符号的 " 继承 " 边缘从 " 用户 " 到一些Python唯一的占位符(或至少不是TS变量)。

** 实际:**

[{'来源':"后端 模型 用户","目标":"前端 widget test base","关系":"固有",".]

用户'现在似乎从.tsx'文件中的当地测试固定物体中“继承”。单独取出 " 后端/模型.py " (没有.tsx ' 文件)就正确产生了目标 " base " (一个赤裸而未解决的占位符) -- -- 只有在两个文件一起取出时才会显示错误,因为rewire unique stub nodes ' 一次贯穿整个实体。

在真实的~530-文件混合的Python/TypeScript单体上,这个确切的模式变成了一个报告的"god node"/跨社区桥:~90 不相干的SQLAlchemy ORM模型类似乎都继承于一个前端Jest/Vites测试的本地‘cost base = {. }` fix fix fix purely purely purely purely purely purely purely purely fix fix fix corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus * corpus corpus * corpus corpus corpus corpus corpus corpus corpus corpus corpus corpus

□ 根源

extract.py',rewire unique stub nodes' (约L7070起为`graphify'0.8.38起):

def  rewire unique stub nodes(节点:列表[dit],边缘:列表[dit]-] 无:
"""将未解决的无源活字标到一个具有同名标签的独特真实定义"".
real by  label: dict[str, list[dit]]=           
ub:列表[dit]= []

对于节点:
键 =   节点  label  key(节点)
如果不是密钥 :
继续
如果节点.get("source file"):
如果  is type like 定义(节点) :
real by  label. setdefault( key, []). 附录(节点)
继续
. . . . . . .