bQUARKz
35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
77 lines
2.7 KiB
Markdown
77 lines
2.7 KiB
Markdown
---
|
|
id: AGD-0063
|
|
ticket: multi-frontend-validation-boundaries
|
|
title: Separar validacoes de linguagem e validacoes de plataforma
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [compiler, compiler-general, compiler-pbs, backend, validation, multi-frontend]
|
|
---
|
|
|
|
# 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.md`
|
|
- `docs/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.
|
|
|