Riferimento linguistico

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

Questa pagina è il riferimento orientato all'utente per l'attuale seed Specifica della lingua. I capitoli completi di grammatica e semantica operativa si trovano qui sotto compiler/llvm. Per i limiti attuali e le richieste di chiusura, vedere Stato corrente.

Codifica sorgente e nomi

.sd i file sono UTF-8. I commenti e il contenuto delle stringhe possono contenere Unicode. string possiede valido UTF-8 e str è di sola lettura preso in prestito UTF-8 vista puntatore più lunghezza byte. La lunghezza del testo è misurata in byte; Le operazioni scalari, grafema, normalizzazione e locale Unicode appartengono alle librerie.

Gli identificatori di origine utilizzano intenzionalmente ASCII:

Gentile Regola Esempio
variabile, funzione, campo, modulo [a-z][a-z0-9_]* my_document
struttura, enum, unione, tratto, parametro generico [A-Z][a-zA-Z0-9]* Document, T
variante enum [A-Z][a-zA-Z0-9]* Some, Ok, Red
costante [A-Z][A-Z0-9_]* MAX_DOCUMENT_SIZE

Il nome formale del linguaggio è seed, sempre minuscolo. I nomi dei valori utilizzano maiuscole e minuscole; i tipi nominali e le varianti enum utilizzano UpperCamelCase e corrispondono a [A-Z][a-zA-Z0-9]*. Le costanti utilizzano la custodia a serpente superiore. _ è la rilegatura degli scarti; un carattere di sottolineatura iniziale può contrassegnare una rilegatura privata intenzionalmente inutilizzata.

I commenti di riga iniziano con //. Blocca i commenti /* ... */ nido. La grammatica pulita non utilizza # commenti.

Il caricatore di origine convalida l'intero file come UTF-8 prima della lexing e rifiuta il NUL incorporato; vengono convalidate anche le stringhe letterali decodificate.

Legami, costanti e mutazione

const MAX_COUNT: usize = 100

fn release(ticket: i64) {}

fn main() -> i64 {
    let answer = 42
    let mut count: usize = 0
    count += 1
    let linear ticket = 7
    release(ticket)
    if count < MAX_COUNT { answer } else { 0 }
}

Il compilatore corrente accetta anche espressioni scalari tipizzate, tabelle costanti u32 fisse private come const TABLE: [4]u32 = [1 as u32, 2 as u32, 3 as u32, 4 as u32], testo statico, tuple e strutture. Le letture indicizzate e di campo utilizzano l'archiviazione statica immutabile con controlli dei limiti ordinari. I valori aggregati pubblici mantengono la loro rappresentazione ricorsiva nelle build elide di origine schema-14.

L'annotazione del tipo costante è facoltativa, corrispondente a const_decl = "const", constant_ident, [ ":", type ], "=", expression: una costante senza annotazioni deduce il suo tipo dal suo inizializzatore (const MAX_ITEMS = 64 è i64, const OFFSETS = [1, 4, 9] è [3]i64), inclusi testo statico, tuple, strutture e costanti denominate. Un inizializzatore il cui tipo non può essere dedotto necessita di un'annotazione esplicita e viene rifiutato con R037 nella dichiarazione.

I collegamenti sono immutabili a meno che non siano dichiarati mut. L'assegnazione a un'associazione, a un campo o a un indice tramite un'associazione richiede che l'associazione sia modificabile. linear crea un obbligo esattamente una volta.

let accetta anche modelli inconfutabili: destrutturazione di tuple (let (a, b) = pair), destrutturazione di strutture (let Point { x, y } = origin), caratteri jolly (_) e annidamento. Ogni foglia con nome diventa un'associazione ordinaria spostata fuori dal componente dell'inizializzatore, quindi la proprietà, la linearità e la pulizia tengono traccia dei componenti in modo indipendente. I modelli confutabili (varianti, letterali) vengono rifiutati (error[B043]); usa match per quelli.

Un'annotazione let accetta qualsiasi tipo valido in una posizione di parametro (matrici, sezioni, tuple, puntatori, tipi di funzione, generici, nomi qualificati) e viene verificata rispetto al tipo di inizializzatore dedotto (error[H059] in caso di mancata corrispondenza). Le query di layout in fase di compilazione size_of(type) e align_of(type) vengono valutate rispetto alla destinazione attiva e sono valide in contesti costanti: inizializzatori const e lunghezze di array come [size_of(i64)]u8; altrove vengono rifiutati con error[H129].

Per scartare un valore restituito, utilizzare let _ = expression che valuta e ripulisce il valore senza creare un'associazione; _ ripetuto in un ambito è legale e _ non è mai accessibile. Anche let _unused = expression con un carattere di sottolineatura iniziale contrassegna un'associazione intenzionalmente inutilizzata ma crea un'associazione con nome.

