clean up
This commit is contained in:
parent
54045bb898
commit
a5769cf980
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -1,37 +0,0 @@
|
|||||||
# PR-032 - Backend BytecodeModule Serializer Baseline
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Implementar a base de marshaling binario de `BytecodeModule` no compilador, alinhada ao contrato v1 de `const_pool`, `functions`, `code`, `exports`, `syscalls` e secao `SYSC` obrigatoria.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Criar modelo interno de emissao de `BytecodeModule` no backend Java.
|
|
||||||
- Implementar serializacao little-endian com tabela de secoes deterministica.
|
|
||||||
- Garantir `SYSC` sempre presente no artefato pre-load, inclusive vazia.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Introduzir pacote backend de bytecode com modelos equivalentes aos campos normativos da spec 15.
|
|
||||||
- Implementar serializer com layout de header e secoes deterministico.
|
|
||||||
- Introduzir erros deterministas de formato (`MARSHAL_FORMAT_*`) para falhas detectaveis antes da escrita final.
|
|
||||||
- Referenciar comportamento-alvo dos contratos existentes em `../runtime/crates/console/prometeu-bytecode/src/model.rs`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. O backend serializa `BytecodeModule` sempre em little-endian.
|
|
||||||
2. A secao `SYSC` e sempre emitida.
|
|
||||||
3. Mesma entrada produz bytes identicos.
|
|
||||||
4. Erros de formato em dados invalidos sao deterministicos e estaveis.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario de serializacao minima (sem syscalls) com `SYSC` vazio presente.
|
|
||||||
2. Teste unitario de determinismo de bytes para mesma entrada.
|
|
||||||
3. Teste unitario de rejeicao `MARSHAL_FORMAT_*` para dados malformados detectaveis no emitter.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
||||||
- `docs/general/specs/19. Verification and Safety Checks Specification.md`
|
|
||||||
|
|
||||||
@ -1,37 +0,0 @@
|
|||||||
# PR-033 - Backend Function Layout and Debug Minimum
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Implementar o builder de layout final de funcoes (`code_offset`, `code_len`) e o contrato minimo de debug (`function_names`, `pc_to_span`) antes de integrar com stages do pipeline.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Construir flatten deterministico de codigo por funcao.
|
|
||||||
- Preencher `functions[]` com offsets/len coerentes.
|
|
||||||
- Preencher `debug_info` minimo v1.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Adicionar um layout builder que recebe codigo por funcao e produz `code` unico.
|
|
||||||
- Garantir `code_offset` monotonicos e unicos.
|
|
||||||
- Garantir `code_len` exato por funcao.
|
|
||||||
- Gerar `debug_info.function_names` e `debug_info.pc_to_span` no momento de materializacao final.
|
|
||||||
- Seguir invariantes de consumo do runtime (`ProgramImage` e verifier).
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. `code_offset + code_len` de cada funcao fica dentro de `code.len`.
|
|
||||||
2. Ordem de flatten e offsets sao deterministicos.
|
|
||||||
3. `function_names` contem todos os `func_idx` emitidos.
|
|
||||||
4. `pc_to_span` cobre cada inicio de instrucao emitida.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario de layout com multiplas funcoes.
|
|
||||||
2. Teste unitario de limites invalidos rejeitados deterministicamente.
|
|
||||||
3. Teste unitario de cobertura de debug minimo.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
||||||
|
|
||||||
@ -1,39 +0,0 @@
|
|||||||
# PR-034 - Backend Emitter HOSTCALL and SYSC Contract
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Fechar o contrato de emissao host-backed e intrinsic no emitter: deduplicacao canonica de `SYSC`, ordenacao por primeira ocorrencia, `HOSTCALL` em pre-load e rejeicao de `SYSCALL` bruto.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Implementar materializacao de `syscalls` no artefato.
|
|
||||||
- Implementar map `host binding -> sysc_index`.
|
|
||||||
- Preservar caminho de `INTRINSIC` distinto de host.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Deduplicar `SYSC` por `(module,name,version)` e manter ordem da primeira ocorrencia.
|
|
||||||
- Emitir chamadas host-backed como `HOSTCALL <sysc_index>`.
|
|
||||||
- Rejeitar candidatas que contenham `SYSCALL` em imagem pre-load (`MARSHAL_LINKAGE_*`).
|
|
||||||
- Validar mismatch detectavel de ABI (`arg_slots`, `ret_slots`) com metadado de compilacao.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. `SYSC` deduplicado e ordenado por primeira ocorrencia.
|
|
||||||
2. Nao existe `SYSCALL` bruto no artefato pre-load emitido.
|
|
||||||
3. Caminho intrinsic nao polui `SYSC`.
|
|
||||||
4. Falhas de linkage sao deterministicas.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste positivo com chamadas host repetidas gerando um unico `SYSC`.
|
|
||||||
2. Teste negativo de `SYSCALL` bruto no pre-load.
|
|
||||||
3. Teste negativo de mismatch ABI em host binding.
|
|
||||||
4. Teste positivo de intrinsic sem entradas em `SYSC`.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
||||||
- `docs/general/specs/19. Verification and Safety Checks Specification.md`
|
|
||||||
- `docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution Specification.md`
|
|
||||||
|
|
||||||
@ -1,37 +0,0 @@
|
|||||||
# PR-035 - EmitBytecode Stage Pipeline Wiring
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Integrar o emitter ao pipeline real: `EmitBytecodePipelineStage` deixa de ser stub e passa a receber `IRVM` otimizado, executar checks de marshaling e produzir bytes finais no contexto do build.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Atualizar `BuilderPipelineContext` com superficies de saida de backend (`irvm`, `optimizedIrvm`, `bytecodeModule`, `bytecodeBytes`).
|
|
||||||
- Implementar `EmitBytecodePipelineStage`.
|
|
||||||
- Registrar falhas de emissao em `BuildingIssueSink`.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Introduzir service de emissao usado pela stage.
|
|
||||||
- Fazer a stage validar precondicoes (`optimizedIrvm` presente, sem opcodes internos restantes).
|
|
||||||
- Persistir resultado no contexto para fases posteriores/consumo externo.
|
|
||||||
- Propagar codigos deterministas `MARSHAL_*` em diagnosticos de build.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. Stage falha deterministicamente quando precondicoes nao sao satisfeitas.
|
|
||||||
2. Stage produz `bytecodeBytes` para entradas validas.
|
|
||||||
3. Stage nao depende de packer.
|
|
||||||
4. Integracao da stage nao altera ordem canonica do pipeline.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario da stage com input valido.
|
|
||||||
2. Teste unitario da stage sem `optimizedIrvm`.
|
|
||||||
3. Teste unitario da stage com opcode interno nao eliminado.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
||||||
- `docs/general/specs/21. IRVM Optimization Pipeline Specification.md`
|
|
||||||
|
|
||||||
@ -1,42 +0,0 @@
|
|||||||
# PR-036 - Backend IRVM Core Model and Validator
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Criar o modelo `IRVM` quase-ISA e validador estrutural compile-time, base para `LowerToIRVM`, `OptimizeIRVM` e `EmitBytecode`.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Introduzir tipos de `IRVM` (modulo, funcao, instrucao, operandos, labels).
|
|
||||||
- Suportar opcodes Core ISA e opcodes internos (`IRVM_EXT`) com metadados obrigatorios.
|
|
||||||
- Implementar validacao estrutural minima de controle/pilha/calls.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Criar API de instrucao com `pops`, `pushes`, `is_branch`, `is_terminator`.
|
|
||||||
- Implementar verificador de fronteira compiler-side:
|
|
||||||
- alvo de salto valido,
|
|
||||||
- join de stack consistente,
|
|
||||||
- underflow/overflow,
|
|
||||||
- retorno coerente com `return_slots`,
|
|
||||||
- validade de `func_id`.
|
|
||||||
- Definir contrato de serializacao bloqueando `IRVM_EXT` na fronteira de emissao.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. `IRVM` suporta representacao de Core ISA e extensoes internas eliminaveis.
|
|
||||||
2. Validador detecta inconsistencias estruturais requeridas pela spec 20.
|
|
||||||
3. Falhas sao deterministicas e categorizadas como `MARSHAL_VERIFY_PRECHECK_*` quando aplicavel.
|
|
||||||
4. Resultado do validador pode ser consumido por stages de optimize/emissao.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario para salto invalido e salto para meio de instrucao.
|
|
||||||
2. Teste unitario para mismatch de stack em join.
|
|
||||||
3. Teste unitario para retorno com shape invalido.
|
|
||||||
4. Teste unitario para `IRVM_EXT` residual bloqueando emissao.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
|
||||||
- `docs/general/specs/19. Verification and Safety Checks Specification.md`
|
|
||||||
|
|
||||||
@ -1,37 +0,0 @@
|
|||||||
# PR-037 - OptimizeIRVM No-op Stage and Guards
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Implementar `OptimizeIRVMPipelineStage` com baseline no-op deterministico, preservando contratos semanticos e adicionando guardas obrigatorias antes da emissao.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Implementar stage real de otimizacao no pipeline.
|
|
||||||
- Garantir preservacao de semantica, slots e determinismo para a baseline.
|
|
||||||
- Preparar superficie para passes futuros sem quebrar contrato.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Criar service `OptimizeIRVMService` com pass manager inicial contendo pass no-op.
|
|
||||||
- Executar validacao pre e pos-pass para garantir equivalencia estrutural minima.
|
|
||||||
- Garantir que a saida segue compativel com `vm_profile` alvo.
|
|
||||||
- Publicar `optimizedIrvm` no `BuilderPipelineContext`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. Pipeline executa `LowerToIRVM -> OptimizeIRVM -> EmitBytecode`.
|
|
||||||
2. Com mesma entrada, saida otimizada e deterministica.
|
|
||||||
3. Stage falha deterministicamente para violacoes de contrato.
|
|
||||||
4. Stage pode operar como no-op sem ser pulada.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario de pass no-op preservando estrutura e metadados.
|
|
||||||
2. Teste unitario de rejeicao quando pass introduz forma fora do profile.
|
|
||||||
3. Teste unitario de integracao da ordem de stages no `BuilderPipelineService`.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/21. IRVM Optimization Pipeline Specification.md`
|
|
||||||
- `docs/pbs/decisions/IRVM Optimization Stage Placement Decision.md`
|
|
||||||
|
|
||||||
@ -1,39 +0,0 @@
|
|||||||
# PR-038 - IRBackend v2 Executable Contract Model
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Evoluir `IRBackend` para contrato executavel v2, adicionando corpo lowerable, classificacao de callsites e metadado canonico para host/intrinsic sem heuristica textual no backend.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Expandir modelos em `prometeu-frontend-api` para incluir:
|
|
||||||
- callable identity estavel,
|
|
||||||
- corpo lowerable,
|
|
||||||
- callsites com categoria explicita (`CALL_FUNC`, `CALL_HOST`, `CALL_INTRINSIC`),
|
|
||||||
- metadado canonico host/intrinsic por callsite.
|
|
||||||
- Preservar compatibilidade de agregacao e ordenacao deterministica.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Introduzir novas records/classes v2 e adaptar agregador de `IRBackend`.
|
|
||||||
- Manter fronteira clara entre metadado reservado global e metadado operacional por callsite.
|
|
||||||
- Introduzir chave deterministica de ordenacao de funcao: `(module_key, callable_name, source_start)`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. `IRBackend` v2 carrega informacao suficiente para `LowerToIRVM` sem heuristica textual.
|
|
||||||
2. Cada callsite executavel pertence a exatamente uma categoria.
|
|
||||||
3. Identidade canonica host/intrinsic fica preservada por callsite.
|
|
||||||
4. Agregacao multi-arquivo continua deterministica.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Testes unitarios de modelo para classificacao de callsites.
|
|
||||||
2. Testes unitarios de agregacao deterministica de funcoes.
|
|
||||||
3. Testes unitarios de preservacao de metadados host/intrinsic.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
|
||||||
- `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
|
||||||
|
|
||||||
@ -1,37 +0,0 @@
|
|||||||
# PR-039 - PBS Frontend Lowering to IRBackend v2
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Atualizar o frontend PBS para emitir `IRBackend` v2 executavel, incluindo corpo lowerable e classificacao de chamadas conforme contrato normativo da agenda 18.1.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Atualizar `PbsFrontendCompiler` e servicos correlatos para emitir IR v2.
|
|
||||||
- Materializar callsites classificados no lowering frontend.
|
|
||||||
- Preservar ancoras de fonte por instrucao/callsite para diagnostico backend.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Extrair do AST/semantica as operacoes necessarias ao corpo lowerable.
|
|
||||||
- Mapear chamadas para `CALL_FUNC`/`CALL_HOST`/`CALL_INTRINSIC`.
|
|
||||||
- Anexar metadado canonico de host/intrinsic por callsite com validacao de coerencia.
|
|
||||||
- Preservar fail-fast dependency-scoped ja existente na agregacao.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. Frontend PBS produz `IRBackend` v2 para modulos executaveis.
|
|
||||||
2. Chamadas host/intrinsic saem classificadas e com metadado canonico.
|
|
||||||
3. Diagnosticos permanecem deterministicos e com atribuicao de fonte.
|
|
||||||
4. SDK interface continua sem emissao de corpo executavel quando aplicavel.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Testes de frontend para classificacao correta de callsites.
|
|
||||||
2. Testes negativos para metadado reservado invalido.
|
|
||||||
3. Testes de regressao para fail-fast em modulos dependentes.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/pbs/specs/13. Lowering IRBackend Specification.md`
|
|
||||||
- `docs/general/specs/13. Conformance Test Specification.md`
|
|
||||||
|
|
||||||
@ -1,41 +0,0 @@
|
|||||||
# PR-040 - LowerToIRVM Stage Implementation
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Implementar `LowerToIRVMPipelineStage` real, convertendo `IRBackend` v2 em `IRVM` com IDs deterministicos, lowering de controle de fluxo e lowering de chamadas compativel com runtime/ISA.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Implementar service de lowering `IRBackend -> IRVM`.
|
|
||||||
- Implementar atribuicao deterministica de `func_id` com entrypoint em `0`.
|
|
||||||
- Resolver labels para offsets `u32` relativos ao inicio da funcao.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Ordenar funcoes por regra normativa `(module_key, callable_name, source_start)` com entrypoint fixo.
|
|
||||||
- Lowering de chamadas:
|
|
||||||
- `CALL_FUNC -> CALL <func_id>`,
|
|
||||||
- `CALL_HOST -> HOSTCALL <sysc_index>`,
|
|
||||||
- `CALL_INTRINSIC -> INTRINSIC <id>`.
|
|
||||||
- Aplicar pre-verificacao estrutural obrigatoria antes de publicar `irvm` no contexto.
|
|
||||||
- Registrar falhas com familias de erro deterministas.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. Stage produz `IRVM` valido para entradas admitidas.
|
|
||||||
2. Mapeamento de funcao e callsite e deterministico.
|
|
||||||
3. Labels nao resolvidas e saltos invalidos sao rejeitados deterministicamente.
|
|
||||||
4. Stage preenche `ctx.irvm` para consumo da etapa `OptimizeIRVM`.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. Teste unitario de ordenacao deterministica de funcoes.
|
|
||||||
2. Teste unitario de lowering de callsites por categoria.
|
|
||||||
3. Teste unitario de rejeicao para fluxo nao terminado.
|
|
||||||
4. Teste unitario de offsets de salto relativos ao inicio da funcao.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
|
|
||||||
- `docs/general/specs/19. Verification and Safety Checks Specification.md`
|
|
||||||
|
|
||||||
@ -1,45 +0,0 @@
|
|||||||
# PR-041 - Backend Gate I Runtime Compatibility Fixtures
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Fechar a evidencia de integracao executavel com fixtures Gate I cobrindo os cenarios normativos da agenda 18.3, sem depender de packer.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Criar suite de integracao para `LowerToIRVM -> OptimizeIRVM -> EmitBytecode`.
|
|
||||||
- Cobrir cenarios positivos e negativos de loader/verifier esperados.
|
|
||||||
- Publicar status S-I (`pass` ou `deferred`) com evidencia reproduzivel.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Construir fixtures que validam o artefato emitido e suas falhas esperadas.
|
|
||||||
- Alinhar cenarios com erros observados no runtime em:
|
|
||||||
- `../runtime/crates/console/prometeu-vm/src/virtual_machine/loader.rs`,
|
|
||||||
- `../runtime/crates/console/prometeu-vm/src/verifier.rs`,
|
|
||||||
- `../runtime/crates/console/prometeu-vm/src/vm_init_error.rs`.
|
|
||||||
- Padronizar assertions nas familias `MARSHAL_FORMAT_*`, `MARSHAL_LINKAGE_*`, `MARSHAL_VERIFY_PRECHECK_*`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
1. Fixture cobre os 8 cenarios minimos definidos em 18.3.
|
|
||||||
2. Resultados sao deterministicos entre execucoes.
|
|
||||||
3. Pelo menos um caminho positivo produz artefato inicializavel no runtime alvo.
|
|
||||||
4. Suite independe de packer.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
1. `SYSC` presente e vazio.
|
|
||||||
2. `HOSTCALL` valido com patch esperado.
|
|
||||||
3. `HOSTCALL` fora de faixa.
|
|
||||||
4. `SYSC` declarado e nao usado.
|
|
||||||
5. `SYSCALL` bruto em pre-load.
|
|
||||||
6. Mismatch ABI de host.
|
|
||||||
7. Capability insuficiente.
|
|
||||||
8. Caminho `INTRINSIC` valido.
|
|
||||||
|
|
||||||
## Affected Documents
|
|
||||||
|
|
||||||
- `docs/general/specs/19. Verification and Safety Checks Specification.md`
|
|
||||||
- `docs/general/specs/13. Conformance Test Specification.md`
|
|
||||||
- `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
|
|
||||||
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O1.1 - Backend Diagnostics Taxonomy and Attribution
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Fechar lacunas de consistencia diagnostica no backend executavel, padronizando familias de erro (`MARSHAL_FORMAT_*`, `MARSHAL_LINKAGE_*`, `MARSHAL_VERIFY_PRECHECK_*`) e regras minimas de atribuicao de fonte quando o erro for acionavel pelo usuario.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `prometeu-compiler/prometeu-build-pipeline` (stages e servicos de lowering/optimize/emit).
|
|
||||||
- Contratos de excecao/codigos de erro no backend.
|
|
||||||
- Mapeamento de falhas para mensagens estaveis no pipeline.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Consolidar codigos de erro de backend em taxonomia unica e estavel.
|
|
||||||
- Garantir que erros source-atribuiveis propaguem `fileId/span` quando disponivel no `IRBackend`.
|
|
||||||
- Alinhar mensagens de stage para manter determinismo de identificacao entre execucoes.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Falhas de backend relevantes caem em uma das 3 familias normativas.
|
|
||||||
- O mesmo input gera o mesmo `error code` e mesma fase reportada.
|
|
||||||
- Erros source-atribuiveis carregam ancora primaria de fonte.
|
|
||||||
- Gate de build nao mascara codigo original do erro backend.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Unit tests para mapeamento de excecoes em cada stage (`LowerToIRVM`, `OptimizeIRVM`, `EmitBytecode`).
|
|
||||||
- Fixtures negativos garantindo estabilidade de `code`/fase/mensagem base.
|
|
||||||
- Caso com span disponivel validando atribuicao no diagnostico final.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O1.2 - IRBackend Executable Contract Hardening
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Endurecer o contrato de entrada do backend (`IRBackendExecutableFunction`) para reduzir ambiguidade e rejeitar estados inconsistentes antes de `LowerToIRVM`.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `prometeu-compiler/prometeu-frontend-api` (`IRBackend`, `IRBackendExecutableFunction`).
|
|
||||||
- Validacoes de construcao do modelo executavel.
|
|
||||||
- Testes de contrato de modelo na API.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Adicionar validacoes estruturais obrigatorias (identidade, slots, limites e metadados minimos por instrucao).
|
|
||||||
- Tornar explicita a politica para campos em branco (`moduleKey`, nomes de callsites, metadado host/intrinsic).
|
|
||||||
- Rejeitar estados impossiveis no proprio modelo, nao no emissor tardio.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Modelo recusa funcoes/instrucoes com combinacoes invalidas de campos.
|
|
||||||
- Contrato de `CALL_FUNC`/`CALL_HOST`/`CALL_INTRINSIC` fica mutuamente exclusivo e completo.
|
|
||||||
- Campos de slot/stack nao aceitam valores negativos.
|
|
||||||
- Testes de contrato cobrem casos validos e invalidos deterministas.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- `IRBackendExecutableContractTest` ampliado para validacoes novas.
|
|
||||||
- Testes de construtor para cada kind de instrucao com metadados obrigatorios.
|
|
||||||
- Testes de regressao para aceitar payloads validos atuais.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O1.3 - PBS Executable Lowering Fidelity
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Elevar fidelidade do lowering executavel no frontend PBS para garantir classificacao correta de callsites e eliminacao de heuristicas que possam produzir `callee` ambiguo (`<unknown>`) no `IRBackend`.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `prometeu-compiler/frontends/prometeu-frontend-pbs` (`PbsFrontendCompiler`).
|
|
||||||
- Coleta/travessia de callsites em blocos/expressoes compostas.
|
|
||||||
- Integracao com metadado reservado host/intrinsic.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Revisar travessia de AST para callsites com foco em completude e null-safety.
|
|
||||||
- Substituir fallback ambiguo por rejeicao diagnostica deterministica quando identidade nao puder ser resolvida.
|
|
||||||
- Garantir ordenacao deterministica de instrucoes coletadas para o mesmo AST admitido.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Frontend nao emite callsite executavel com callee ambiguo.
|
|
||||||
- Chamadas host/intrinsic sao classificadas sem heuristica textual fragil.
|
|
||||||
- Coleta de callsites em `if/switch/handle/block expr` permanece deterministica.
|
|
||||||
- Casos sem resolucao de identidade falham com diagnostico estavel.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Novos testes em `PbsFrontendCompilerTest` para callsites complexos.
|
|
||||||
- Regressao para `handle/switch` com blocos terminais.
|
|
||||||
- Fixture negativa para callee nao-resolvido no lowering executavel.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O1.4 - LowerToIRVM Callsite Prechecks
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Implementar prechecks obrigatorios de chamada em `LowerToIRVM` (consistencia de assinatura/slots e validade de destino) para cumprir integralmente o contrato de verificacao pre-emissao.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `prometeu-compiler/prometeu-build-pipeline` (`LowerToIRVMService`, `IRVMValidator`).
|
|
||||||
- Taxonomia de erros de lowering/verificacao.
|
|
||||||
- Testes unitarios de lowering negativo.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Introduzir validacao de aridade/shape de retorno em `CALL_FUNC` usando metadados das funcoes alvo.
|
|
||||||
- Rejeitar inconsistencias de chamada antes do emissor.
|
|
||||||
- Preservar determinismo de `func_id` e diagnostico para falhas de precheck.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- `CALL_FUNC` invalido por contrato de slots falha no `LowerToIRVM` com codigo estavel.
|
|
||||||
- Falhas de callsite nao avancam para `EmitBytecode`.
|
|
||||||
- Verificador cobre func-id, stack e contrato de chamada no mesmo passe.
|
|
||||||
- Testes existentes de lowering continuam verdes.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Novos testes em `LowerToIRVMServiceTest` para mismatch de param/ret slots.
|
|
||||||
- Regressao para caminho valido com host/intrinsic.
|
|
||||||
- Teste de estabilidade de codigo de erro para mesma entrada invalida.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O1.5 - Bytecode Debug Minimum Completeness
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Garantir conformidade integral com o minimo de debug v1: `function_names` para todas as funcoes e `pc_to_span` para todo inicio de instrucao emitida.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `BytecodeEmitter` e `BytecodeFunctionLayoutBuilder`.
|
|
||||||
- Estrutura `BytecodeModule.DebugInfo`.
|
|
||||||
- Testes de emissao/debug.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Registrar spans de todas as instrucoes emitidas (nao apenas host/intrinsic).
|
|
||||||
- Definir fallback deterministico para instrucoes sem span source-especifico.
|
|
||||||
- Validar que toda funcao emitida possui nome em `function_names`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- `pc_to_span` cobre 100% dos instruction starts do modulo emitido.
|
|
||||||
- `function_names` cobre 100% dos `func_idx`.
|
|
||||||
- Falha de integridade de debug e detectada antes da serializacao final.
|
|
||||||
- Output permanece deterministico entre execucoes.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes em `BytecodeFunctionLayoutBuilderTest` e `BytecodeEmitterTest` para cobertura completa de PCs.
|
|
||||||
- Fixture com multiplas funcoes e misto de opcodes.
|
|
||||||
- Teste negativo para span fora de faixa.
|
|
||||||
@ -1,29 +0,0 @@
|
|||||||
# PR-O1.6 - Gate S-U Safety Matrix Completion
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Fechar cobertura minima de seguranca em testes unitarios por stage (`LowerToIRVM`, `OptimizeIRVM`, `EmitBytecode`) conforme especificacao de verificacao/safety.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Suite de testes do modulo `prometeu-build-pipeline`.
|
|
||||||
- Evidencia Gate S-U para casos positivos e negativos deterministas.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Consolidar matriz de casos obrigatorios por stage.
|
|
||||||
- Cobrir invariantes de determinismo, precheck estrutural e rejeicoes normativas.
|
|
||||||
- Garantir que cada familia de erro relevante tenha pelo menos um fixture dedicado.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Gate S-U cobre os checks minimos exigidos pela spec 19.
|
|
||||||
- Cada stage possui testes de sucesso e falha com codigos estaveis.
|
|
||||||
- Pipeline order e contratos de fronteira permanecem testados.
|
|
||||||
- Nao ha `deferred` em checks S-U obrigatorios para backend executavel.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Expansao de `LowerToIRVMServiceTest`, `IRVMValidatorTest`, `OptimizeIRVMPipelineStageTest`, `EmitBytecodePipelineStageTest`.
|
|
||||||
- Testes deterministas (mesmo input, mesmo output/erro).
|
|
||||||
- Tabela de cobertura Gate S-U documentada em assertions/fixures.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O2.1 - Bytecode Link Precheck Stage (JVM-Inspired)
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Adicionar etapa de precheck de linkagem do artefato emitido, separando responsabilidades de formatacao e vinculacao (inspirado no modelo JVM de fronteiras claras).
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Novo servico/stage de precheck apos emissao.
|
|
||||||
- Validacoes de referencias cruzadas em `BytecodeModule` (`functions`, `code`, `exports`, `syscalls`).
|
|
||||||
- Integracao no pipeline sem alterar autoridade do runtime.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Implementar verificador leve de consistencia de indices/offsets no artefato pre-load.
|
|
||||||
- Validar referencias de export, limites de funcao e uso de `sysc_index`.
|
|
||||||
- Manter determinismo de erro e taxonomia `MARSHAL_VERIFY_PRECHECK_*`.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Artefatos malformados por linkagem interna falham antes de handoff externo.
|
|
||||||
- Rejeicoes sao estaveis e reproduziveis.
|
|
||||||
- Stage e opcional por feature flag, mas habilitado no perfil normativo.
|
|
||||||
- Nenhuma sobreposicao com validacoes que sao exclusivamente do runtime.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes unitarios do novo verificador com casos de offsets/indices invalidos.
|
|
||||||
- Testes de pipeline garantindo execucao da etapa na ordem correta.
|
|
||||||
- Regressao para artefatos validos atualmente emitidos.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O2.2 - Bytecode Preload Verifier (JVM-Inspired)
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Introduzir verificador estrutural de pre-load no compilador para antecipar rejeicoes triviais e fortalecer qualidade de artefato antes de runtime.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Novo componente de verificacao estrutural em `prometeu-build-pipeline`.
|
|
||||||
- Regras de controle de fluxo/stack no artefato (quando observaveis no pre-load).
|
|
||||||
- Integração com Gate S-U/S-I.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Definir subconjunto de verificacoes que o compilador pode garantir sem substituir o verifier oficial do runtime.
|
|
||||||
- Reusar taxonomia de erros de precheck.
|
|
||||||
- Garantir que o verificador rode de modo deterministico e sem heuristicas dependentes de ambiente.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Verificador captura classes de erro estruturais detectaveis localmente.
|
|
||||||
- Rejeicoes compilador e runtime convergem para os casos de intersecao.
|
|
||||||
- Falhas nao mascaram erros anteriores de lowering/emissao.
|
|
||||||
- Overhead de execucao permanece controlado (baseline no-op em casos validos).
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Fixtures com bytecode invalido estruturalmente (stack/control-flow simplificado).
|
|
||||||
- Regressao com artefatos validos cobrindo hostcall/intrinsic.
|
|
||||||
- Teste de estabilidade de codigos e mensagens base.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O2.3 - OptimizeIRVM Pass Manager and Equivalence Harness
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Evoluir `OptimizeIRVM` de no-op para estrutura de pass manager deterministica, mantendo preservacao semantica e compatibilidade de perfil.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `OptimizeIRVMService`.
|
|
||||||
- Infraestrutura de registro/execucao de passes.
|
|
||||||
- Suite de equivalencia entre pipeline otimizado vs baseline.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Criar contrato de pass (`name`, `enabled`, `apply`, validacao pos-pass).
|
|
||||||
- Manter no-op como pass default, mas com trilha para adicao incremental de passes reais.
|
|
||||||
- Adicionar harness de regressao comparando invariantes de saida e comportamento esperado.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Pipeline suporta multiplos passes com ordem deterministica.
|
|
||||||
- Cada pass roda sob validacao estrutural pre e pos.
|
|
||||||
- Saida otimizada preserva contratos de slots/calls/profile.
|
|
||||||
- Existe suite de equivalencia minima para impedir regressao semantica.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes de pass manager (ordem, habilitacao, falha curta).
|
|
||||||
- Testes de equivalencia entre `OptimizeIRVM` ativo vs no-op.
|
|
||||||
- Regressao de perfil invalido e determinismo de output.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O2.4 - Gate I Runtime-Backed Compatibility Harness
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Trocar verificador mock de integracao por harness aderente ao runtime line alvo, mantendo os cenarios normativos de Gate I e evidencias repetiveis.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Testes de integracao backend (`BackendGateIIntegrationTest` e correlatos).
|
|
||||||
- Adaptador para checagem realista de compatibilidade de pre-load.
|
|
||||||
- Vinculacao explicita com runtime line suportado.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Encapsular checagem de compatibilidade em adaptador substituivel (mock/local/runtime-backed).
|
|
||||||
- Preservar cenarios minimos normativos (hostcall valido, OOB, unused SYSC, raw syscall, ABI mismatch, capability, intrinsic).
|
|
||||||
- Registrar runtime line e perfil usados nos testes para rastreabilidade.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Gate I deixa de depender exclusivamente de checador interno ad-hoc.
|
|
||||||
- Suite segue estavel e reproduzivel no ambiente de CI.
|
|
||||||
- Cenarios normativos da spec 19 permanecem cobertos.
|
|
||||||
- Evidencia inclui runtime line explicita no relatorio/test metadata.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Rework de testes de integracao para usar adaptador de compatibilidade.
|
|
||||||
- Regressao completa dos 8 cenarios de Gate I.
|
|
||||||
- Teste de fallback para modo local quando runtime externo nao estiver disponivel.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O3.1 - IRVM Control-Flow Lowering and Label Resolution
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Expandir lowering para cobrir controle de fluxo com labels simbolicos internos e resolucao deterministica para offsets finais, alinhando o backend ao perfil quasi-ISA.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `LowerToIRVMService` e modelo de instrucao IRVM.
|
|
||||||
- Resolucao de labels para `JMP/JMP_IF_*`.
|
|
||||||
- Validacoes de alvo de salto em fronteira de instrucao.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Introduzir representacao intermediaria de labels no lowering.
|
|
||||||
- Resolver labels para `u32` relativo ao inicio da funcao antes da emissao.
|
|
||||||
- Integrar com `IRVMValidator` para garantir alvos validos e paths terminados.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Fluxos com desvio condicional/incondicional sao emitidos corretamente.
|
|
||||||
- Todos os saltos resolvidos apontam para fronteiras validas.
|
|
||||||
- Caminhos alcancaveis sem terminador sao rejeitados deterministicamente.
|
|
||||||
- Mesmo input gera mesmos offsets finais.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes novos de lowering/validator com CFG linear e com joins.
|
|
||||||
- Casos negativos para alvo invalido e mismatch de altura de pilha em join.
|
|
||||||
- Regressao para funcoes sem saltos.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O3.2 - Bytecode ConstPool and Symbol Interning Determinism
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Estabelecer estrategia deterministica de internacao para constantes/simbolos no emissor, reduzindo redundancia e preparando evolucao do formato sem quebrar reproducibilidade.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- `BytecodeEmitter` e mapeamento de `const_pool`/simbolos.
|
|
||||||
- Contratos internos de deduplicacao e ordem de materializacao.
|
|
||||||
- Testes de reproducibilidade de modulo.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Definir politica canonical para internacao (tipo + valor + ordem deterministica).
|
|
||||||
- Materializar indices finais em etapa unica de fechamento do artefato.
|
|
||||||
- Garantir bytecode identico para entradas semanticamente identicas.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- `const_pool` nao depende de ordem incidental de estruturas nao deterministicas.
|
|
||||||
- Emissoes repetidas do mesmo input produzem bytes identicos.
|
|
||||||
- Duplicacao desnecessaria de constantes e reduzida sem alterar semantica.
|
|
||||||
- Falhas de internacao invalidas retornam erro deterministico.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes de snapshot binario para entradas repetidas.
|
|
||||||
- Casos com constantes repetidas em multiplas funcoes.
|
|
||||||
- Testes negativos para entradas de constante fora de contrato.
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
# PR-O3.3 - IRVM Profile Evolution and Feature Gates
|
|
||||||
|
|
||||||
## Briefing
|
|
||||||
|
|
||||||
Definir trilha de evolucao controlada do `IRVM` quasi-ISA com feature gates por perfil, protegendo compatibilidade entre pipeline de compilacao e runtime line.
|
|
||||||
|
|
||||||
## Target
|
|
||||||
|
|
||||||
- Modelo `IRVMModule.vmProfile` e validacoes de perfil.
|
|
||||||
- Poltica de habilitacao de opcodes/extensoes internas por perfil.
|
|
||||||
- Documentacao de compatibilidade/rollout.
|
|
||||||
|
|
||||||
## Method
|
|
||||||
|
|
||||||
- Formalizar matriz de features por `vm_profile` (ex.: `core-v1`, futuros perfis).
|
|
||||||
- Bloquear introducao de opcode fora do perfil selecionado.
|
|
||||||
- Expor gates de evolucao para rollout incremental e rollback seguro.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
|
|
||||||
- Backend rejeita artefato com opcode nao permitido no perfil ativo.
|
|
||||||
- Mapeamento perfil->feature e deterministico e testado.
|
|
||||||
- Evolucao de perfil nao quebra caminho `core-v1` existente.
|
|
||||||
- Decisao de compatibilidade fica rastreavel em specs/decisions.
|
|
||||||
|
|
||||||
## Tests
|
|
||||||
|
|
||||||
- Testes de validacao por perfil com opcodes permitidos/proibidos.
|
|
||||||
- Regressao do pipeline completo em `core-v1`.
|
|
||||||
- Fixtures cobrindo ativacao/desativacao de feature gate.
|
|
||||||
Loading…
x
Reference in New Issue
Block a user