Referencia de Diagnósticos

La igualdad entre floats es imprecisa. Usa `~=` (tolerancia adaptativa), `!~=` o `math.approx_eq_abs/_rel(...)`. Para comparaciones exactas, usa el tipo `decimal`.

Una variable `let` o parámetro nunca se lee. Prefija el nombre con `_` para silenciar el lint intencionalmente.

Una función de nivel superior nunca se llama y no está marcada con `pub`, `@test`, `@bench`, `@export`, ruta HTTP ni `main`.

Un nombre importado nunca se referencia en el archivo.

Un `let` re-vincula un nombre de un ámbito externo. El shadowing a veces es intencional; renombra uno de los bindings para silenciar la advertencia.

El código tras `return`, `break` o `continue` es inalcanzable.

Funciones/variables usan `snake_case`; structs/enums/traits/efectos usan `PascalCase`.

Una función o tipo anotado con `@must_use` retornó un valor que el llamador descartó. Vincúlalo (`let _ = ...`) o consúmelo.

Se llamó una función anotada con `@deprecated`. El mensaje de la anotación explica el reemplazo.

Un bloque `loop`/`while true` no tiene ningún `break`/`return` alcanzable.

Un uso de `Some(...)` / `None` / `?.` / `??` que parece un error tipográfico o mal uso de la API de opcional.

Un `match` sobre un enum no cubre todas las variantes y no tiene un brazo comodín `_`.

Un patrón nunca coincide porque un brazo anterior ya lo cubre.

Configurado vía lint config del proyecto. El predeterminado es permisivo; ajústalo en CI si quieres límites estrictos.

El anidamiento profundo perjudica la legibilidad. Extrae helpers o usa guard clauses con return temprano.

Las listas largas de parámetros son un code-smell. Considera agrupar parámetros relacionados en una struct.

Divide la función en helpers más pequeños.

Solo se reconocen `@repr(C)`, `@repr(packed)`, `@repr(transparent)` y `@repr(zolo)`.

`transparent` solo se aplica a structs newtype de un único campo.

`@layout` solo tiene efecto junto a un `@repr` explícito.

La alineación debe ser una potencia de dos positiva.

Las reglas de alineación de hardware requieren valores potencia de dos (1, 2, 4, 8, ...).

La alineación solicitada excede el máximo soportado por la plataforma destino.

El tamaño no puede ser cero ni negativo.

El lexer llegó al fin de archivo (o de línea, en algunos contextos) antes de encontrar la comilla de cierre de la cadena.

El parser esperaba un token específico (por ejemplo `}`, `)`, identificador, tipo) pero encontró otra cosa. Suele ser una llave, paréntesis o puntuación ausente.

Un token apareció donde la gramática no lo permite — típicamente un símbolo perdido, una palabra clave mal escrita o un separador faltante en la línea anterior.

Un error de parseo que no coincidió con ningún clasificador específico. Lee el mensaje del diagnóstico para la causa precisa.

Se escribió un comentario `<!-- -->` entre `<` y `>`, donde el propio HTML tampoco lo permite. Dentro de la etiqueta, usa los comentarios de Zolo: `//` o `/* */`. En los hijos de un elemento, `<!-- -->` sí funciona.

`<style>` y `<script>` son elementos de texto crudo: su contenido corre literal hasta el `</style>`/`</script>` correspondiente, sin markup anidado y sin interpolación `{expr}`. Llegar al final del archivo antes de ese cierre reporta TE139 en lugar del mensaje genérico "unclosed element" — normalmente una etiqueta de cierre olvidada, o una cadena con forma `</tag` dentro del contenido (por ejemplo, un literal de cadena JS) que cerró el bloque antes de tiempo.

Equivalente a `TE001`. Emitido por el clasificador heredado cuando el nuevo typeck no adjuntó un código.

Alias heredado para `TE100`.

Alias heredado para `TE101`.

Alias heredado para `TE004`. La variable se declaró con `let`; usa `let mut` para permitir reasignación.

Alias heredado para `TE102`.