Funzioni, metodi e rendimenti

struct Document {
    title: string
}

fn add(left: i64, right: i64) -> i64 {
    left + right
}

@borrow
fn Document.title_size() -> usize {
    len(self.title)
}

@mut
fn Document.rename(next: string) {
    self.title = move next
}

unsafe fn read_register(address: *mmio mut i64) -> i64 {
    raw_volatile_read<i64>(address, 0)
}

L'espressione finale di un blocco è il suo valore. return expression ritorna presto; il compilatore pulito non utilizza ret. Una dichiarazione di metodo include il tipo nominale prima del punto e riceve implicitamente self; non scrivere self nella sua lista dei parametri. fn TypeName.drop() è un distruttore consumante. @borrow su un metodo o un metodo di caratteristica dà self un prestito lessicale condiviso. @mut richiede invece un ricevitore indirizzabile mutabile, detiene un prestito esclusivo per la chiamata e apporta mutazioni self visibile al chiamante. I due attributi si escludono a vicenda.

str i rendimenti sono basati sulla provenienza, non limitati ai metodi: una funzione libera può restituire una vista statica o derivata dall'input. Una vista ricavata da un locale di proprietà string/bytes il valore non può sfuggire (V001); restituire il proprietario quando la proprietà deve lasciare la funzione. Non esiste una sintassi a vita.

Utilizzo delle dichiarazioni pubbliche pub. Le dichiarazioni straniere utilizzano esplicito extern chiamando convention/link metadati e non è sicuro chiamarli finché non vengono inseriti in una funzione sicura controllata. La classificazione degli argomenti della piattaforma C è specifica del target: Windows x86-64 passa indirettamente parametri aggregati più grandi di otto byte, quindi str, le fette e le strutture C equivalenti interagiscono con MinGW/MSVC-style chiamati.

Tipi di nucleo

Categoria Tipi
controllo void, never, bool
intero i8, i16, i32, i64, u8, u16, u32, u64, isize, usize; byte alias u8
galleggiare f32, f64
text/buffer str, string, bytes, shared_bytes
formattazione format_args (effimero)
aggregate/view [N]T, []T, mut []T, tuple, nominale structs/enums/unions
fallimento ?T, Result<T, E>, alloc_error
richiamabile non proprietario fn(T) -> U, in fuga box fn(T) -> U
di basso livello puntatori grezzi più user, kernel, physical, mmio, e dma spazi di indirizzi
esatto-una volta linear T

AllocResult<T> abbrevia Result<T, alloc_error> senza introdurre una nuova identità di tipo, rappresentazione, regola di pulizia o ABI.

Ospitato main potrebbe tornare Result<i64, E>. Ok(status) esce con quello stato; alloc_error utilizza la diagnostica dell'allocazione fissa. Un altro E deve essere Copia, non avere distruttore e implementare @borrow fn E.display() -> str; la sua vista viene scritta una volta prima dello stato 1, dopo la pulizia ordinaria.

@static_view extern fn ... è la dichiarazione FFI sottoposta ad audit per un reso str/slice di cui si trova l'archiviazione process/static tutta la vita. L'attributo viene rifiutato in via ordinaria seed funziona e non rende sicura la chiamata estera.

Gli attributi degli effetti possono annotare dichiarazioni fn: @no_alloc, @allocates, @blocking, @panics, @io, @interrupt_safe. I tipi di callback qualificati utilizzano @no_runtime_effects fn(...) -> T per dichiarare un riepilogo completo degli effetti vuoto. Uno unsafe struct può dichiarare @unsafe_send per affermare la capacità di invio o @repr("null_niche") per abilitare l'ottimizzazione del puntatore nullo su un singolo campo puntatore non elaborato per ?Wrapper.

Il numero intero add/subtract/multiply esegue il ritorno a capo in modo deterministico in base alla larghezza del tipo. Divisione per zero, minimo con segno diviso per -1, spostamenti non validi, cast sicuri non validi e trap di indicizzazione sicura non riuscita. I profili di rilascio preservano queste regole. L'ampliamento esplicito degli interi utilizza la firma dell'origine; il restringimento mantiene i bit bassi e le modifiche di uguale larghezza preservano i bit. Integer/float e i cast di larghezza float seguono la conversione IEEE-754. La conversione da virgola mobile a intero richiede unsafe e un input rappresentabile con destinazione finita.

I letterali byte utilizzano b'A' e avere tipo u8. Un byte ASCII grezzo o uno \\n/\\r/\\t/\\0/\\\\/\\'/\\xNN la fuga è accettata. Utilizzare b'\\xFF' per un byte non ASCII; seed deliberatamente non ha un tipo letterale di carattere dipendente dalla locale.

