Yeda AI Tips · #132

English

Todo bloque unsafe necesita un comentario de seguridad

unsafe sin un comentario es solo un "confía en mí" en Rust. El bloque compila, las pruebas pasan, y lo único que lo mantiene correcto — el invariante que verificaste en tu cabeza — no está escrito en ninguna parte. Un revisor no puede confirmarlo. Un agente de IA que edite el archivo seis meses después no puede confirmarlo. La próxima refactorización rompe la suposición en silencio y obtienes comportamiento indefinido sin ninguna advertencia.

Por qué el comentario carga con el peso

Un bloque unsafe no desactiva la seguridad. Traslada la carga de la prueba del compilador hacia ti. Dentro de él puedes desreferenciar punteros crudos, llamar a otras funciones unsafe o acceder a un campo de una union — operaciones donde el compilador deja de verificar el contrato y confía en que tú ya lo hiciste. La regla que hace correcto al bloque (este índice está dentro de los límites, este puntero es no nulo y está alineado, este tiempo de vida sobrevive al préstamo) existe solo en tu cabeza hasta que la escribes.

Un comentario // SAFETY: la escribe. Convierte un "confía en mí" no verificable en una afirmación declarada que una persona o una herramienta puede revisar línea por línea.

La regla: sin comentario, no hay merge

Coloca un comentario // SAFETY: justo encima de cada bloque unsafe, nombrando el invariante del que depende el bloque y por qué se cumple aquí.

// SAFETY: `idx` is checked against `self.len` on the line above,
// so it is always in bounds for `get_unchecked`.
let elem = unsafe { self.data.get_unchecked(idx) };
SituaciónQué debe declarar el comentario
Desreferencia de puntero crudoEl puntero es no nulo, está alineado y apunta a un valor vivo e inicializado
get_unchecked / indexaciónEl índice está demostrablemente dentro de los límites en este punto
from_utf8_uncheckedLos bytes ya fueron validados como UTF-8
Llamada FFISe cumple el contrato foráneo (propiedad, nulabilidad, reglas de hilos)
unsafe impl Send/SyncPor qué el acceso concurrente es realmente correcto para este tipo

La imagen espejo también importa: una sección # Safety en el comentario de documentación de toda función pública unsafe fn le dice a quien la llama qué debe garantizar antes de llamarla. El comentario SAFETY: salda esa obligación en el sitio de la llamada.

Aplícalo en CI, no en la revisión de código

No tienes que vigilar esto a mano. Clippy trae dos lints para ello:

Convierte el primero en una barrera dura:

#![warn(clippy::undocumented_unsafe_blocks)]
// or, to block the merge outright:
#![deny(clippy::undocumented_unsafe_blocks)]

Combínalo con #![deny(unsafe_op_in_unsafe_fn)] — la política de la biblioteca estándar — para que el cuerpo de una unsafe fn no obtenga un pase libre: cada operación unsafe sigue necesitando su propio bloque unsafe, y por lo tanto su propio comentario. Así es exactamente como la biblioteca estándar de Rust aplica su política de comentarios de seguridad sobre decenas de miles de operaciones unsafe.

Por qué rinde con la IA en el circuito

Los revisores dejan de adivinar si un bloque es correcto y empiezan a verificarlo contra una regla escrita. También lo hacen los agentes de IA: dado el invariante declarado, un agente puede verificar que un cambio lo preserva, o rechazar la edición y señalar el riesgo — en lugar de borrar en silencio la verificación de límites que el comentario protegía discretamente. El comentario es el contrato legible por máquina que mantiene honestos tanto a las personas como a los modelos.

Recursos

¿Envías Rust que tocan agentes de IA? Yeda AI audita y fortalece bases de código para que tanto personas como modelos puedan razonar sobre ellas.

Habla con nosotros · Lee el blog