Un literal de struct omite uno o más campos obligatorios.

Alias heredado para `TE110`.

El valor retornado no coincide con el tipo de retorno declarado por la función.

Un nombre (función, variable, campo, variante) se declaró dos veces en el mismo ámbito.

Una anotación de tipo se refiere a un tipo que el compilador no puede encontrar.

El valor asignado a un binding `let` no satisface la anotación de tipo declarada.

El valor asignado a un binding `const` no satisface la anotación de tipo declarada.

`const` requiere una expresión constant-foldable. Usa `let` para valores en runtime.

Los bindings `let` son inmutables por defecto. Usa `let mut x = ...` para permitir reasignación, o crea un nuevo binding con shadowing via `let`.

Operadores como `+=`, `-=`, `*=` requieren que ambos lados sean numéricos (o cadenas, para `+=`).

La función declaró un retorno en tupla, pero la sentencia `return` proporciona menos valores.

La función retorna más valores de los que su tipo de retorno único puede contener.

Un literal de array mezcla tipos incompatibles; los arrays son homogéneos.

La aritmética binaria requiere que ambos operandos sean numéricos y (en modo strict) del mismo tipo numérico.

El nombre no está declarado en ningún ámbito envolvente. El compilador adjunta una sugerencia "¿quisiste decir?" cuando existe un nombre similar.

El objetivo de una expresión de llamada no es un tipo invocable.

La struct no declara este campo. Se adjuntan sugerencias "¿quisiste decir?" para nombres similares.

Una anotación de tipo o campo de variante de enum hace referencia a un tipo que el compilador no puede resolver.

El tipo receptor no tiene un método con ese nombre. Verifica la ortografía, los imports y la visibilidad del trait.

Un nombre simple corresponde a un módulo conocido de la biblioteca estándar (`math`, `json`, `http`, `os`, …) que nunca se trajo al ámbito. A diferencia de TE100, el compilador reconoce el nombre e indica exactamente qué línea `use` falta.

Un literal de struct omite un campo que no tiene valor por defecto ni zero-value de respaldo. Todo campo sin default debe proporcionarse explícitamente en la construcción.

Un struct con `@derive(Default)` tiene un campo cuyo tipo no posee zero-value ni default explícito, por lo que no se puede sintetizar ninguna impl de `Default`.

Un campo de struct se escribió sin anotación de tipo, apoyándose en su valor por defecto para inferirlo (`nombre = valor`) — pero el tipo de ese valor es ambiguo (p. ej. `nil`, o una expresión que resuelve a `any`).

El número de argumentos pasados no coincide con la cantidad de parámetros de la función.

El tipo de un argumento no coincide con el tipo del parámetro correspondiente.

Dos o más campos embebidos con `using` declaran un campo con el mismo nombre, por lo que un acceso `.campo` en el struct externo no sabe de cuál embed promoverlo.

Un campo marcado con `using` debe embeber otro struct — son sus campos los que se promueven. Un escalar, o cualquier tipo que no sea una declaración de struct conocida, no tiene campos que promover.

Un enum optó por discriminantes numéricos (tipo de respaldo, o un `= n` explícito) pero es genérico o tiene una variante con payload. Los discriminantes solo tienen sentido para enums planos, con todas las variantes unitarias.

El discriminante de una variante está fuera del rango del tipo de respaldo declarado (`enum E: u8` lo limita a `0..=255`), por lo que no sobreviviría al ida y vuelta de `to_int()`/`from_int()`.

Dos variantes del mismo enum resolvieron al mismo entero — o dos `= n` explícitos colisionan, o un valor autoincrementado cayó sobre uno ya usado.

Bajo `@stable` el autoincremento está prohibido: insertar una variante en el medio renumeraría silenciosamente todas las siguientes, rompiendo la codificación que la anotación promete mantener.

El discriminante `= expr` de una variante o no evaluó a un entero en tiempo de compilación, o no pudo evaluarse como constante de compilación.