I valori letterali interi sono decimali, 0x esadecimali o 0b binari, con _ come separatore di cifre opzionale (20_000_000, 0xFF, 0b1010). Ogni forma accettata raggiunge codegen ovunque sia consentito un letterale, inclusi i letterali di array e i letterali di ripetizione.

Un valore letterale di array ripetuto riempie un array fisso da un valore letterale: let slots: [4]usize = [0; 4], [255; 3], [[0; 2]; 3]. Il tipo di elemento proviene dall'annotazione o dal tipo previsto dell'array, quindi non è necessario alcun cast. Il valore deve essere un valore letterale (o un cast di uno, o un array di questi) - un valore di luogo o chiamata viene rifiutato come B048 anziché valutato silenziosamente una volta per elemento - e il conteggio deve essere un valore letterale intero positivo (B049) al massimo di 65536 (B050), perché gli elementi vengono materializzati individualmente; i riempimenti più grandi appartengono a un buffer heap o a un ciclo esplicito.

Strutture, ADT e unioni

struct Document {
    title: string
}

enum LookupResult {
    Found(Document)
    Missing
}

union ScalarBits {
    integer: u64
    decimal: f64
}

trait Identity {
    fn id() -> i64
}

Una struttura letterale è Document { title: owned_title }. Un costruttore ADT è qualificato, ad esempio LookupResult.Found(value)e il suo carico utile viene ispezionato in modo esaustivo match. Un'enumerazione senza payload:

enum Color { Red Green Blue }

L'unione grezza construction/access non è sicura. Le alternative con tag sicuri utilizzano ADT.

Opzioni, risultati e propagazione

fn find(enabled: bool) -> ?i64 {
    if enabled { Some(42) } else { None }
}

fn allocate_name(view: str) -> Result<string, alloc_error> {
    view.to_string()
}

Some(value) e None di tipo previsto costruiscono un'opzione. Ok(value) e Err(problem) costruiscono un risultato. ? consuma il contenitore, cede il suo payload success/present o restituisce l'errore corrispondente dalla funzione corrente. La propagazione dei risultati può modificare il tipo di successo ma deve preservare il tipo di errore. Non esegue alcuna allocazione o clonazione implicita.

is_some/is_none e is_ok/is_error ispezionare tramite prestito condiviso. unwrap_or(fallback) consuma il contenitore e pulisce il valore posseduto non selezionato esattamente una volta. or_abort(), expect(message)e solo principale or_exit(status) sono confini espliciti dell'applicazione; non si nascondono mai nell'ordinario ? propagazione.

? può attraversare un limite spawn quando il corpo è fallibile: spawn { fallible_work()? } memorizza Result<T, E> in una cella di join e l'espressione spawn restituisce un handle task_join il cui wait() restituisce Result<T, E>; payload ed errore devono essere tipi di copia senza distruttori. Un ? all'interno di una chiusura nidificata in un corpo di spawn vuoto viene comunque rifiutato.

Controllare il flusso e i modelli

I moduli di controllo implementati sono orientati all'espressione if/else if/else, while, loop, for, esaustivo match, blocchi, break, continue, e return. else if è l'ortografia richiesta; elif non è accettato. Le braccia della corrispondenza non hanno bisogno di virgole a meno che il confine non sia ambiguo: un braccio il cui corpo termina con un'espressione seguita da a (/[ il modello richiede la virgola (B044). Copertina dei modelli bindings/discards, valori letterali, tuple, strutture e varianti ADT qualificate; le guardie mantengono uno scrutatore di sola mossa finché il braccio selezionato non lo trasferisce effettivamente. _ è un vero e proprio scarto vincolante: let _ = expr valuta e ripulisce senza vincolare, ripetuto _ in un ambito è legale, e _ non è mai accessibile. ref è un modificatore di modello contestuale che vincola un carico utile di solo spostamento con un prestito di sola lettura quando l'esaminatore è un luogo preso in prestito (Some(ref info) su a @borrow self campo); i collegamenti ref non possono essere spostati o modificati, ref _ scarta senza muoversi, e una partita il cui carico utile di sola mossa è legato all'arbitro non consuma lo scrutinatore. Gli esaminatori temporanei i cui carichi utili di solo spostamento del trasferimento di armi vengono materializzati in un legame di proprietà implicita, quindi match fallible() { Ok(v) => ... } compila senza a let x = expr involucro.

if let e while let sono le forme concise rispetto a match: if let Some(x) = found { ... } else { ... } e while let Some(x) = next { ... }. Entrambi si dezuccherano in una partita a due braccia, quindi vincolante, comportamento move/borrow e pulizia sono esattamente le regole della partita. if let Some(...) nomina il suo complemento None; qualsiasi altro modello variante mantiene un braccio jolly e H032 rifiuta che quando l'esaminatore trasporta un carico utile di solo movimento: scrivi lì i bracci match espliciti. Un modello inconfutabile (while let name = value) viene rifiutato come H029.

