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
78 lines
2.4 KiB
Markdown
78 lines
2.4 KiB
Markdown
---
|
|
id: AGD-0066
|
|
ticket: multi-frontend-synthetic-test-frontend
|
|
title: Frontend sintetico de teste para provar neutralidade do pipeline
|
|
status: open
|
|
created: 2026-07-15
|
|
resolved:
|
|
decision:
|
|
tags: [compiler, compiler-general, frontend, tests, backend, multi-frontend]
|
|
---
|
|
|
|
# Agenda - Criar um frontend sintetico de teste
|
|
|
|
## Objetivo
|
|
|
|
Domain owner: `compiler/general`.
|
|
|
|
Discutir um frontend exclusivo de testes que prove que o pipeline comum nao depende implicitamente do PBS.
|
|
|
|
## Contexto atual
|
|
|
|
O criterio arquitetural final exige que um frontend sintetico implemente contratos equivalentes a `FrontendProvider`, `FrontendSpec` e `FrontendCompiler`, produza IR comum minima e passe pelo backend ate PBX/verifier.
|
|
|
|
## Escopo
|
|
|
|
- Escolher entre frontend totalmente sintetico ou extensao ficticia.
|
|
- Definir fixture de IR minima com `frame` vazio.
|
|
- Garantir isolamento em testes.
|
|
|
|
## Fora de escopo
|
|
|
|
- Expor frontend sintetico no Studio.
|
|
- Criar segunda linguagem real.
|
|
- Criar parser completo ou grammar dummy complexa.
|
|
|
|
## Arquivos e componentes a inspecionar
|
|
|
|
- `prometeu-compiler/prometeu-frontend-registry/...`
|
|
- `prometeu-compiler/prometeu-build-pipeline/...`
|
|
- testes do build pipeline e backend
|
|
- `prometeu-studio/src/main/java/p/studio/projects/...` apenas se a selecao por extensao for exercitada
|
|
|
|
## Alteracoes propostas
|
|
|
|
Opcao A: provider sintetico que ignora arquivos e retorna IR minima diretamente.
|
|
|
|
Opcao B: extensao `.dummy` reconhecida em fixture, com conteudo ignorado ou trivial.
|
|
|
|
Recomendacao inicial: preferir Opcao A para provar neutralidade do pipeline sem criar outra superficie de linguagem.
|
|
|
|
## Estrategia de implementacao
|
|
|
|
Esperar provider/IR/lifecycle estarem suficientemente definidos, entao adicionar fixture de teste que registra provider sintetico e executa pipeline comum sem PBS.
|
|
|
|
## Testes necessarios
|
|
|
|
- Provider registrado e resolvido por `languageId`.
|
|
- Extensao/source handling testado se a opcao B for escolhida.
|
|
- IR comum produzida, lifecycle montado, IRVM gerado, PBX emitido e verificado.
|
|
|
|
## Criterios de aceitacao
|
|
|
|
- Teste falha se pipeline comum instanciar PBS implicitamente.
|
|
- Synthetic frontend existe apenas em test fixtures.
|
|
- PBS nao e afetado.
|
|
|
|
## Riscos
|
|
|
|
- Fixture sintetica exercitar caminho feliz pequeno demais e nao proteger acoplamentos reais.
|
|
- Virar uma segunda linguagem informal.
|
|
|
|
## Decisoes que devem ser registradas
|
|
|
|
- Forma do frontend sintetico.
|
|
- Escopo minimo da IR fixture.
|
|
- Onde o provider de teste pode ser registrado.
|
|
|