Status atual

Esta é a página canônica de status de implementação pública para seed. A especificação de idioma atual é seed/docs/lang-spec.md; seus capítulos gramaticais e semânticos estão sob seed/compiler/llvm. Um item do roteiro não é implementado apenas porque é proposto; portões concluídos exigem sua evidência de fechamento nomeada.

Compilador

seed/compiler/llvm é o compilador e inicializador do repositório operacional. Gates 0-24 estão completos para seus escopos gravados. O pipeline verificado é:

source → lexer/parser → semantic graph → typed HIR/CFG
       → ownership/provenance/effects/loans → cleanup planning/verification
       → MIR → target layout/ABI → verified low MIR → LLVM

Importações de origem e .sdi emissão executam a mesma cadeia de segurança obrigatória. O normal e ASan/UBSan suítes passam por 1.496 verificações do compilador mais sete binários de unidade na linha de base atual. Gate-evidência específica está sob seed/compiler/llvm/tests/GATE*_BASELINE.md.

Compilador auto-hospedado

A auto-hospedagem completa é uma faixa Linux x86-64 ativa governada por roadmap-self-hosted.md. O compilador operacional LLVM permanece o oráculo semântico e ABI até a transição SH20.

SH0 congelou o Linux x86-64 contrato de bootstrap, limite de dependência e rastreabilidade. SH1 fechou as bibliotecas de nível de compilador e o substrato host. SH2 está em andamento com token, lexer, AST, analisador, formatador e fatias mínimas de comando de frontend implementadas. Análise semântica, IRs do compilador, o LLVM ponte, nativo x86-64/ELF emissão, bootstrap de ponto fixo nativo, tempo de execução, vinculador, origem da versão e transição operacional permanecem como portas posteriores. Não-Linux as portas são explicitamente adiadas até depois da primeira transição.

O Linux O alocador -native usa classes de placas precisas de 16 bytes a 8 KiB, um cache de placas vazias limitado em todo o processo e desmapeia placas vazias em excesso. box<t> é um proprietário de ponteiro único, enquanto ?box<t> usa seu nicho nulo auditado e, portanto, também ocupa um ponteiro. Esquema-11 .sdi preserva a representação nominal de nicho nulo na compilação separada. Gate 18 interfaces de esquema 12 adicionam receptores mutáveis exclusivos, modelos genéricos, proveniência de retorno emprestado e contratos falíveis de limites de aplicativos. Gate 19 interfaces esquema-13 adicionam exatas target/profile/runtime identidade e órgãos públicos inline verificados. Gate 20 interfaces de esquema 14 preservam adicionalmente escalares imutáveis públicos, texto, tupla, estrutura e constantes de matriz aninhada para consumidores excluídos da origem; o compilador emite globais somente leitura digitados e projeções verificadas. Gate 21 tem uma primitiva de capacidade não inicializada auditada usada internamente por buffers de bytes e I/O; io.input_stream fornece leituras incrementais limitadas, crescimento geométrico copia apenas prefixos inicializados e capacidade sobressalente direta I/O é coberto pela sua linha de base.

As árvores do compilador substituídas foram removidas após a substituição. Suas classificações de comportamento relevantes sobrevivem em compiler/llvm/COMPATIBILITY.md e regressões migradas; eles não definem a semântica atual do compilador.

Gate status

Codificação de origem e texto

• .sd arquivos de origem são UTF-8 por contrato.
• string é de propriedade válida UTF-8.
• str é uma visualização UTF-8 de ponteiro mais byte emprestada somente leitura.
• Literais de string têm armazenamento estático e tipo str.
• Comentários e conteúdos de string podem conter Unicode.
• len informa o comprimento em bytes. O pacote text comum valida e itera escalares Unicode sem alocação; segmentação de grafema, normalização e comportamento de localidade continuam sendo trabalho da biblioteca.
• Os identificadores de origem permanecem intencionalmente em letras minúsculas ASCII; constantes são letras maiúsculas ASCII.

O carregador valida cada fonte como UTF-8 canônico antes do lexing e rejeita NUL incorporado, codificações longas, substitutos, truncamento e valores além do escalar máximo do Unicode. Literais de string decodificados também são validados.

A interpolação de string f da fase 1 é implementada para str, emprestado string, boole números inteiros integrados. A construção produz efêmero format_args sem alocação de heap; usos de saída direta file.write_*_format, enquanto .to_string()? materializa explicitamente uma string de propriedade. A Fase 2 implementa conversão de base inteira; limitado width/fill/alignment; exato fixo e determinístico scientific/general f32/f64 conversão sem libc; e formatação personalizada estática direta por meio de empréstimo sem alocação display.display() -> str e debug.debug() -> str implementações.

Superfície de linguagem implementada