for su intervalli, array fissi e sezioni si riducono a un'allocazione libera index/length ciclo. for index, value in enumerate(items) aggiunge a usize indice senza un iteratore heap. Gli elementi di solo spostamento richiedono esplicitamente indexing/ownership manipolazione.

Testo, visualizzazioni e conversioni

L'interpolazione digitata phase-1/2 è esente da allocazione a meno che non sia esplicitamente materializzata:

use "file"

fn main() -> Result<i64, alloc_error> {
    let name = "widget"
    let count = 3
    write_stdout_format(f"name={name} count={count} braces={{ok}}\n")
    let message = f"count={count}".to_string()?
    Ok(len(message) as i64)
}

Le espressioni valutano una volta da sinistra a destra. I valori supportati sono str, preso in prestito string, bool, e numeri interi incorporati - come espressioni arbitrarie, non solo nomi: chiamate, operatori e nidificazione funzionano tutti (f"{a + b}", f"{p.distance()}"). L'effimero format_args il risultato deve essere passato direttamente o consumato da .to_string()?; non può essere assegnato let, restituito, catturato o archiviato. Integer/text/bool sono implementate le specifiche di larghezza, riempimento, allineamento e base intera. Utilizzo di tipi personalizzati trait Display { @borrow fn display() -> str } con invio statico diretto. I float supportano l'output generale predefinito plus f/F, e/E, e g/G con precisione fino a 18. Personalizzato :? la formattazione utilizza l'analogo preso in prestito Debug.debug() -> str tratto.

Generi e tratti

I parametri generici utilizzano UpperCamelCase. Le definizioni vengono verificate rispetto ai loro limiti, quindi le istanze concrete raggiungibili vengono monomorfizzate. Un parametro può dichiarare più limiti di tratto con + (fn f<T: Metric + Named>(x: T)); ogni limite deve nominare un tratto dichiarato, l'argomento deve implementarli tutti (error[H072] per limite mancante) e i metodi dei tratti si risolvono attraverso qualsiasi limite. I blocchi impl possono essi stessi essere generici: impl<T: Show> Show for Pair<T> implementa il tratto per ogni istanza i cui argomenti soddisfano i limiti di impl; gli argomenti di destinazione devono essere esattamente i parametri dell'impl in ordine (error[P042]) e un impl generico che si sovrappone a un altro impl della stessa caratteristica per lo stesso tipo viene rifiutato (error[R019]). L'invio dei tratti è statico e diretto: non sono presenti vtable, boxing, allocazioni o cloni impliciti. Vengono verificati la completezza dell'implementazione, le firme, la coerenza e le regole orfane. Modelli generici pubblici, istanze comuni, parametri format_args effimeri, rappresentazione nominale di nicchia nulla, ricevitori modificabili esclusivi, callback qualificati e firme richiamabili in scatola persistono nell'attuale schema-17 .sdi. Le istanze del metodo materializzato vengono esportate solo da un'interfaccia che possiede anche la definizione del metodo generico. Un involucro attorno ad un tipo generico importato registra quindi il suo contratto pubblico senza una specializzazione orfana; un consumatore eliso alla fonte ottiene il modello del metodo dall'interfaccia di dipendenza del wrapper e materializza lì l'istanza concreta.

inline fn richiede l'inlining limitato. Un pub inline fn pubblica il proprio corpo verificato e l'hash del corpo deterministico nello schema-13 .sdi mantenendo un simbolo di fallback esportato. Le dichiarazioni in linea hanno un budget di origine di 4096 byte; una modifica del corpo invalida gli artefatti dipendenti. Le partizioni di slice mutabili utilizzano view.split_at_mut(index) e i modelli di tupla possono dichiarare associazioni mutabili come (mut left, mut right). Gli assegni divisi index <= len, non assegnano nulla e mantengono il proprietario comune in prestito esclusivo fino alla morte di entrambi i fratelli.

Chiusure e richiamate

fn apply(values: [3]i64, callback: fn(i64) -> i64) -> i64 {
    let mut total = 0
    for value in values {
        total = total + callback(value)
    }
    total
}

fn main() -> i64 {
    let base = 40
    let total = apply([1, 2, 3], |value: i64| base + value)
    let retained = (box |value: i64| base + value).or_abort()
    total + retained(1)
}

|...| e la posizione del prefisso || creano richiamabili anonimi. I tipi di parametri possono essere omessi quando vengono forniti da un fn(...) -> T previsto. Una chiusura semplice utilizza l'archiviazione di cattura dello stack, non alloca nulla e non può sfuggire al suo proprietario lessicale. La funzionalità di copia acquisisce la copia; le catture possedute si spostano; le acquisizioni sono immutabili. Acquisizioni prese in prestito, modificabili, legate a una regione, già spostate e altre acquisizioni non sicure da archiviare vengono rifiutate.