Un enum `@flags` es genérico o tiene una variante con payload. `@flags` modela una bitmask sobre un conjunto fijo y plano de variantes unitarias — no hay espacio para parámetros de tipo ni payloads.

Cada variante `@flags` debe ser un bit nuevo (autoincrementado o potencia de dos explícita) o un compuesto nombrado construido solo a partir de bits declarados encima de ella.

El valor de una flag está fuera del rango del tipo de respaldo del enum — las flags en `enum: u8` llegan hasta `255` (bit 7).

Dos flags de un solo bit en el mismo enum `@flags` resolvieron al mismo bit, normalmente porque recibieron el mismo valor explícito.

Un patrón de destructuring — `let Struct { … } = expr`, un `let { … }` anónimo, un patrón de parámetro o una asignación con destructuring de struct — nombra un campo que el struct no tiene.

El bloque `else` puede caer fuera. Si lo hiciera, la ejecución seguiría hacia los bindings del patrón con un valor que NO coincidió, por lo que todo camino por `else` debe retornar, hacer panic, romper o continuar.

El patrón puede no coincidir (patrón de variante de enum, patrón de longitud de array, …) y no tiene cláusula `else`. Sin ella, un valor que no coincide ligaría basura silenciosamente.

Un patrón de struct anónimo necesita saber qué struct desestructura, pero el tipo del valor no resuelve a un struct concreto — normalmente por falta de anotación de tipo.

Un patrón de struct nombrado en posición de parámetro (`fn f(NombreStruct { … }: T)`) nombra un struct distinto al de la anotación de tipo del propio parámetro.

El spread final de un literal de struct (`Struct { ..origen }`) tiene un `origen` que no es struct ni record, por lo que no hay campos que esparcir.

Una asignación con destructuring de tupla (`(a, b, c) = expr`) tiene un número de destinos distinto al número de valores de `expr`.

Los operadores compuestos (`+=`, `-=`, …) no tienen significado por elemento cuando el lado izquierdo es un patrón entero, y el spread `..` no tiene sentido como destino de asignación.

Un argumento nombrado (`f(nombre: valor)`) no coincide con los parámetros declarados de la función llamada — un nombre desconocido o duplicado, un argumento posicional después de uno nombrado, un parámetro intermedio omitido, o una llamada cuya firma no se conoce localmente.

El placeholder `_` solo es válido como argumento directo en la llamada del lado derecho (RHS) de una etapa de pipe `|>`/`?>` (como máximo uno por etapa), o como la cabeza de una cadena de campo/método/índice usada como argumento de llamada (`_.campo`). Un `_` suelto, un segundo `_` en la misma etapa de pipe, o `_` como lado izquierdo de un pipe son todos rechazados.

Se identificó un enum real y declarado para este punto — como base de `EnumName::variante`, o como tipo del valor evaluado por un pattern con atajo `.variante` — pero el nombre de la variante no coincide con ninguna variante declarada. Se incluye una sugerencia "¿quisiste decir?" en el mensaje cuando existe un nombre cercano.

El atajo `.Variante` obtiene su enum del tipo que espera la posición donde aparece, y esta posición no aporta nada utilizable — ningún tipo esperado (un `let` sin anotación, un argumento de una función cuya firma no se conoce), un parámetro genérico aún sin fijar, o un tipo que no es un enum. Anota la variable o escribe la forma calificada `Enum::Variante`.

El atajo `.Variante` resolvió su enum a partir del tipo esperado por la posición, pero ese enum no tiene ninguna variante con ese nombre. Se incluye una sugerencia "¿quisiste decir?" cuando existe un nombre cercano. La forma de pattern del mismo error reporta `TE133` en lugar de este código.

El nombre forma parte del preludio siempre-en-ámbito de la VM, pero el backend native/LLVM no tiene implementación para él. Compilar igual haría que evaluara silenciosamente a `nil` y saliera con 0, así que el build falla.

Chequeo exclusivo de native/LLVM: un identificador simple no resolvió a nada. Sin preludio Lua de respaldo, se convertiría silenciosamente en `nil` en runtime — la clase "un typo se vuelve un no-op silencioso" que esto detecta en tiempo de build.

