ClauseComunicação de funcionalidades adiadas
Erlang legal que precise de uma funcionalidade não implementada falha com uma única mensagem explícita, distinta dos erros comuns de entrada inválida. As alternativas genéricas suportadas (por exemplo, especialização saltada) são silenciosas e não constituem uma falha.
[pattern matching] notimpl: src/example.erl:12:5 [module="example"] [target="native"] [operation="match argument"]
Catálogo
features.hpp atribui IDs estáveis e nunca reutilizados e nomes de diagnóstico, com responsável e estado por entrada. Uma entrada é retirada ou refinada quando a sua funcionalidade fica pronta; o seu ID mantém-se reservado.
| Responsável | Onde comunica |
|---|---|
| Análise semântica do compilador | Verificações de capacidade sobre todas as funções, incluindo código não usado |
| Rebaixamento do compilador | Rejeição defensiva nas operações alcançadas; limpa os artefactos preparados |
| Driver | -o/--output liga as entradas posicionais ou um alvo de projeto; as compilações de projetos ligam cada alvo executável ao output do seu manifesto |
| Serviços do runtime | Ver serviços adiados do runtime |
Regras das mensagens
- O formatador partilhado
omite o contexto desconhecido, escapa os bytes de controlo como
\xHHe escapa as aspas e as barras invertidas, para que o contexto não possa injetar linhas. O UTF-8 é mantido. - Exatamente uma mensagem por operação falhada, independentemente de
--verbose. - Compilador: reject_feature comunica
a primeira falha de um lote, regista a falha, descarta a saída preparada e
marca o diagnóstico como
reported, para que os drivers não o voltem a imprimir. - Runtime: FeatureFailure
comunica uma vez por operação através de um destino emprestado (null →
stderr). As chamadas posteriores devolvem o estado registado. As falhas do
destino ou da formatação tornam-se
diagnostic_failure; as exceções são contidas. - Os chamadores propagam a falha sem a voltar a comunicar; um anfitrião deve terminar com um código diferente de zero e encerrar normalmente.