Validação

Base atual

Plan 11 step 1, 2026-10-03, commit b1a471f, Windows x64: clang-cl 23.1.2, LLVM SDK 23.1.2 (/MT, _ITERATOR_DEBUG_LEVEL=0), Lizard 1.24.0, clang-tidy 22.1.8, pin do OTP 21776803ecd1 com o oráculo OTP 29.1.1 / ERTS 17.1.

Executar o gate

A partir de uma shell de programador do Visual Studio x64 com C:\Program Files\LLVM\bin no PATH (a seleção automática do SDK reutiliza thirdparty/):

cmake --preset debug --fresh -DBUILD_TESTING=ON -G Ninja -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl
cmake --build build/debug
ctest --preset debug-fast                  # during development
ctest --preset debug -j 16                 # full mode, at feature completion
cmake --build build/debug --target check-quality      # changed files + dependents
cmake --build build/debug --target check-quality-all  # whole tree

• CLAUSE_TEST_MODE=fast executa os corpora golden em O0 posicional mais o projeto O2 com a especialização desativada, executa as mutações uma vez e salta os testes full_only. O modo completo (predefinido) executa todas as combinações de driver/política.
• check-quality, make format e make-format.bat abrangem os ficheiros alterados desde HEAD mais os ficheiros não seguidos; cmake/quality_scope.py acrescenta as unidades de tradução que incluem um cabeçalho alterado. As alterações a .clang-tidy, a cmake/ ou ao CMake de produção selecionam tudo.
• Os programas de teste não contêm informação de depuração (sem PDBs); configure com -DCLAUSE_TEST_DEBUG_INFO=ON para os recompilar para um depurador. Os consumidores nativos aninhados ligam o runtime da compilação principal através de ClauseRuntimeTargets.cmake em vez de o compilar novamente; só runtime_link compila o runtime de forma autónoma.
• Os limiares e as supressões nunca são aumentados para passar o gate.

Fixtures e proveniência

• As compilações e os testes normais não precisam do OTP nem do seu código-fonte. Os goldens foram gerados uma vez a partir do OTP e estão no repositório com hashes; as verificações de hash são executadas antes de qualquer fixture ser usada.
• Dezanove corpora de padrões/guards contêm 67 748 valores/erros nativos esperados e 106 linhas de aceitação semântica. Cada corpus nativo executa os drivers posicional e de projeto em O0/O2 com a especialização ativada e desativada, com chamadas locais e remotas.
• As entradas Erlang no repositório são de autoria local (tests/fixtures/patternmatch/fragments/, semantic/headers/ do pré-processador). Uma auditoria de 2026-10-03 removeu todos os ficheiros copiados do OTP; uma comparação por janelas de 60 tokens com 4 150 ficheiros Erlang e 1 190 ficheiros C/C++ do OTP não encontrou nenhuma sobreposição restante além de um tuplo de inteiros gerado. fixture_sources impõe o isolamento.
• Seis fixtures de programas finais (tests/fixtures/programs/, plan 11 step 2) contêm goldens de stdout/estado de saída do OTP e os diagnósticos de compilação atuais; programs_compile verifica-os sem OTP e tests/compiler/programs/regenerate.py --check reprodu-los com o OTP (mapa das fixtures).
• Os goldens de impressão de termos (tests/fixtures/printing/, plan 11 step 4) contêm o texto de ~w e de erlang:display/1 do OTP para 9 542 valores, mais o stdout do OTP de chamadas display compiladas; tests/compiler/printing/regenerate.py --check reprodu-los (notas das fixtures).
• Os casos golden de executáveis (tests/fixtures/executables/, plan 11 step 8) são diretórios de código-fonte mais um golden.json com o stdout/estado de saída do OTP e um padrão de stderr escrito à mão; tests/compiler/executables/run.py liga e executa cada um sob a matriz de política/driver (CTest executables_<case>), e regenerate.py --check reprodu-los com o OTP (notas dos casos).
• A regeneração e as auditorias em direto são explícitas: -DCLAUSE_OTP_AUDITS=ON e tests/compiler/patternmatch/regenerate.py (instruções). Nada atualiza os goldens nem o pin silenciosamente.

Conceção dos testes

O comportamento é testado através da CLI real, dos objetos emitidos, de consumidores nativos ligados e dos goldens do OTP. Os testes unitários dedicados permanecem apenas onde o código-fonte não consegue alcançar o estado, cada um com o seu propósito indicado no teste:

• Orçamentos injetados e falhas de alocação/E/S (project_limits, project_creation_failure, codegen_limits, codegen_write_failure, runtime_lifecycle_failure, pontos de injeção de falhas em chamadas geradas).
• Invariantes de posse privada, de handles inválidos/obsoletos e de reversão no analisador sintático, no grafo de tipos semântico e no backend.
• Validação de palavras em bruto e limites de termos de 32/64 bits (runtime_immediate, runtime_term_tag, abi_integers).
• Falhas do destino de diagnósticos e o instantâneo estável dos IDs de funcionalidades.

Os casos de capacidades do sistema de ficheiros (ligações, aliases por maiúsculas/minúsculas) relatam testes saltados por caso; nunca substituem a aprovação de um teste completo.

Estado por plataforma e sanitizers

• Execução de código gerado nativo: apenas Windows x64.
• Execução em Linux, Apple Silicon e nativa de 32 bits: pendente (os objetos são apenas inspecionados).
• ASan, UBSan e LeakSanitizer no compilador/frontend: pendente. O SDK do LLVM pré-compilado para Windows entra em conflito com o código instrumentado (annotate_string 0 vs 1; antes também símbolos duplicados dos alocadores rpmalloc/ASan). Nenhuma verificação foi desativada para contornar o problema.
• O ASan apenas do runtime passa em Windows com sondas Release, /EHsc /fsanitize=address, /MT, a biblioteca de importação do ASan e o thunk de runtime estático do Clang, e a DLL do ASan no PATH.
• Execuções históricas em macOS arm64 (2026-09-19/20) passaram compilações Debug completas, C++26, ASan+UBSan, apenas do compilador e apenas do runtime para as fases do analisador sintático e dos projetos; são anteriores ao backend.

Histórico

Condensado a partir dos antigos registos por passo (originais no histórico do Git até ao commit 2777c98). Salvo indicação em contrário: Windows x64, LLVM 23.1.2, pin 21776803ecd1, oráculo OTP 29.1.1 / ERTS 17.1. Os números de testes são execuções completas do CTest aprovadas, com zero testes saltados.

PG = passo do plano de padrões/guards (arquivado em .agents/00-finished.md).