Core built-in e librerie standard

<!-- verified-against: seed-llvm; examples: docs-examples-test -->

seed mantiene piccolo il nucleo del linguaggio. File, rete, processi, formattazione, raccolte e sincronizzazione sono normali librerie compilate separatamente, non integrate universali. La superficie integrata del compilatore pulito è sotto; il catalogo dei pacchetti operativi gestiti dal compilatore è documentato in Riferimento libreria, mentre l'albero Grove di generazione mista è classificato separatamente in Grove Compatibility Tree.

Tipi di nucleo

Il compilatore definisce void, never, bool, numeri interi a larghezza fissa, isize, usize, f32, f64, str, string, bytes, shared_bytes, alloc_errore quello nascosto region_handle. byte è accettato come u8. AllocResult<T> è la scorciatoia canonica per Result<T, alloc_error>. Ospitato main() -> Result<i64, E> associa il successo allo stato del processo. alloc_error ha la diagnostica fissa; un altro E deve essere Copia, non avere distruttore e implementare preso in prestito display() -> str. Il fallimento viene stampato una volta prima dello stato 1, dopo la pulizia e senza svolgimento.

Operazioni sicure note al compilatore

L'indicizzazione sicura di arrays/slices accetta ogni larghezza intera incorporata e controlla l'indice matematico prima della formazione del puntatore. Le API di testo espongono byte; L'elaborazione Unicode scalar/grapheme appartiene alle librerie. Le letture e le scritture degli indici variabili funzionano su mut []u8 e sulle sottosezioni derivate tramite .slice(), con gli stessi limiti controllati di ogni altra forma di sezione (verificata da tests/gate18/mut_slice_dynamic_index_consumer.sd).

byte_buffer nota: byte_buffer.mutable_view() restituisce una vista del prefisso inizializzato, che è di lunghezza 0 per un buffer appena creato. La scrittura oltre la lunghezza restituita provoca un trap fuori limite. Per preparare una destinazione di scrittura di n byte, utilizzare byte_buffer.resize_zeroed(n) (incrementare o ridurre il prefisso inizializzato; i nuovi byte sono zero) o byte_buffer.push_zeroed(n) (aggiungere n byte inizializzati con zero); entrambi sono fallibili con alloc_error in termini di crescita e preservano l'invariante del prefisso impegnato su ogni percorso, incluso il fallimento dell'allocazione. Per scrivere in un buffer non elaborato, utilizzare bytes.zeroed(n) il cui mutable_view() copre l'intera allocazione oppure utilizzare i metodi byte_buffer push/extend/reserve/resize.

Costruzione di stringhe canoniche: si accumula con push/push_str/extend, quindi si materializza una volta con text.utf8_string_from_bytes(buffer.view()), che convalida UTF-8 e segnala Utf8Error invece di trapping. La validazione risiede apposta nella libreria text controllata: gli stati intermedi del buffer possono contenere sequenze parziali, quindi solo il passaggio finale controlla:

use "byte_buffer"
use "text"

fn main() -> AllocResult<i64> {
    let mut builder = byte_buffer_new(8 as usize)?
    builder.push_str("hello ")?
    builder.push_str("world")?
    let built = match text.utf8_string_from_bytes(builder.view()) {
        Ok(value) => value,
        Err(_) => {
            return Ok(1)
        }
    }
    if built.view().equal("hello world") { Ok(0) } else { Ok(2) }
}

Substrato del compilatore non sicuro

Le seguenti operazioni richiedono un blocco unsafe o unsafe fn:

raw_try_alloc<t> segnala il conteggio negativo, l'overflow delle dimensioni o l'errore dell'allocatore come alloc_error. read/write/free non elaborato si affida al chiamante non sicuro controllato per limiti, inizializzazione, provenienza, sincronizzazione e rilascio esatto una volta.

Pacchetti bibliotecari ordinari

Il compilatore pulito mette in scena i pacchetti rappresentativi in compiler/llvm/libs:

Il launcher è incrementale build/run path mette automaticamente in scena questi pacchetti principali del repository quando un pacchetto ordinario utilizza un'importazione semplice come use "vec" o use "fibonacci"; non è richiesta l'installazione manuale dell'interfaccia o un'FFI visibile dall'applicazione. Il più stretto check il sottocomando non mette prima in scena un pacchetto nudo mancante. Gli utenti del compilatore diretto possono utilizzare una fonte esplicita o .sdi pacchetto. Questi non sono nomi di lingue magiche.

Formattazione e output

Il linguaggio implementa typed phase-1/2 f"..." interpolazione. Una stringa f produce effimero format_args senza allocazione heap. compiler/llvm/libs/io è la superficie tipizzata canonica per testo, porzione di byte e output in formato. Per risultati rapidi, print(text) scrive su stdout e println(text) scrive con una nuova riga finale. print prende str, quindi print(f"...") non controlla il tipo: le stringhe f producono effimeri format_args. Utilizzare print_format / println_format (stesso single/two-write disciplina come print/println) per l'uscita interpolata:

use "io"

fn main() -> Result<i64, IoError> {
    let count = 42
    print_format(f"events={count}\n")?
    println_format(f"done")?
    Ok(0)
}

.to_string()? esegue una materializzazione fallibile esplicita. Sono implementati Width/fill/alignment, specificatori di base interi e la formattazione dei tratti display presa in prestito senza allocazione. La fase 2 aggiunge la formattazione fissa, scientifica e generale f32/f64 priva di libc oltre ai tratti display/debug presi in prestito.

Avviso di compatibilità

lvm-v1 e storico Grove/runtime le tabelle espongono molti nomi come str_cat, read_file, net_connect, vec_new, e sd_*. La loro esistenza in un compilatore archiviato non li rende integrati puliti del compilatore. Quando esegui il porting del codice legacy, importa o implementa un wrapper sicuro corrente e lascialo .sdi contratto definisce proprietà, effetti, ABI e disponibilità.