1.9 KiB
1.9 KiB
PR-05.0.2 - Module Identity Dense Table and ModuleId Wiring
Briefing
O FE usa String moduleKey em varios mapas e no handoff para backend.
Esta PR introduz identidade densa de modulo (ModuleTable + ModuleId) e faz o FE operar internamente por ID, mantendo string apenas como representacao de borda quando necessario.
Motivation
Dor que esta PR resolve
- Chaves string de modulo sao repetidas e suscetiveis a inconsistencia de normalizacao.
- Custos de hash/string crescem com o grafo de modulos.
- Dificuldade de garantir determinismo e joins estaveis em agregacao multi-modulo.
Target
Substituir identidade interna de modulo baseada em string por ModuleId internado.
Scope
- Criacao de
ModuleTableno core. - Uso de
ModuleIdemPBSFrontendPhaseServicepara mapas de modulo/dependencias. - Adaptacao de pontos de diagnostico e exibição para renderizar nome canônico quando preciso.
Non-Goals
- Nao altera sintaxe de import.
- Nao altera formato de mensagens ao usuario final alem do necessario.
Method
O que deve ser feito explicitamente
- Implementar
ModuleTable extends InternTable<ModuleId, ModuleRef>(ou valor equivalente canonico). - Trocar
Map<String,...>de modulo emPBSFrontendPhaseServiceporMap<ModuleId,...>. - Trocar grafo de dependencia de
StringparaModuleId. - Manter funcao unica de render de modulo para diagnostico.
Acceptance Criteria
- Fluxo principal do FE nao depende de
moduleKeystring para joins internos. - Dependencias e bloqueios por falha de modulo usam
ModuleId. - Nao ha regressao funcional em linking/import gating.
Tests
- Teste de determinismo de IDs de modulo para mesmo grafo admitido.
- Teste de propagacao de falha por dependencia usando IDs.
Affected Documents
docs/pbs/specs/13. Lowering IRBackend Specification.mddocs/general/specs/20. IRBackend to IRVM Lowering Specification.md
Open Questions
Sem bloqueios arquiteturais.