El tipado strict requiere que cada `let`/`const` tenga una anotación de tipo explícita.

El tipado strict requiere que cada parámetro de función tenga un tipo explícito.

El número de argumentos de tipo proporcionados no coincide con la cantidad de parámetros del tipo genérico.

Un bound de trait, bloque `impl` o cláusula `where` hace referencia a un trait que el compilador no encuentra.

`@(expr)` compila a un puente de custom property de CSS (`var(--…)`), que solo existe en valores de declaración — después del `:`, antes del `;`. En un selector, un nombre de propiedad o el preludio de una at-rule no hay `var()` al que compilar, y hacer splice de texto del usuario ahí es un anti-feature deliberado. Mueve la parte dinámica a un valor, o alterna clases estáticas en el markup.

Un `<style children={expr}>` lleva contenido de runtime que el compilador no puede ver — no puede izarlo ni acotarlo; acotar texto desconocido sería una mentira. Spec §6.1: el contenido dinámico debe optar por `global` explícitamente (`<style global children={…}>`), la única forma de style que sigue siendo un nodo de render.

Un valor de `@()` viaja como custom property de CSS, y solo `str`, `int` y `float` serializan a una. Un valor tipado `bool`, `View`, map, struct o función se rechaza en compilación — en el render se convertiría en basura o desaparecería. Los valores sin tipo (`Any`) quedan en silencio: este error nunca adivina.

`@()` compila a `var(--…)`, y CSS no concatena cadenas en valores comunes — `var(--w)px` es un error de sintaxis que el navegador descarta, no "número más unidad". Escribe `calc(@(x) * 1px)` o interpola la cadena completa (`@(f"{x}px")` — dentro de `@()` estás de vuelta en Zolo). `!important`, `/` y `*` en `calc()` son vecinos sin espacio legales.

`:global(…)` exime a un compound del sello de ámbito hermético. Un wrapper vacío (`:global()`) no exime nada, y uno anidado (`:global(:global(a))`) escapa de un escape — ambos solo pueden ser un error. En un cuerpo `<style global>`, `:global()` ni siquiera es sintaxis Zolo y pasa intacto.

Advertencia, nunca un fallo de build. El ámbito hermético sella cada compound con la clase del componente, así que un selector que nombra una clase/id/etiqueta que el markup del propio componente nunca produce es una regla muerta — y `:root` bajo ámbito está estructuralmente muerto. Incluye un "¿quisiste decir?" (distancia de edición ≤ 2) y el conjunto renderizado del componente. Valores dinámicos de class/id o llamadas `el`/`raw` abren el conjunto y suprimen la advertencia — nunca adivina.

Un `<style>` con ámbito pertenece al fn de componente que lo rodea — el sello de clase del fn es el ámbito de los selectores. En una sentencia de nivel superior o un método de `impl`/`trait` no hay componente, así que no hay ámbito. Añade `global` (un `<style global>` estático fuera de un componente se renderiza en su lugar) o muévelo a un fn de componente. Un cuerpo con `@()` lo reporta incluso con `global`: sus valores necesitan un elemento raíz de componente.

Cada valor de `@()` viaja como custom property de CSS en el elemento raíz del componente (el literal de elemento en posición de cola), heredándose DOM abajo. Un componente que delega toda su vista — sin raíz de elemento propia — no da a los valores dónde viajar. Haz que la cola sea un literal de elemento (un `<div>` envolvente sirve) o quita la interpolación.

Advertencia, nunca un fallo de build. Los nombres de propiedad se comprueban contra una tabla curada que viene con la toolchain (datos estáticos, sin descarga de registro); un casi-acierto vuelve con un "¿quisiste decir?" (distancia de edición ≤ 2). Los nombres que empiezan con `-` — prefijos de proveedor y custom properties `--` — nunca se comprueban, ni tampoco los descriptores de at-rules (el `src` de `@font-face`, …). Una propiedad más nueva que la tabla cuesta un subrayado, nunca un release.