box |...| è la forma di escape esplicita e restituisce Result<box fn(...) -> T, alloc_error>. Il proprietario può essere archiviato o restituito, ma è di solo spostamento, non clonabile e non inviabile. Drop distrugge le sue catture esattamente una volta e libera la sua allocazione. L'assegnazione regionale rimane lessicale. Non esiste alcuna conversione implicita tra chiusure stack e boxed.

I callback seed fn(...) -> T utilizzano un descrittore code/environment a un puntatore. I puntatori alle funzioni C/platform rimangono sottili e accettano solo funzioni con nome. Gli effetti di chiusura vengono dedotti dal corpo e confrontati con contratti di callback qualificati come @no_runtime_effects fn() -> void. Le chiusure ricorsive non sono supportate.

Riepilogo della proprietà

Vedere Proprietà per il modello operativo.

Regioni, attività e biblioteche

region(capacity) { body } installa un allocatore di bump controllato dal lessico. Valori, visualizzazioni o puntatori legati alla regione non possono sfuggire. Attività strutturate acquisite all'interno di un'unione di regioni prima che venga rilasciato lo spazio di archiviazione di backup.

spawn { body } è strutturato: ogni bordo che lascia l'ambito lessicale proprietario attende il proprio gruppo di lavoro prima della pulizia. La cattura è la copia o lo spostamento in base alla funzionalità. Un corpo fallibile (? all'interno o una coda di tipo Result<T, E>) produce un join digitato: la struttura memorizza il risultato in una cella di join e handle.wait() ritorna Result<T, E>; task_result_* rimane per le unioni manuali. Canali, join digitati, eventi, cancellazione e sincronizzazione sono forniti dall'ordinario compiler/llvm/libs/task pacchetto. La grammatica pulita non ha built-in chan<t>, send, recvo spawn distaccato.

use "name" importa un modulo sorgente o un file elidato dal codice sorgente .sdi interfaccia. Le funzioni pubbliche importate sono richiamabili con o senza il qualificatore del modulo: use "process" li fa entrambi environment("HOME") e process.environment("HOME") valido. Viene segnalato un simbolo qualificato sconosciuto error[H002]: unknown symbol in module.

Substrato non sicuro

raw_try_alloc<t>, raw_null<t>, raw_is_null<t>, raw_read<t>, raw_write<t>, raw_free<t>, raw_slice<t>, atomici, accesso volatile, recinzioni, cast dello spazio degli indirizzi, assemblaggio grezzo, FFI, le chiamate di sistema e le unioni grezze richiedono unsafe. Le normali applicazioni dovrebbero utilizzare wrapper sicuri dalle librerie.

Lanciatore di archivi

./seed/seed check [--lib] [path|file.sd]
./seed/seed check [--json|--deep] [--report report.json] [--max-ms n] [--max-rss-kib n] [--max-files n] [--max-loc n] [--lib] [path|file.sd]
./seed/seed build [path] [-o output] [compiler flags]
./seed/seed run [path] [-- program arguments]
./seed/seed test [path] [compiler flags]
./seed/seed format [--check] [file.sd]
./seed/seed fmt [--check] [file.sd]  # short alias
./seed/seed fmt --write directory/
./seed/seed fmt --check --json [--output file] [file.sd|directory]

With `--check`, a directory recursively checks its `.sd` files; `.git`,
`target`, and `.seed` directories are ignored.
With `--json`, the formatter emits `seed.format.v1` with per-file status and
stable checked/needs-format/error counts; a non-zero status still includes the
complete JSON result.
./seed/seed new path [--name package_name]
./seed/seed pkg resolve|add|update|prune ...
./seed/seed install [path|package] [--profile release] [--system] [--prefix path] [--dry-run]
./seed/seed uninstall package [--system] [--prefix path] [--dry-run]
./seed/seed doc [path] [--json] [--check-links] [--output file]
./seed/seed lint [--json] [--deny-warnings] [--cache dir] [--no-cache] [--fix] [--output file] [path]
./seed/seed explain [--json] CODE
./seed/seed explain [--json] --list
./seed/seed lsp
./seed/seed repl [--json]
./seed/seed publish --check [--json] [path]
./seed/seed publish --check [path]
./seed/seed mobile android <setup|sign|build|stage|check|package|run|doctor>

check è un controllo ristretto della fonte diretta che gestisce l'intera pipeline semantica, inclusa ogni prova di sicurezza obbligatoria (proprietà, provenienza, effetti, pulizia, prestiti, concorrenza); il riutilizzo di un HIR memorizzato nella cache non ne ignora nessuno. check --deep aggiunge solo il passaggio della lanugine didattica dopo il superamento del controllo semantico; non sostituisce mai una dimostrazione. Si risolve in modo relativo source/interface importazioni e manifesto locale path dipendenze; non compila prima un pacchetto di repository nudo mancante. Utilizzare build o run durante la convalida dell'integrazione del pacchetto che dipende dalla gestione temporanea automatica della libreria principale.