• immutable/mutable/linear ligações e constantes de cobra superior;
• funções, métodos de receptor implícito, destruidores, genéricos, características, impls;
• estruturas de cobra inferior, ADTs, uniões brutas, matrizes, fatias, tuplas, option/result;
• blocos orientados a expressão e if, mais while, livre de alocação for, exaustivo match, break, continue, e cedo ret;
• indexação verificada para todas as larguras inteiras integradas; leituras de índice variável são suportado nos parâmetros da função []u8 e na fatia original de bytes.view(). Escopo visualizações mutáveis ​​dentro de um bloco e use parâmetros de função []u8 somente leitura ou a fatia original para acesso ao índice variável;
• memória bruta unsafe explícita, atômicos, acesso volátil, espaços de endereço, FFI, syscalls, acesso bruto à união e intrínsecos da arquitetura;
• estruturado spawn, regiões, perfis de tempo de execução e compilação separada.
• fechamentos sem escape sem alocação, fechamentos em caixa falíveis explícitos, efeitos de retorno de chamada inferidos e contratos exigíveis excluídos da origem do esquema 16;
• strings f phase-1/2 digitadas com avaliação única, escape de chave literal, especificações de formato, características display/debug estáticas, saída segmentada sem alocação e materialização de propriedade falível.

A gramática limpa atualmente não implementa legado enum, nomes nominais em maiúsculas, return, # comentários, integrados chan<t>/send/recv, spawn desanexado, fechamentos recursivos, geradores, macros, exceções, async/await ou sintaxe vitalícia.

Propriedade e segurança

O modelo comum é: copiar escalares, mover recursos, emprestar visualizações de cópia zero e clonar explicitamente. A limpeza é executada exatamente uma vez nas saídas estruturadas. Pânico, armadilha e aborto não desenrolam ou executam o léxico cleanup/destructors.

Ownership/place/provenance os fatos se propagam através de aliases, blocos, ramificações, pontos fixos de loop, fields/nested campos, índices de array conhecidos, tuplas, ADTs, option/result, agregados genéricos, channels/tasks, função values/indirect chamadas, parameters/returns e fonte omitida .sdi. As movimentações de índice dinâmico de elementos de recursos permanecem rejeitadas.

linear t possui semântica exatamente uma vez nas mesmas formas implementadas. As visualizações @borrow receiver/input-derived mantêm a origem sem sintaxe vitalícia. O código inseguro assume obrigações brutas explícitas, mas não desativa a propriedade segura dos valores circundantes.

Os fechamentos simples são baseados em pilha e não escapam. As capturas copiam ou movem na primeira ordem de uso lexical, permanecem imutáveis ​​e são limpas exatamente uma vez. box |...| aloca explicitamente uma chamada de escape e retorna result<box fn(...) -> t, alloc_error>; os callables em caixa são somente móveis, não clonáveis, não enviáveis ​​e confinados à região quando a região é alocada. Os retornos de chamada iniciais usam descritores code/environment de um ponteiro, enquanto os ponteiros de função da plataforma permanecem finos e aceitam apenas funções nomeadas.

Texto, bytes e regiões

• propriedade string movimentos; .clone() cria um proprietário independente explícito;
• bytes é propriedade binária mutável única;
• shared_bytes é um identificador somente leitura compartilhado com explícito retain/clone;
• visualizações owner/array compatíveis são isentas de alocação e de proveniência verificada;
• as conversões próprias retornam result<..., alloc_error>;
• region(capacity) { body } fornece alocação de colisão verificada e alinhada aninhada;
• o seguro values/views/pointers vinculado a uma região não pode escapar dela;
• tarefas vinculadas à região são ingressadas antes da limpeza da região.
• str.slice impõe UTF-8 limites, enquanto str.equal e delimitador ASCII a pesquisa permanece livre de alocação;
• o comum text, box, vece sort pacotes fornecem token seguro intervalos, propriedade recursiva, mutação verificada e ordenação estática.

Simultaneidade

spawn é estruturado: grupos de tarefas são drenados em todas as arestas, deixando seu proprietário léxico antes da limpeza. Captura, copia ou move de acordo com a capacidade; o compartilhamento é explícito e os valores de tarefas cruzadas exigem send/sync conforme apropriado.

compiler/llvm/libs/task é uma biblioteca genérica comum que fornece canais de divisão de propriedade, junções de tarefas únicas digitadas, eventos, cancelamento, grupos de espera, semáforos, barreiras e bloqueios. O corpo gerado direto ABI ainda retorna void, então pós-fixado ? não pode cruzar o limite da tarefa diretamente. Gate 15 adiciona a superfície da biblioteca digitada task_result_new, task_result_complete_ok/errore task_result_wait sobre os mesmos pontos finais lineares e lexicalmente unidos. Valores de função e fechamentos inferidos podem usar @no_runtime_effects fn(...) exigir um resumo completo e vazio do efeito do tempo de execução; chamadas indiretas desconhecidas e não qualificadas permanecem rejeitadas em perfis restritos. Retornos de chamada em caixa não podem cruzar spawn porque eles não fornecem send.