Una función genérica se llamó con un argumento de tipo que no implementa un trait requerido por uno de sus bounds.

Se usa un operador sobre un parámetro de tipo genérico que no lleva el trait bound correspondiente. Sin él, el compilador no puede garantizar que la operación sea válida para todo argumento de tipo posible.

Un bound en la firma de la función nombra un trait que el compilador no conoce.

Se usa un operador sobre un valor de struct/enum concreto cuyo tipo no implementa el trait requerido. Sin él no hay método que impulse el operador y fallaría en runtime.

Las rutas calificadas de trait deben ser `core::<módulo>::<Trait>` o `std::<módulo>::<Trait>`, nombrando un `pub trait` realmente declarado allí — tanto en un bound genérico como en una cabecera de `impl`.

Un `impl Trait for Tipo` carece de uno o más métodos requeridos (los que no tienen cuerpo por defecto). Sin ellos, el despacho de método y operador fallaría en runtime.

Se llamó a un método de colección (`each`, `filter`, `len`, …) directamente sobre un wrapper `Result` u `Option`. Desenvuélvelo primero con `?>`, `?` o `.unwrap()`.

`?.` es encadenamiento null-safe, no desenvolvimiento fallible. Un `Result` u `Option` nunca es `nil`, por lo que el encadenamiento opera sobre el wrapper. Usa `expr ?> .m(...)`, `let v = expr?` o `expr!.m(...)` en su lugar.

`for x in expr` exige que `expr` produzca una secuencia. Zolo itera colecciones nativas y cualquier tipo que implemente `Iterator`/`IntoIterator`; un struct o enum que no implementa ninguno no le da nada al bucle.

Un tagged template `tag"…"` no es sintaxis especial — se reduce a una llamada normal a una función llamada `tag`, y no hay ninguna función con ese nombre en el ámbito.

`parallel { … }` ejecuta cada sentencia de nivel superior como su propia tarea concurrente, por lo que toda sentencia del bloque debe ser una expresión que pueda convertirse en una.

Una función ejecuta un efecto (`!io`, `!net`, `!fs`, ...) que no declaró en su firma.

Se ejecutó un efecto pero ningún bloque `handle` envolvente lo maneja.

Un bloque `handle` intenta manejar una operación que el efecto no declaró.

Un bloque `handle` no implementa una de las operaciones declaradas por el efecto.

El handler hace referencia a un nombre de operación que no existe en el efecto.

Una firma de función o handler hace referencia a un efecto que el compilador no encuentra.

Una llamada `perform` u operación de handler no coincide con la firma declarada del efecto.

`handle … with <handler_valor>` usa un handler-valor que cubre solo parte de las operaciones del efecto. El error aparece en el `with` y nombra las operaciones faltantes.

Una llamada `perform Efecto::op(…)` pasó un argumento cuyo tipo no coincide con el tipo del parámetro declarado de la operación.

La forma resumida de TE800: en lugar de reportar cada `perform`, reúne todos los efectos que la función de frontera realmente necesita y los reporta en la firma.

Es una advertencia, no un fallo de build. Un bloque `handle` que usa un handler-valor con anotación explícita `handler<…>` cubre un efecto que el cuerpo tratado nunca realiza.

Un parámetro genérico se usa a la vez como parámetro de tipo y como cola de variable de fila en una cláusula `with` (`{Fs | e}`). Un mismo nombre no puede significar un tipo y un conjunto de efectos extra a la vez.

Un `perform` apunta a una operación declarada `multi` (reanudable más de una vez). Las continuaciones multi-shot hoy son exclusivas de la VM.

El parámetro de tipo de un efecto genérico no resolvió en un `perform` — ni los tipos de los argumentos ni un `with Efecto<Concreto>` dieron un tipo concreto.

`h` debe ser algo cuyo tipo sea `handler<…>`. Si resuelve a otra cosa, no hay conjunto de brazos al que despachar las operaciones realizadas.

Una invariante de runtime que el compilador emitió código para verificar (por ejemplo, bounds, división por cero en const eval) fue violada.