added PRs
This commit is contained in:
parent
b3e8c22086
commit
88c849d3b0
@ -93,8 +93,19 @@ Esta trilha organiza as PRs por ondas para execucao incremental com rollback sim
|
|||||||
7. `PR-O4.7-gate-i-runtime-backed-execution-adapter.md`
|
7. `PR-O4.7-gate-i-runtime-backed-execution-adapter.md`
|
||||||
8. `PR-O4.8-jvm-grade-regression-matrix-and-golden-artifacts.md`
|
8. `PR-O4.8-jvm-grade-regression-matrix-and-golden-artifacts.md`
|
||||||
|
|
||||||
|
### Onda O5.0 - Dense Table Identity Foundation (Pre-O5)
|
||||||
|
|
||||||
|
1. `PR-05.0.1-frontend-phase-shared-name-table-context.md`
|
||||||
|
2. `PR-05.0.2-module-identity-dense-table-and-moduleid-wiring.md`
|
||||||
|
3. `PR-05.0.3-irbackend-typed-callable-and-intrinsic-ids.md`
|
||||||
|
4. `PR-05.0.4-callable-shape-and-signature-interning.md`
|
||||||
|
5. `PR-05.0.5-synthetic-stdlib-fileid-via-filetable.md`
|
||||||
|
6. `PR-05.0.6-host-binding-key-interning-and-capability-identity.md`
|
||||||
|
|
||||||
### Onda O5 - JVM-Grade Score Evolution (5.6 -> 8.5+)
|
### Onda O5 - JVM-Grade Score Evolution (5.6 -> 8.5+)
|
||||||
|
|
||||||
|
Prerequisito de execucao: concluir a Onda O5.0.
|
||||||
|
|
||||||
1. `PR-05.1-pbs-frontend-semantic-executable-lowering-cfg.md`
|
1. `PR-05.1-pbs-frontend-semantic-executable-lowering-cfg.md`
|
||||||
2. `PR-05.2-irbackend-callsite-classification-by-semantic-identity.md`
|
2. `PR-05.2-irbackend-callsite-classification-by-semantic-identity.md`
|
||||||
3. `PR-05.3-irvm-deterministic-function-id-and-entrypoint-policy.md`
|
3. `PR-05.3-irvm-deterministic-function-id-and-entrypoint-policy.md`
|
||||||
|
|||||||
@ -0,0 +1,63 @@
|
|||||||
|
# PR-05.0.1 - Frontend Phase Shared NameTable Context
|
||||||
|
|
||||||
|
## Briefing
|
||||||
|
|
||||||
|
Hoje o frontend PBS cria `NameTable` em componentes diferentes (linking, declarative semantics, rules), o que fragmenta identidade de nome por fase.
|
||||||
|
|
||||||
|
Esta PR centraliza `NameTable` no `FrontendPhaseContext` para toda a fase de frontend, com um ciclo de vida unico por compilacao.
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
### Dor que esta PR resolve
|
||||||
|
|
||||||
|
1. Mesma string pode receber `NameId` diferente dependendo da fase.
|
||||||
|
2. Dificulta evoluir para identidades tipadas cross-phase sem adaptadores de conversao.
|
||||||
|
3. Complica debug e rastreabilidade de diagnosticos semanticos entre linking e lowering.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Uniformizar identidade de nomes no FE inteiro, com `NameId` estavel durante a fase de frontend.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. `FrontendPhaseContext` passa a expor `NameTable`.
|
||||||
|
2. Validators e binders do PBS passam a receber `NameTable` do contexto, sem criar tabela local.
|
||||||
|
3. Ajuste de testes que dependem de instanciacao direta.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao altera regras semanticas.
|
||||||
|
2. Nao altera parser/AST.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Adicionar `NameTable` ao contexto da fase de frontend.
|
||||||
|
2. Remover `new NameTable()` locais em linking/semantics.
|
||||||
|
3. Injetar o `NameTable` compartilhado em:
|
||||||
|
- `PbsModuleVisibilityValidator`,
|
||||||
|
- `PbsDeclarationSemanticsValidator`,
|
||||||
|
- `PbsDeclarationRuleValidator`,
|
||||||
|
- `PbsNamespaceBinder`.
|
||||||
|
4. Garantir que o ciclo de vida da tabela seja por execucao de fase, nao global estatico.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. Nao existe mais alocacao local de `NameTable` nas fases PBS do frontend.
|
||||||
|
2. Mesmo nome gera mesmo `NameId` em linking e semantica na mesma compilacao.
|
||||||
|
3. Testes de linking/semantica continuam passando sem regressao comportamental.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Teste de identidade cruzada (linking vs declaration validation) para nomes iguais.
|
||||||
|
2. Teste de isolamento entre duas compilacoes diferentes (nao vazar IDs entre runs).
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/11. AST Specification.md`
|
||||||
|
2. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -0,0 +1,59 @@
|
|||||||
|
# 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
|
||||||
|
|
||||||
|
1. Chaves string de modulo sao repetidas e suscetiveis a inconsistencia de normalizacao.
|
||||||
|
2. Custos de hash/string crescem com o grafo de modulos.
|
||||||
|
3. Dificuldade de garantir determinismo e joins estaveis em agregacao multi-modulo.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Substituir identidade interna de modulo baseada em string por `ModuleId` internado.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. Criacao de `ModuleTable` no core.
|
||||||
|
2. Uso de `ModuleId` em `PBSFrontendPhaseService` para mapas de modulo/dependencias.
|
||||||
|
3. Adaptacao de pontos de diagnostico e exibição para renderizar nome canônico quando preciso.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao altera sintaxe de import.
|
||||||
|
2. Nao altera formato de mensagens ao usuario final alem do necessario.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Implementar `ModuleTable extends InternTable<ModuleId, ModuleRef>` (ou valor equivalente canonico).
|
||||||
|
2. Trocar `Map<String,...>` de modulo em `PBSFrontendPhaseService` por `Map<ModuleId,...>`.
|
||||||
|
3. Trocar grafo de dependencia de `String` para `ModuleId`.
|
||||||
|
4. Manter funcao unica de render de modulo para diagnostico.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. Fluxo principal do FE nao depende de `moduleKey` string para joins internos.
|
||||||
|
2. Dependencias e bloqueios por falha de modulo usam `ModuleId`.
|
||||||
|
3. Nao ha regressao funcional em linking/import gating.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Teste de determinismo de IDs de modulo para mesmo grafo admitido.
|
||||||
|
2. Teste de propagacao de falha por dependencia usando IDs.
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -0,0 +1,62 @@
|
|||||||
|
# PR-05.0.3 - IRBackend Typed Callable and Intrinsic IDs
|
||||||
|
|
||||||
|
## Briefing
|
||||||
|
|
||||||
|
O contrato `IRBackendExecutableFunction` ainda carrega `callableId`, `calleeCallableId` e `intrinsicId` como `int/Integer`.
|
||||||
|
|
||||||
|
Esta PR tipa esses campos com `CallableId` e `IntrinsicId`, alinhando model com Dense Tables e reduzindo erro de classe de ID.
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
### Dor que esta PR resolve
|
||||||
|
|
||||||
|
1. Mistura acidental entre dominios de ID diferentes em tempo de desenvolvimento.
|
||||||
|
2. Validacoes repetitivas de faixa/semantica por usar primitivo nu.
|
||||||
|
3. API de backend menos segura para evolucao de lowering/remap.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Evoluir o contrato de FE->BE para IDs tipados em vez de inteiros crus.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. `IRBackendExecutableFunction` e metadados de instrucao.
|
||||||
|
2. `IRBackendAggregator` remap de callables e intrinsecos.
|
||||||
|
3. Ajustes de serializers/tests que assumem `int`.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao muda semantica de chamada.
|
||||||
|
2. Nao muda ordenacao de remap por si so.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Trocar:
|
||||||
|
- `int callableId` -> `CallableId`,
|
||||||
|
- `Integer calleeCallableId` -> `CallableId` (nullable quando aplicavel),
|
||||||
|
- `int intrinsicId` -> `IntrinsicId`.
|
||||||
|
2. Atualizar construtores/guards para validar `.isNone()` e nao-negatividade via tipo.
|
||||||
|
3. Atualizar `IRBackendAggregator` para trabalhar com vetores/tabelas de IDs tipados.
|
||||||
|
4. Atualizar FE lowering PBS para emitir IDs tipados desde origem.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. Nao ha mais campos de callable/intrinsic ID como inteiro cru no contrato executavel.
|
||||||
|
2. Tentativas de misturar dominio de ID falham em compile-time.
|
||||||
|
3. Testes de remap e merge seguem verdes.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Testes unitarios de construcao de instrucao com tipos corretos/incorretos.
|
||||||
|
2. Testes de agregacao multi-arquivo validando remap tipado.
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -0,0 +1,62 @@
|
|||||||
|
# PR-05.0.4 - Callable Shape and Signature Interning
|
||||||
|
|
||||||
|
## Briefing
|
||||||
|
|
||||||
|
O FE ainda monta chaves semanticas por concat string (`name#arity`, `signatureSurface`, `typeShape`).
|
||||||
|
|
||||||
|
Esta PR cria internacao para superfícies de assinatura/shape e remove concatenação textual como identidade primaria.
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
### Dor que esta PR resolve
|
||||||
|
|
||||||
|
1. Chave textual e fragil para evolucao de formato.
|
||||||
|
2. Custo de alocacao/hash desnecessario em caminhos quentes.
|
||||||
|
3. Risco de colisao logica por normalizacao incompleta.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Internar shapes de callable e superfícies de assinatura em tabela dedicada, com ID estavel.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. Estruturas de assinatura do linking e lowering.
|
||||||
|
2. `CallableSignatureRef` com suporte a referencia internada de shape.
|
||||||
|
3. Remocao gradual de `callableArityKey` e derivados string.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao altera regra de overload.
|
||||||
|
2. Nao altera formato externo de diagnostico.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Introduzir tabela de shapes (ex.: `CallableShapeTable` / `TypeSurfaceTable`).
|
||||||
|
2. Representar identidade de callable por tupla tipada (`NameId`, aridade, `ShapeId`).
|
||||||
|
3. Atualizar:
|
||||||
|
- linking (`FunctionSymbolKey`),
|
||||||
|
- FE lowering executavel (`callableIdsByNameAndArity`),
|
||||||
|
- referencias em `CallableSignatureRef`.
|
||||||
|
4. Manter conversao para string apenas para logs/debug.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. Fluxo principal de resolução de callable nao depende de concat string.
|
||||||
|
2. Determinismo de shape/signature comprovado por ID internado.
|
||||||
|
3. Nenhuma regressao de resolução de overload/documentada.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Teste de internacao idempotente para shape identico.
|
||||||
|
2. Testes de distinção para shapes diferentes com mesmo nome/arity.
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -0,0 +1,59 @@
|
|||||||
|
# PR-05.0.5 - Synthetic Stdlib FileId via FileTable
|
||||||
|
|
||||||
|
## Briefing
|
||||||
|
|
||||||
|
`InterfaceModuleLoader` hoje aloca `FileId` sintetico por `AtomicInteger`.
|
||||||
|
|
||||||
|
Esta PR move a alocacao de arquivos sinteticos para o `FileTable`, mantendo uma unica autoridade de identidade de arquivo.
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
### Dor que esta PR resolve
|
||||||
|
|
||||||
|
1. Risco de colisao/deriva de `FileId` fora da infraestrutura oficial.
|
||||||
|
2. Arquivos sinteticos ficam fora da trilha normal de metadata de source.
|
||||||
|
3. Diagnosticos e spans de stdlib perdem consistencia de origem no pipeline.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Fazer todo `FileId` (incluindo sintetico) vir do `FileTable`.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. `InterfaceModuleLoader`.
|
||||||
|
2. Contexto de carga de stdlib/interface para suportar registro no `FileTable`.
|
||||||
|
3. Source handle sintetico minimo para parser/diagnostico.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao altera conteudo dos modulos stdlib.
|
||||||
|
2. Nao altera parse mode de interface.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Criar `SourceHandle` sintetico para fontes carregadas da stdlib/interface.
|
||||||
|
2. Registrar cada handle no `FileTable` e usar `FileId` retornado.
|
||||||
|
3. Remover contador `AtomicInteger` de `InterfaceModuleLoader`.
|
||||||
|
4. Preservar caminho lógico para mensagens (ex.: origem virtual stdlib).
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. `InterfaceModuleLoader` nao usa mais `new FileId(...)`.
|
||||||
|
2. Todo `FileId` de stdlib/interface existe no `FileTable`.
|
||||||
|
3. Diagnosticos em fontes sinteticas mantem atribuicao consistente.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Teste de carga de interface garantindo que `FileId` sintetico foi registrado no `FileTable`.
|
||||||
|
2. Teste de span/diagnostico para arquivo sintetico.
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/11. AST Specification.md`
|
||||||
|
2. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -0,0 +1,59 @@
|
|||||||
|
# PR-05.0.6 - Host Binding Key Interning and Capability Identity
|
||||||
|
|
||||||
|
## Briefing
|
||||||
|
|
||||||
|
A validacao de host admission ainda usa chave composta em string (`module|method|version`) para deduplicacao e consistencia.
|
||||||
|
|
||||||
|
Esta PR troca chave textual por identidade internada de binding host e prepara capacidade para validacoes mais seguras.
|
||||||
|
|
||||||
|
## Motivation
|
||||||
|
|
||||||
|
### Dor que esta PR resolve
|
||||||
|
|
||||||
|
1. Concatenacao textual para chave critica de ABI e fragil.
|
||||||
|
2. Risco de bug por normalizacao inconsistente de partes da chave.
|
||||||
|
3. Menor clareza para evoluir validacao de capabilities por dominio tipado.
|
||||||
|
|
||||||
|
## Target
|
||||||
|
|
||||||
|
Internar identidade canonica de host binding em tabela dedicada e usar ID no validador de host admission.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
1. `PbsHostAdmissionValidator`.
|
||||||
|
2. Infra de tabela de binding host no core/frontend.
|
||||||
|
3. Ajustes em metadados reservados quando necessario.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
|
||||||
|
1. Nao altera semantica de capability policy.
|
||||||
|
2. Nao altera contrato de host ABI no runtime.
|
||||||
|
|
||||||
|
## Method
|
||||||
|
|
||||||
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
|
1. Introduzir valor canônico `HostBindingRef(module,name,version)` e tabela internada.
|
||||||
|
2. Substituir map com chave string por map com `HostBindingId` (ou `HostBindingRef` internado).
|
||||||
|
3. Manter normalizacao de capability separada da identidade de binding.
|
||||||
|
4. Preservar diagnosticos com referencias claras ao binding original.
|
||||||
|
|
||||||
|
## Acceptance Criteria
|
||||||
|
|
||||||
|
1. `PbsHostAdmissionValidator` nao usa mais chave formatada por string para binding.
|
||||||
|
2. Inconsistencia de capability para mesmo binding continua detectada de forma deterministica.
|
||||||
|
3. Nao ha regressao em cenarios conhecidos de host admission.
|
||||||
|
|
||||||
|
## Tests
|
||||||
|
|
||||||
|
1. Teste de deduplicacao de binding por identidade internada.
|
||||||
|
2. Teste de mismatch de capability para mesmo binding.
|
||||||
|
|
||||||
|
## Affected Documents
|
||||||
|
|
||||||
|
1. `docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution Specification.md`
|
||||||
|
2. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
||||||
|
|
||||||
|
## Open Questions
|
||||||
|
|
||||||
|
Sem bloqueios arquiteturais.
|
||||||
@ -18,6 +18,15 @@ Esta PR substitui esse caminho por lowering semântico baseado em fluxo de contr
|
|||||||
|
|
||||||
Esta PR altera o frontend PBS para que `IRBackendExecutableFunction.instructions` represente fluxo executável real, não apenas uma lista de chamadas encontradas.
|
Esta PR altera o frontend PBS para que `IRBackendExecutableFunction.instructions` represente fluxo executável real, não apenas uma lista de chamadas encontradas.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisitos diretos:
|
||||||
|
|
||||||
|
1. `PR-05.0.1` (NameTable compartilhada por fase).
|
||||||
|
2. `PR-05.0.2` (identidade de modulo por `ModuleId`).
|
||||||
|
3. `PR-05.0.3` (IDs tipados de callable/intrinseco no contrato).
|
||||||
|
4. `PR-05.0.4` (internacao de shape/signature).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Gerador de IR executável no frontend PBS.
|
1. Gerador de IR executável no frontend PBS.
|
||||||
@ -41,6 +50,7 @@ Esta PR altera o frontend PBS para que `IRBackendExecutableFunction.instructions
|
|||||||
4. Preservar spans de origem em cada instrução emitida para diagnóstico.
|
4. Preservar spans de origem em cada instrução emitida para diagnóstico.
|
||||||
5. Manter validação fail-fast quando existir forma semântica não lowerável em v1.
|
5. Manter validação fail-fast quando existir forma semântica não lowerável em v1.
|
||||||
6. Atualizar análise de stack para operar sobre o programa realmente emitido.
|
6. Atualizar análise de stack para operar sobre o programa realmente emitido.
|
||||||
|
7. Emitir referências de chamada via IDs tipados (`CallableId`/`IntrinsicId`) sem chave textual ad-hoc.
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
@ -49,6 +59,7 @@ Esta PR altera o frontend PBS para que `IRBackendExecutableFunction.instructions
|
|||||||
3. Funções com `return` antecipado não emitem execução espúria após ponto de saída.
|
3. Funções com `return` antecipado não emitem execução espúria após ponto de saída.
|
||||||
4. `maxStackSlots` calculado bate com programa emitido e passa em validação backend.
|
4. `maxStackSlots` calculado bate com programa emitido e passa em validação backend.
|
||||||
5. Diagnósticos de lowering preservam fase e span corretamente.
|
5. Diagnósticos de lowering preservam fase e span corretamente.
|
||||||
|
6. Não há lookup de identidade de callsite baseado em concatenação string no caminho principal.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,15 @@ Esta PR torna obrigatória a classificação por identidade semântica resolvida
|
|||||||
|
|
||||||
Fronteira `PBS FE -> IRBackend` com identidade de callsite estável e sem heurística textual para decisão de categoria.
|
Fronteira `PBS FE -> IRBackend` com identidade de callsite estável e sem heurística textual para decisão de categoria.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisitos diretos:
|
||||||
|
|
||||||
|
1. `PR-05.0.1` (NameTable compartilhada).
|
||||||
|
2. `PR-05.0.2` (ModuleId no FE).
|
||||||
|
3. `PR-05.0.3` (CallableId/IntrinsicId tipados no contrato).
|
||||||
|
4. `PR-05.0.4` (shape/signature internadas).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Resultado de resolução semântica para chamadas.
|
1. Resultado de resolução semântica para chamadas.
|
||||||
@ -34,10 +43,11 @@ Fronteira `PBS FE -> IRBackend` com identidade de callsite estável e sem heurí
|
|||||||
### O que deve ser feito explicitamente
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
1. Propagar do analisador semântico para lowering um descritor explícito de destino de chamada.
|
1. Propagar do analisador semântico para lowering um descritor explícito de destino de chamada.
|
||||||
2. Remover dependência de `extractSimpleCalleeName` para classificação.
|
2. O descritor deve carregar identidade canônica tipada (ao menos categoria + id alvo), sem depender de nome textual.
|
||||||
3. Exigir que cada callsite emitido em `IRBackend` esteja em exatamente uma categoria válida.
|
3. Remover dependência de `extractSimpleCalleeName` para classificação.
|
||||||
4. Emitir erro determinístico quando o FE não possuir identidade semântica suficiente para classificar o callsite.
|
4. Exigir que cada callsite emitido em `IRBackend` esteja em exatamente uma categoria válida.
|
||||||
5. Validar compatibilidade de metadados obrigatórios por categoria no ato de emissão.
|
5. Emitir erro determinístico quando o FE não possuir identidade semântica suficiente para classificar o callsite.
|
||||||
|
6. Validar compatibilidade de metadados obrigatórios por categoria no ato de emissão.
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
@ -45,6 +55,7 @@ Fronteira `PBS FE -> IRBackend` com identidade de callsite estável e sem heurí
|
|||||||
2. Cada callsite em `IRBackend` possui categoria única e metadados obrigatórios.
|
2. Cada callsite em `IRBackend` possui categoria única e metadados obrigatórios.
|
||||||
3. Casos ambíguos geram diagnóstico estável em fase correta, sem fallback heurístico.
|
3. Casos ambíguos geram diagnóstico estável em fase correta, sem fallback heurístico.
|
||||||
4. Não há regressão em casos já válidos.
|
4. Não há regressão em casos já válidos.
|
||||||
|
5. O payload de callsite no contrato executável é tipado por ID, não por inferência textual.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,13 @@ Esta PR fecha política determinística de `func_id` e entrypoint único explíc
|
|||||||
|
|
||||||
`LowerToIRVMService` com regra única e testável de ordenação/indexação/entrypoint.
|
`LowerToIRVMService` com regra única e testável de ordenação/indexação/entrypoint.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisitos diretos:
|
||||||
|
|
||||||
|
1. `PR-05.0.2` (identidade de modulo por `ModuleId`).
|
||||||
|
2. `PR-05.0.3` (IDs tipados de callable).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Ordenação determinística de funções.
|
1. Ordenação determinística de funções.
|
||||||
@ -34,16 +41,18 @@ Esta PR fecha política determinística de `func_id` e entrypoint único explíc
|
|||||||
### O que deve ser feito explicitamente
|
### O que deve ser feito explicitamente
|
||||||
|
|
||||||
1. Definir ordenação canônica apenas pelos campos normativos aprovados.
|
1. Definir ordenação canônica apenas pelos campos normativos aprovados.
|
||||||
2. Exigir exatamente um entrypoint válido no grafo admitido.
|
2. Tornar explícita a ordenação de módulo a partir do `ModuleId` canônico.
|
||||||
3. Atribuir `func_id=0` ao entrypoint e indexar demais por ordem canônica.
|
3. Exigir exatamente um entrypoint válido no grafo admitido.
|
||||||
4. Rejeitar determinísticamente casos sem entrypoint ou com entrypoint múltiplo.
|
4. Atribuir `func_id=0` ao entrypoint e indexar demais por ordem canônica.
|
||||||
5. Cobrir cenários de permutação de entrada com mesma saída de indexação.
|
5. Rejeitar determinísticamente casos sem entrypoint ou com entrypoint múltiplo.
|
||||||
|
6. Cobrir cenários de permutação de entrada com mesma saída de indexação.
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
1. Mesma entrada admitida gera mesma tabela de `func_id` em execuções repetidas.
|
1. Mesma entrada admitida gera mesma tabela de `func_id` em execuções repetidas.
|
||||||
2. Mudança na ordem de merge dos módulos não altera indexação final.
|
2. Mudança na ordem de merge dos módulos não altera indexação final.
|
||||||
3. Ausência ou ambiguidade de entrypoint falha com diagnóstico estável.
|
3. Ausência ou ambiguidade de entrypoint falha com diagnóstico estável.
|
||||||
|
4. A ordenação não depende de string derivada não canônica de módulo.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,12 @@ Esta PR remove esses atalhos do fluxo canônico e endurece o contrato de coerên
|
|||||||
|
|
||||||
`IRVMProgram` com coerência obrigatória, sem exceção silenciosa para formas proibidas no pipeline canônico.
|
`IRVMProgram` com coerência obrigatória, sem exceção silenciosa para formas proibidas no pipeline canônico.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisito direto:
|
||||||
|
|
||||||
|
1. `PR-05.0.3` (payload de IDs tipados no contrato executável).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Regras de coerência no construtor e no `coherentEmissionPlan()`.
|
1. Regras de coerência no construtor e no `coherentEmissionPlan()`.
|
||||||
@ -43,6 +49,7 @@ Esta PR remove esses atalhos do fluxo canônico e endurece o contrato de coerên
|
|||||||
1. `IRVMProgram` nunca retorna plano incoerente no fluxo canônico.
|
1. `IRVMProgram` nunca retorna plano incoerente no fluxo canônico.
|
||||||
2. Não existe mais derivação com placeholders desconhecidos para hostcall.
|
2. Não existe mais derivação com placeholders desconhecidos para hostcall.
|
||||||
3. Erros de coerência aparecem antes da emissão binária.
|
3. Erros de coerência aparecem antes da emissão binária.
|
||||||
|
4. Coerência valida vínculos de IDs de call/intrinsic com tipo correto de domínio.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,13 @@ Esta PR passa a validar efeitos reais de stack por assinatura (`arg_slots`/`ret_
|
|||||||
|
|
||||||
`IRVMValidator` e metadados de operação com informação suficiente para calcular efeito real de stack.
|
`IRVMValidator` e metadados de operação com informação suficiente para calcular efeito real de stack.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisitos diretos:
|
||||||
|
|
||||||
|
1. `PR-05.0.3` (IDs tipados de callable/intrinseco).
|
||||||
|
2. `PR-05.0.6` (identidade canônica de host binding).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Modelo de metadados para chamadas host e intrínseco no estágio IRVM.
|
1. Modelo de metadados para chamadas host e intrínseco no estágio IRVM.
|
||||||
@ -38,12 +45,14 @@ Esta PR passa a validar efeitos reais de stack por assinatura (`arg_slots`/`ret_
|
|||||||
3. Aplicar stack effect real no data-flow do validador.
|
3. Aplicar stack effect real no data-flow do validador.
|
||||||
4. Rejeitar mismatch de altura de retorno em joins e `RET` final.
|
4. Rejeitar mismatch de altura de retorno em joins e `RET` final.
|
||||||
5. Preservar mensagens de erro estáveis na taxonomia `MARSHAL_VERIFY_PRECHECK_*`.
|
5. Preservar mensagens de erro estáveis na taxonomia `MARSHAL_VERIFY_PRECHECK_*`.
|
||||||
|
6. Consumir metadados canônicos por ID, sem lookup textual ad-hoc.
|
||||||
|
|
||||||
## Acceptance Criteria
|
## Acceptance Criteria
|
||||||
|
|
||||||
1. `HOSTCALL` e `INTRINSIC` participam do cálculo real de pilha no validador.
|
1. `HOSTCALL` e `INTRINSIC` participam do cálculo real de pilha no validador.
|
||||||
2. Casos de mismatch de assinatura falham no precheck com erro determinístico.
|
2. Casos de mismatch de assinatura falham no precheck com erro determinístico.
|
||||||
3. Casos válidos seguem aprovando sem regressão.
|
3. Casos válidos seguem aprovando sem regressão.
|
||||||
|
4. O caminho de validação não depende de composição textual de chave de binding.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,13 @@ Esta PR introduz o primeiro conjunto de passes reais, seguros e determinísticos
|
|||||||
|
|
||||||
`OptimizeIRVMService` com pass manager produtivo e baseline de passes v1.
|
`OptimizeIRVMService` com pass manager produtivo e baseline de passes v1.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisitos diretos:
|
||||||
|
|
||||||
|
1. `PR-05.0.3` (IDs tipados no contrato executável).
|
||||||
|
2. `PR-05.0.4` (shape/signature internadas).
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Pass manager determinístico com ordem estável.
|
1. Pass manager determinístico com ordem estável.
|
||||||
@ -50,6 +57,7 @@ Esta PR introduz o primeiro conjunto de passes reais, seguros e determinísticos
|
|||||||
2. Mesma entrada produz mesma saída otimizada (determinismo).
|
2. Mesma entrada produz mesma saída otimizada (determinismo).
|
||||||
3. Testes de equivalência semântica passam para fixtures representativas.
|
3. Testes de equivalência semântica passam para fixtures representativas.
|
||||||
4. Nenhum pass viola perfil de VM ou contrato de emissão.
|
4. Nenhum pass viola perfil de VM ou contrato de emissão.
|
||||||
|
5. Nenhum pass degrada identidade tipada para chave textual ad-hoc.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
@ -18,6 +18,12 @@ Esta PR separa modo dev e modo CI, tornando obrigatório runtime-backed real em
|
|||||||
|
|
||||||
Pipeline de testes com política explícita: em CI, fallback local não é aceito para Gate I.
|
Pipeline de testes com política explícita: em CI, fallback local não é aceito para Gate I.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Dependencia recomendada:
|
||||||
|
|
||||||
|
1. `PR-05.8` para registrar o status do Gate I na matriz de conformidade.
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Política de execução do adapter runtime-backed.
|
1. Política de execução do adapter runtime-backed.
|
||||||
|
|||||||
@ -18,11 +18,18 @@ Esta PR cria a matriz de rastreabilidade para `18.1`, `18.2`, `18.3`, specs `19`
|
|||||||
|
|
||||||
Artefato de conformidade auditável que mapeia requisito -> teste positivo -> teste negativo -> status.
|
Artefato de conformidade auditável que mapeia requisito -> teste positivo -> teste negativo -> status.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
Prerequisito de conteúdo:
|
||||||
|
|
||||||
|
1. Incorporar explicitamente a trilha `PR-05.0.X` como fundação de identidade/IDs.
|
||||||
|
|
||||||
## Scope
|
## Scope
|
||||||
|
|
||||||
1. Matriz normativa de backend FE/BE.
|
1. Matriz normativa de backend FE/BE.
|
||||||
2. Classificação de status por requisito (`pass`, `missing`, `partial`, `deferred`).
|
2. Classificação de status por requisito (`pass`, `missing`, `partial`, `deferred`).
|
||||||
3. Regra de atualização obrigatória da matriz em toda PR backend relevante.
|
3. Regra de atualização obrigatória da matriz em toda PR backend relevante.
|
||||||
|
4. Seção dedicada para rastrear requisitos de identidade tipada e Dense Tables.
|
||||||
|
|
||||||
## Non-Goals
|
## Non-Goals
|
||||||
|
|
||||||
@ -47,6 +54,7 @@ Artefato de conformidade auditável que mapeia requisito -> teste positivo -> te
|
|||||||
1. Todo MUST de `19`, `20`, `21` e addendum executável de `13` aparece na matriz.
|
1. Todo MUST de `19`, `20`, `21` e addendum executável de `13` aparece na matriz.
|
||||||
2. Cada item tem referência concreta a teste ou marcação explícita de ausência.
|
2. Cada item tem referência concreta a teste ou marcação explícita de ausência.
|
||||||
3. Revisão de PR consegue identificar rapidamente gaps de conformidade.
|
3. Revisão de PR consegue identificar rapidamente gaps de conformidade.
|
||||||
|
4. A matriz explicita dependência e cobertura dos itens `PR-05.0.1` a `PR-05.0.6`.
|
||||||
|
|
||||||
## Tests
|
## Tests
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user