check --report report.json scrive un deterministico seed.check-report.v1 riassunto con la fonte, file/LOC conteggi, flag di modalità profonda, risultato, tempo totale trascorso e fasi separate di risoluzione della sorgente, controllo semantico e (quando richiesto) deep-lint. Sugli host POSIX registra anche peak_child_rss_kib per il compiler/lint sottoprocessi. Se la lanugine profonda non riesce, il rapporto contrassegna sia la fase di lanugine profonda che il risultato complessivo come fail e include il suo error/warning conta. Il rapporto include anche i tempi della fase del compilatore interno e il picco RSS quando il file LLVM il profiler è disponibile. --max-ms e --max-rss-kib aggiungere budget CI espliciti; sono controlli post-esecuzione: il sottoprocesso del compilatore viene eseguito fino al completamento, quindi gli strumenti valutano il tempo di wall (dall'avvio dello strumento) e il picco RSS del figlio rispetto ai massimali. I budget superati vengono registrati nel report e il comando non riesce dopo aver emesso un output strutturato (budgets.violations più il distinto check budget exceeded errore). --max-files e --max-loc applicare la stessa politica alla dimensione dell'origine raggiungibile.

Gli errori del compilatore si dividono in due classi. Un errore semantico è una violazione del programma segnalata come diagnostica specifica (codici come S001, H022) con intervalli, note e aiuto. Un errore dell'infrastruttura (memoria esaurita del compilatore o violazione del contratto della toolchain) viene segnalato come error[I-code]: detail (I900 fallback) o il messaggio generico "il compilatore ha esaurito la memoria o ha violato un contratto dell'infrastruttura", senza alcun artefatto di output pubblicato. Nemmeno il lato programma alloc_error, che è un tipo di risultato di runtime recuperabile all'interno dei programmi generati (vedere il capitolo sulla proprietà).

check --json emette la diagnostica leggibile dalla macchina del compilatore più il check source e una stalla summary con error/warning conta. Può essere combinato con --deep per includere il seed.lint.v1 carico utile di lanugine profonde; aggiungere --deny-warnings per fare in modo che gli avvisi del compilatore e del deep-lint falliscano il controllo pur emettendo il file complete JSON busta. --output file lo scrive JSON atomicamente e mantiene pulito lo stdout, anche quando il controllo fallisce.

doc --json emette un seed.doc.v1 indice della documentazione contenente dichiarazioni pubbliche, Markdown renderizzato, dipendenze solo dell'interfaccia e diagnostica dei collegamenti strutturati. doc --check-links trasforma i collegamenti non risolti in uno stato di errore. lint --deny-warnings allo stesso modo trasforma gli avvisi di lanugine in uno stato di errore senza modificare il comportamento di avviso predefinito; lint --output file scrive il JSON o il risultato del testo in modo atomico, anche in caso di esecuzione di lanugine non riuscita. I risultati lint vengono riutilizzati da una cache per origine indirizzata al contenuto in .seed/cache/lint per impostazione predefinita; --cache dir o SEED_LINT_CACHE lo sovrascrive e --no-cache impone una corsa a freddo. --prune-days N rimuove le vecchie voci della cache e segnala il conteggio. SEED_BUILD_JOBS controlla i controlli delle sorgenti parallele limitate preservando l'ordine diagnostico. Le voci della cache utilizzano l'estensione seed.lint-cache.v1 busta; le voci non valide o più vecchie vengono ricostruite e segnalate come cache.invalidated. Solo documentazione L001 la diagnostica viene memorizzata nella cache in modo indipendente per dichiarazione pubblica, quindi le modifiche non correlate possono riutilizzarla; il controllo semantico rimane all'interno dell'intero codice sorgente. --fix applica solo correzioni sicure dei commenti della documentazione e disabilita il riutilizzo della cache per quell'esecuzione.

La cache HIR verificata del compilatore può essere mantenuta esplicitamente con --cache-prune-days N insieme a --cache-dir dir. Rimuove solo i file di identità regolari .hci obsoleti da quella directory; vengono conservati file non correlati, collegamenti simbolici, pubblicazioni temporanee e voci recenti. La potatura è consultiva e non ignora mai la compilazione o la verifica di sicurezza.

explain --json CODE emette un record seed.explain.v1 contenente il titolo, il significato, un esempio non valido e una guida alla riparazione per un codice diagnostico. Senza --json, mantiene la spiegazione in forma lunga orientata all'uomo. explain --list enumera il catalogo disponibile; La modalità JSON emette seed.explain-catalog.v1 con i record strutturati completi.

repl è una sessione orientata alla linea di solo controllo. Ogni riga inserita viene convalidata come parte della corrente fn main regione prima di essere accettato. Utilizzo delle regioni multilinea :begin e :end transazionale; :check, :show, :reset, :undo, :help, e :quit gestire la sessione. :show stampa solo la regione accettata, esclusa qualsiasi transazione aperta. Non esegue codice né indebolisce le regole di proprietà. Il completamento LSP segue la grammatica corrente, incluso return, loop, break, e continue; le ortografie legacy rimosse non sono suggerite. repl --json ne emette uno seed.repl-event.v1 JSON oggetto per evento per editor e consumatori di automazione, comprese le righe di transazione in sospeso e l'uscita dalla sessione. check --max-files N e check --max-loc N rifiutare progetti che superano i budget espliciti su scala di fonti raggiungibili e registrare le violazioni nel rapporto di controllo e JSON busta diagnostica. Il JSON la busta espone anche osservata metrics per file raggiungibili, LOC, millisecondi trascorsi e picco RSS figlio. Il result il campo è esplicitamente pass o fail, compresi i fallimenti di bilancio. Con --report, JSON La modalità incorpora anche il report completo della fase mentre scrive in modo atomico il file di report richiesto.

publish --check --json emette seed.publish-check.v1 con il pacchetto, la versione e pass/fail risultato per integrazioni CI; --output file lo scrive atomicamente. Gli errori di convalida restituiscono comunque uno stato diverso da zero dopo aver emesso il risultato strutturato. Gli inviluppi di fallimento includono stabile error_code e il risolto project, quindi i consumatori non hanno bisogno di analizzare il testo dell'errore umano. Le classi conosciute includono PUBLISH_MANIFEST, PUBLISH_LICENSE, PUBLISH_DEPENDENCY, PUBLISH_PLATFORM, e PUBLISH_FFI_INSTALL.

build esegue la compilazione incrementale con risoluzione automatica delle dipendenze. Importazioni di pacchetti semplici (ad es. use "vec") sono allestiti in modo isolato target/profile negozio. Una seconda build riutilizza la corrispondenza .sdi/artefatti nativi. test inoltra i flag finali del compilatore, inclusi quelli ripetuti --link-object e --link-library input, a ogni binario di test. Ciò è necessario per i test della libreria la cui superficie Seed sicura è supportata da un nativo esterno ABI.

install compila il pacchetto in modalità di rilascio e lo installa a livello di sistema: eseguibili in ~/.local/bin (o /usr/local/bin con --system), generazioni di dipendenza a ~/.local/lib/seed/generations/e si interfaccia con ~/.local/share/seed/interfaces/. Utilizzare --profile debug per build di debug e --prefix /custom/path per posizioni di installazione personalizzate.

uninstall rimuove un pacchetto installato in precedenza e le relative generazioni di dipendenze. Sia install che uninstall supportano --dry-run per l'anteprima. Il record del pacchetto installato transazionale include destinazione, profilo, identità di generazione delle dipendenze, checksum del compilatore, checksum dell'artefatto installato, checksum dell'origine e checksum del blocco in modo che un'applicazione distribuita possa essere tracciata fino ai suoi esatti input di build.

La pubblicazione remota è separata; seed publish --check convalida l'integrità del pacchetto e del blocco localmente senza eseguire script senza restrizioni. I pacchetti compilati utilizzano la destinazione qualificata .sdi inoltre --install-library/--install-interface. Dichiarazione dei pacchetti extern fn deve anche fornire INSTALL.md descrivere la configurazione nativa richiesta per le piattaforme dichiarate; il file deve essere leggibile UTF-8 e non vuoto. I monorepos locali possono mantenere più pacchetti con versione indipendente collegati da relative path dipendenze. I checksum dell'albero guidano le ricostruzioni; lo sviluppo locale ordinario non richiede un repository, un tag o una pubblicazione Git per ciascuna libreria.

Il programma di avvio legge [build].profile = "debug" | "release" | "release-small"; il vecchio release = true è mappato su release. Un profilo CLI esplicito sovrascrive il manifest. Per impostazione predefinita seed install viene rilasciato indipendentemente dal manifest a meno che --profile non sia esplicito. L'impostazione predefinita delle applicazioni è src/main.sd; una cassaforte relativa opzionale [package].entry seleziona un'altra fonte all'interno del pacchetto. Le importazioni di pacchetti semplici si risolvono prima con gli artefatti installati corrispondenti; altrimenti vengono compilati con il profilo dell'applicazione in un archivio target/profile isolato. Le build ospitate li collegano dinamicamente per impostazione predefinita. Una seconda build riutilizza gli artefatti .sdi/nativi corrispondenti; le modifiche alla libreria dinamica privata non ricostruiscono i consumer, mentre le modifiche pubbliche .sdi o ABI lo fanno.

L'installazione dell'utente inserisce gli eseguibili ~/.local/bin, generazioni di dipendenza immutabile in ~/.local/lib/seede i mirror dell'interfaccia con versione sono sotto ~/.local/share/seed/interfaces. --system utilizza l'ambito del sistema della piattaforma (/usr/local su Unix); --prefix sovrascrive la radice. L'installazione e la rimozione sono registrate in base alla proprietà e sono atomiche e nessun comando modifica silenziosamente i file di avvio della shell o le variabili di ambiente del caricatore.

Operatori

Precedenza binaria dal più alto al più basso:

  1. moltiplicativo (*, /, %)
  2. additivo (+, -)
  3. turni (<<, >>)
  4. confronti (<, <=, >, >=)
  5. uguaglianza (==, !=)
  6. AND bit per bit (&), XOR (^), OR (|)
  7. AND logico (&&)
  8. OR logico (||)

&& e || cortocircuito: a && b valuta b solo quando a è true, e a || b valuta b solo quando a è false. Entrambi gli operandi devono esserlo bool e il risultato è bool. Il cortocircuito si applica anche al ripiegamento costante, quindi false && expensive() e true || expensive() sono espressioni costanti valide anche quando expensive() non è costante.

Compilatore pulito diretto

L'eseguibile è compiler/llvm/build/seed. Il suo elenco di flag autorevole è seed --help.

# Source processing
seed --check source.sd
seed --format|--format-check|--format-write source.sd

# Code generation
seed --emit-llvm out.ll source.sd
seed --emit-object out.o source.sd
seed --emit-binary out source.sd
seed --emit-shared library.so source.sd
seed --emit-static-library library.a source.sd
seed --emit-raw out.bin source.sd
seed --run source.sd -- arguments

# Interface inspection
seed --interface-print file.sdi
seed --interface-hash file.sdi
seed --emit-interface out.sdi source.sd

# Library management
seed --install-library artifact --install-interface file.sdi --package name [--seed-home path]

# Debug dumps
seed --lex source.sd
seed --ast-print source.sd
seed --types-print source.sd
seed --symbols-print source.sd
seed --hir-print source.sd
seed --safety-print source.sd
seed --mir-print source.sd
seed --layout-print source.sd
seed --abi-print source.sd
seed --low-mir-print source.sd
seed --llvm-print source.sd

# Build options
seed --release source.sd
seed --release-small source.sd
seed --thin-lto source.sd
seed --pgo-generate dir source.sd
seed --pgo-use profile source.sd
seed --profile-print source.sd
seed --target target source.sd
seed --runtime linux-native|linux-libc source.sd
seed --runtime-profile profile source.sd
seed --runtime-feature feature source.sd
seed --static source.sd
seed --static=all source.sd
seed --sysroot path source.sd
seed --soname name source.sd
seed --entry symbol source.sd
seed --linker-script path source.sd
seed --code-model model source.sd
seed --relocation-model model source.sd
seed --no-red-zone source.sd
seed --link-object file.o source.sd
seed --link-library lib.so|lib.a|package source.sd
seed --cache-dir path source.sd
seed --seed-home path source.sd
seed --package name source.sd

# Diagnostics
seed --diagnostics human|json source.sd
seed --version
seed --help

Debug/inspection le modalità includono token, AST, tipi, simboli, HIR, sicurezza, MIR, layout, ABI, MIR basso e LLVM stampa. Target/runtime le opzioni includono --target, --runtime-profile, --runtime-feature, --runtime, --sysroot, entry/linker-script controlli e separati object/library collegamento.

--release usi seed-safe-o2-v1; --release-small usi seed-safe-oz-v1. Entrambi sono sicuri. ThinLTO e PGO sono opzioni esplicite di sola versione; il collegamento statico è indipendente. Non esiste alcun operativo --unchecked o --fast-unsafe profilo.

Stato dell'obiettivo

Il supporto degli oggetti e il supporto ospitato end-to-end sono affermazioni separate. Linux x86-64/AArch64 sono i percorsi ospitati chiusi. Indipendente x86-64/AArch64/RISC-V64 avere prove di avvio ai livelli dichiarati. Windows x86-64 ha PE/runtime/DLL/ task/network prova sotto richiesta Vino. macOS x86-64 e arm64 hanno un SDK esplicito executable/dylib/static collegamento, runtime e pianificazione pthread. Intel nativa x86-64 l'esecuzione rimane; arm64 è solo cross-link. Vedi compiler/llvm/tests/GATE14_TARGET_MATRIX.tsv.

Su un Mac Intel, esegui SEED_MACOS_RUNNER_POLICY=required make -C seed/compiler/llvm gate14-macos-x86_64-test. Lo script rileva l'SDK con xcrun e utilizza ld di Apple a meno che non venga sovrascritto esplicitamente.