2.7 KiB
| id | ticket | title | status | created | resolved | decision | tags | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AGD-0063 | multi-frontend-validation-boundaries | Separar validacoes de linguagem e validacoes de plataforma | open | 2026-07-15 |
|
Agenda - Separar validacoes de linguagem e plataforma
Objetivo
Domain owner: compiler/general, com impacto em compiler/pbs.
Definir onde cada validacao deve viver: PBS para sintaxe e semantica da linguagem; compiler core/backend para entrypoints, exports, hostcalls, capabilities, layouts, IR e bytecode.
Contexto atual
O PBS concentra parsing, semantica, lowering e algumas validacoes que podem ser universais. O backend ja possui validadores para IRVM, bytecode e precondicoes de lowering.
Escopo
- Mapear diagnostics e validacoes atuais.
- Classificar cada uma como linguagem ou plataforma.
- Definir regra: colocar a validacao no nivel mais baixo que a compreende sem conhecer a linguagem.
Fora de escopo
- Reescrever todas as mensagens diagnosticas.
- Mudar codigos de erro sem necessidade.
- Transferir validacoes antes de existir contrato comum suficiente.
Arquivos e componentes a inspecionar
prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/...prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...prometeu-compiler/prometeu-build-pipeline/src/test/java/p/studio/compiler/backend/...docs/specs/compiler/19. Verification and Safety Checks Specification.mddocs/specs/compiler-languages/pbs/12. Diagnostics Specification.md
Alteracoes propostas
Opcao A: criar matriz de ownership de validacoes antes de mover codigo.
Opcao B: mover validacoes junto com lifecycle/IR quando cada fronteira for tocada.
Recomendacao inicial: matriz primeiro; migracao so quando uma decisao posterior fechar lifecycle e IR.
Estrategia de implementacao
Auditar testes de erro existentes, agrupar por origem, decidir ownership e adicionar testes de regressao para impedir que o backend importe PBS.
Testes necessarios
- Testes PBS para erros de sintaxe/semantica continuam no frontend.
- Testes comuns para IR malformada, hostcall inexistente, export duplicado e lifecycle invalido.
- Teste arquitetural de ausencia de imports PBS em validadores comuns.
Criterios de aceitacao
- Validacoes da plataforma sao expressas sem conceitos PBS.
- Validacoes PBS continuam preservadas e especificas.
Riscos
- Perder qualidade de diagnostico ao mover validacao para camada comum.
- Duplicar validacoes em vez de estabelecer ownership.
Decisoes que devem ser registradas
- Matriz de validacoes e ownership.
- Politica de diagnosticos quando o erro comum ainda precisa de source span de frontend.