clean up
This commit is contained in:
parent
6288056c7a
commit
8a4b494ad0
SSH Key Fingerprint:
SHA256:Z7dgqoglWwoK6j6u4QC87OveEq74WOhFN+gitsxtkf8
@ -1,32 +0,0 @@
|
||||
# PR-O4.1 - Callable Signature Identity and Dense Symbol Table
|
||||
|
||||
## Briefing
|
||||
|
||||
Eliminar ambiguidade de callsites no backend substituindo resolucao por nome simples por identidade canônica de callable baseada em assinatura.
|
||||
|
||||
## Target
|
||||
|
||||
- Modelo `IRBackend`/`IRBackendExecutableFunction`.
|
||||
- Lowering PBS para callsites `CALL_FUNC`.
|
||||
- Backend `LowerToIRVM` no mapeamento de callee.
|
||||
- Infra `source/tables` para simbolos de callable.
|
||||
|
||||
## Method
|
||||
|
||||
- Introduzir `CallableId` e `CallableSignatureRef` usando `DenseTable`/`InternTable` em `source/tables`.
|
||||
- FE emite `calleeCallableId` para `CALL_FUNC` em vez de lookup textual por nome.
|
||||
- Chave canônica de assinatura: `module + callable + arity + type-shape`.
|
||||
- Backend resolve `CALL_FUNC` por id canônico, sem heuristica `putIfAbsent(name)`.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Overloads válidos com mesmo nome e assinaturas diferentes chamam alvo correto.
|
||||
- Não há resolução de callee por nome simples no caminho executável.
|
||||
- Mesmo grafo de entrada gera mesma tabela densa de callables.
|
||||
- Falha de resolução gera erro determinístico de lowering.
|
||||
|
||||
## Tests
|
||||
|
||||
- Fixtures com overloads por aridade e por shape de tipo.
|
||||
- Regressão negativa para callsite sem `CallableId` válido.
|
||||
- Teste de determinismo de IDs de callable entre execuções.
|
||||
@ -1,32 +0,0 @@
|
||||
# PR-O4.2 - Global Intrinsic Table and Reindexing
|
||||
|
||||
## Briefing
|
||||
|
||||
Consolidar IDs de intrínsecos em escopo global de build para impedir drift de IDs entre módulos e manter mapeamento canônico estável.
|
||||
|
||||
## Target
|
||||
|
||||
- `PBSFrontendPhaseService` e `IRBackendAggregator`.
|
||||
- Modelo de saída `IRBackend` para carregar pool global de intrínsecos.
|
||||
- `CALL_INTRINSIC` no FE/BE.
|
||||
- Infra `source/tables` de intrínsecos já existente.
|
||||
|
||||
## Method
|
||||
|
||||
- Promover `IntrinsicTable` para escopo de agregação (não por arquivo).
|
||||
- Agregador constrói `intrinsic_pool` global (`IntrinsicId -> IntrinsicReference`).
|
||||
- Reindexar `CALL_INTRINSIC` de módulos compilados para o pool global antes do handoff ao backend.
|
||||
- Tornar explícito no contrato que `intrinsicId` é relativo ao pool global de build.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Mesmo intrínseco em módulos distintos referencia o mesmo `IntrinsicId` final.
|
||||
- Não existe colisão/duplicação de id para referências canônicas iguais.
|
||||
- Artifact produzido mantém IDs estáveis no mesmo input graph.
|
||||
- Backend não precisa inferir/normalizar ids de intrínseco em runtime.
|
||||
|
||||
## Tests
|
||||
|
||||
- Caso multi-módulo com intrínseco repetido e intrínsecos distintos.
|
||||
- Teste de reindex determinístico em ordem diferente de compilação.
|
||||
- Regressão para caminho de emissão e Gate I com intrínsecos.
|
||||
@ -1,31 +0,0 @@
|
||||
# PR-O4.3 - Semantic Lowering, CFG, and Stack Analysis
|
||||
|
||||
## Briefing
|
||||
|
||||
Trocar lowering executável baseado em coleta de callsites por lowering semântico real com construção de CFG e cálculo formal de `max_stack_slots`.
|
||||
|
||||
## Target
|
||||
|
||||
- `PbsFrontendCompiler` (lowering executável).
|
||||
- Modelo `IRBackendExecutableFunction` para instruções semânticas.
|
||||
- Regras de stack/slot no handoff FE -> BE.
|
||||
|
||||
## Method
|
||||
|
||||
- Introduzir lowering de statements/expressões para instruções executáveis (não apenas calls + RET).
|
||||
- Construir CFG por função e resolver blocos/jumps explicitamente.
|
||||
- Calcular `max_stack_slots` por análise de fluxo em vez de heurística fixa.
|
||||
- Preservar spans por instrução para debug e diagnóstico.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Programas com controle de fluxo e expressões produzem IR executável semântico.
|
||||
- `max_stack_slots` é derivado por análise, não constante heurística.
|
||||
- Paths não terminados e inconsistências de stack são detectados no FE/BE boundary.
|
||||
- Contrato de lowering mantém determinismo para o mesmo AST admitido.
|
||||
|
||||
## Tests
|
||||
|
||||
- Fixtures com `if/while/for/switch/handle` e joins de controle.
|
||||
- Testes de stack-depth máximo e mismatch em join.
|
||||
- Regressão de spans e call classification.
|
||||
@ -1,29 +0,0 @@
|
||||
# PR-O4.4 - IRVM Program Single Source of Truth
|
||||
|
||||
## Briefing
|
||||
|
||||
Remover possibilidade de inconsistência entre `IRVMModule` e `EmissionPlan` tornando o pipeline de emissão derivado de uma única fonte autoritativa.
|
||||
|
||||
## Target
|
||||
|
||||
- `IRVMProgram`.
|
||||
- `OptimizeIRVMService`.
|
||||
- `EmitBytecodePipelineStage` e derivação de plano de emissão.
|
||||
|
||||
## Method
|
||||
|
||||
- Redefinir `IRVMProgram` para carregar apenas IR autoritativo (ou tornar `EmissionPlan` derivado e validado).
|
||||
- Se `EmissionPlan` permanecer, adicionar invariantes obrigatórias de sincronização e builder único.
|
||||
- Garantir que passes de otimização atualizem exatamente a fonte autoritativa usada por emissão.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Não existe estado observável onde módulo e plano de emissão divergem.
|
||||
- `EmitBytecode` consome dados derivados da mesma representação validada pelo optimizer.
|
||||
- Violação de coerência falha com erro determinístico antes de serialização.
|
||||
|
||||
## Tests
|
||||
|
||||
- Testes de coerência módulo/plano após passes.
|
||||
- Testes negativos para plano stale/inconsistente.
|
||||
- Regressão do pipeline completo sem alteração semântica.
|
||||
@ -1,30 +0,0 @@
|
||||
# PR-O4.5 - VM Profile End-to-End Pipeline
|
||||
|
||||
## Briefing
|
||||
|
||||
Unificar suporte a `vm_profile` do FE ao BE eliminando hardcodes de perfil e garantindo compatibilidade por feature matrix em todas as stages.
|
||||
|
||||
## Target
|
||||
|
||||
- Configuração de build/pipeline (`LowerToIRVM`, `OptimizeIRVM`, `EmitBytecode`, validators).
|
||||
- Contrato de profile no `IRBackend`/`IRVM`.
|
||||
- Matrizes de feature gate por perfil.
|
||||
|
||||
## Method
|
||||
|
||||
- Propagar `vm_profile` como input explícito de compilação.
|
||||
- Remover hardcode de `core-v1` no lowering.
|
||||
- Alinhar validator/profile gate e optimizer para aceitar perfis suportados.
|
||||
- Definir fallback e erro determinístico para perfil não suportado.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Pipeline executa corretamente para `core-v1` e perfis adicionais admitidos.
|
||||
- Todas as stages usam o mesmo profile efetivo.
|
||||
- Opcodes fora do profile são rejeitados de forma determinística.
|
||||
|
||||
## Tests
|
||||
|
||||
- Testes parametrizados por profile (válido/inválido).
|
||||
- Regressão `core-v1` sem quebra de comportamento existente.
|
||||
- Fixtures com opcode permitido em profile A e proibido em profile B.
|
||||
@ -1,29 +0,0 @@
|
||||
# PR-O4.6 - Strict Bytecode Precheck and Unknown Opcode Rejection
|
||||
|
||||
## Briefing
|
||||
|
||||
Endurecer precheck/verifier de artefato para rejeitar opcodes desconhecidos e instruções malformadas, removendo comportamento permissivo por `default-size`.
|
||||
|
||||
## Target
|
||||
|
||||
- `BytecodeLinkPrecheckService`.
|
||||
- `BytecodePreloadVerifierService`.
|
||||
- Taxonomia de erros `MARSHAL_VERIFY_PRECHECK_*`.
|
||||
|
||||
## Method
|
||||
|
||||
- Substituir `default -> 2` por tabela explícita de opcodes válidos por profile.
|
||||
- Rejeitar opcode desconhecido com erro dedicado e pc apontado.
|
||||
- Validar tamanhos de instrução somente para opcodes reconhecidos.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Opcode não reconhecido falha deterministicamente no precheck/verifier.
|
||||
- Não há avanço silencioso sobre bytecode inválido.
|
||||
- Mensagens/códigos de erro estáveis por classe de falha.
|
||||
|
||||
## Tests
|
||||
|
||||
- Fixtures com opcode inválido no meio de função.
|
||||
- Casos de truncamento de imediato para opcode conhecido.
|
||||
- Regressão para bytecode válido existente.
|
||||
@ -1,29 +0,0 @@
|
||||
# PR-O4.7 - Gate I Runtime-Backed Execution Adapter
|
||||
|
||||
## Briefing
|
||||
|
||||
Substituir evidência de integração puramente simulada por adapter com execução/verificação real contra runtime line alvo, mantendo fallback local explícito.
|
||||
|
||||
## Target
|
||||
|
||||
- Suite `BackendGateIIntegrationTest`.
|
||||
- `RuntimeCompatibilityAdapter` e implementação runtime-backed.
|
||||
- Metadata de runtime line no resultado de compatibilidade.
|
||||
|
||||
## Method
|
||||
|
||||
- Introduzir implementação real do adapter que invoca runtime/verifier/loader do target line.
|
||||
- Manter adapter local como fallback de desenvolvimento.
|
||||
- Expor no resultado: `runtimeLine`, `adapterMode`, `pass/fail reason`.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Gate I principal roda contra runtime real quando disponível.
|
||||
- Fallback local permanece funcional sem mascarar modo de execução.
|
||||
- Relatório de teste informa claramente qual runtime line foi usada.
|
||||
|
||||
## Tests
|
||||
|
||||
- Reexecução dos 8 cenários normativos Gate I no modo runtime-backed.
|
||||
- Teste de fallback local quando runtime externo indisponível.
|
||||
- Teste de consistência de resultado entre adapters para cenários de interseção.
|
||||
@ -1,29 +0,0 @@
|
||||
# PR-O4.8 - JVM-Grade Regression Matrix and Golden Artifacts
|
||||
|
||||
## Briefing
|
||||
|
||||
Estabelecer matriz de regressão de alto risco com fixtures golden para preservar determinismo e contratos críticos após endurecimentos de arquitetura.
|
||||
|
||||
## Target
|
||||
|
||||
- Testes FE/BE de integração e unidade.
|
||||
- Harness de snapshots de IR/bytecode.
|
||||
- Evidências Gate S-U e Gate I versionadas.
|
||||
|
||||
## Method
|
||||
|
||||
- Definir matriz mínima obrigatória: overload, intrinsic pool multi-módulo, profile gating, CFG complexa, bytecode determinístico.
|
||||
- Adotar golden artifacts para outputs canônicos (`IRVM`, `BytecodeModule.serialize()`).
|
||||
- Versionar baseline por runtime/profile com política explícita de update.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Cada classe de risco alta possui pelo menos um golden fixture.
|
||||
- Mudança de output exige diff explícito e revisão consciente.
|
||||
- Pipeline de CI falha em regressão de determinismo/contrato.
|
||||
|
||||
## Tests
|
||||
|
||||
- Golden tests para FE->IRBackend, IRBackend->IRVM e IRVM->bytecode.
|
||||
- Repetição de build com assert de bytes idênticos.
|
||||
- Regressão multi-profile e multi-módulo para IDs densos.
|
||||
Loading…
x
Reference in New Issue
Block a user