Bibliotecas e ligação

.sdi interfaces preservam tipos públicos, genéricos templates/common instâncias, efeitos, propriedade, proveniência, destruidor, clone, alvo, build/runtime perfil, dependência e ABI identidade. O esquema 13 preserva corpos in-line verificados e hashes de corpo; o esquema 14 adiciona cargas constantes imutáveis ​​recursivas públicas verificadas; o esquema 15 adiciona contratos de efeito exigíveis; o esquema 16 adiciona assinaturas que podem ser chamadas em caixa, corpos de fechamento em linha e identidade de representação que pode ser chamada. Um wrapper de biblioteca não publica uma especialização de método órfão cujo proprietário do método genérico vem de um pacote importado; os consumidores excluídos da origem rematerializam essa instância a partir do modelo da dependência. Hospedado seed as bibliotecas são vinculadas dinamicamente por padrão; --static seleciona estático seed dependências. A publicação do artefato é atômica e corrompida, esquema obsoleto, perfil, destino ou ABI-interfaces incompatíveis falham no fechamento.

O lançador incremental build/run path prepara pacotes seguros para digitados I/O, visualizações de processos, análise de inteiros, matemática portátil, buffers de bytes, fatias, caixas, rede, serialização, tarefas, coleções genéricas e wrappers de sistemas. Gate 18 adiciona esquema-12 @mut vetores e seguros benchmark/application consumidores; Gate 19 adiciona esquema-13 embutido math/system folhas e partições de fatias disjuntas. Estes continuam sendo pacotes importados comuns, e não embutidos em idiomas ocultos.

Resolução de registro, lockfiles/download cache, pacote add/update, remoção de cache, geração de documentação, LSP e incremental object/interface cache são implementados pelo Gate 15 ferramentas. Gate 17 estágios de dependências básicas e manifestas comuns em profile/target-qualified armazenamentos dinâmicos por padrão, reutiliza gerações instaladas sem recompilação e implementa transações transacionais user/system seed install além de reconhecimento de referência seed uninstall. Explícito --static e --static=all permanecem escolhas de ligação independentes.

Crie perfis e desempenho

--release usa seed-safe-o2-v1; --release-small usa seed-safe-oz-v1. Limites, discriminantes, procedência, propriedade e guardas de limpeza permanecem, a menos que LLVM prove que são redundantes. ThinLTO, PGO e ligação estática são opções independentes explícitas. Não existe nenhum perfil operacional não verificado.

Gate 13 compara cargas de trabalho equivalentes numéricas, de análise, de coleção, allocation/string, tarefas estruturadas, rede, chamada dinâmica, inicialização, RSS e tamanho de artefato com Clang C e Rust. No host de fechamento, seed permanece dentro da meta de tempo de execução normal de 0-10% para o corpus imposto. Esta é uma evidência de carga de trabalho controlada, não uma afirmação universal de que todo programa seed supera o C/Rust.

Gate A mediana de verificação completa de 100k do host de fechamento do 12 é 0,41 s a 177.504 KiB contra orçamentos de 3,00 se 196.608 KiB. Veja GATE12_BASELINE.md e GATE13_BASELINE.md para hardware/toolchain metadados e interpretação.

Status de destino

O suporte a objetos não é o mesmo que suporte hospedado a executáveis. A matriz canônica é compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv.

Gate 14 é necessário Intel runner, SDK, ABI, FFI, biblioteca dinâmica, compilação separada, corrupção, carregador e requisitos de regressão são aprovados. macOS arm64 continua sendo um host nativo rotulado de forma independente, em vez de um substituto para a linha de fechamento da Intel.

CLI e ferramentas

O inicializador do repositório fornece new, check, format, incremental build, run, test, resolução do pacote, install/uninstall, doc, lint, LSP e publish --check, além de encaminhamento direto do sinalizador do compilador e file.sd -o output. Registro remoto publication/signing não está implementado; o comando de publicação existente executa apenas validação local.

O compilador direto formata a fonte, imprime semantic/IR formulários, emits/reads/hashes .sdi, emite LLVM/object/shared/static/binary artefatos, instalações target/ABI- bibliotecas qualificadas e executa alvos suportados. Sua ajuda executável é a lista de sinalizadores autorizados:

seed/compiler/llvm/build/seed --help

Documentação fonte da verdade

Documentos históricos podem descrever llvm-v1, o protótipo v2 ou diretórios stub de assembly que não existem mais. Eles devem ser explicitamente rotulados e não devem ser usados ​​como orientação atual em linguagem limpa.