Hola Habr! Les presento la traducción del artículo "The Rust Release Team" Announcing Rust 1.34.0 " .
El equipo de desarrollo de Rust se complace en anunciar el lanzamiento de una nueva versión de Rust, 1.34.0. Rust es un lenguaje de programación que permite a todos crear software confiable y eficiente.
Si tiene una versión anterior de Rust instalada con Rustup, entonces para actualizar Rust a la versión 1.34.0 solo necesita hacer:
$ rustup update stable
Si aún no ha instalado Rustup, puede instalarlo desde la página correspondiente de nuestro sitio web.
Lo que se incluye en la versión estable 1.34.0
La mejora principal de esta versión es el soporte para registros de carga alternativos. ¿La versión también incluye soporte ? en pruebas de documentación, algunas mejoras en #[attribute(...)] y estabilización TryFrom . Siga leyendo sobre cosas clave o vea las notas detalladas de la versión para obtener más información.
Registros alternativos de cargo
Antes de la versión 1.0, Rust tenía un registro público, crates.io . Las personas publicaron cajas utilizando cargo publish y conectaron fácilmente estas cajas en la sección [dependencies] de Cargo.toml .
Sin embargo, no todos quieren publicar sus cajas en crates.io. Las personas que respaldan proyectos de código cerrado no podían usar crates.io, y en su lugar tenían que especificar git o path en las dependencias. No hay nada como esto para proyectos pequeños, pero si su organización tiene muchas cajas de código cerrado, pierde los beneficios del soporte de versiones, que está disponible en crates.io.
A partir de esta versión, Cargo puede admitir registros alternativos. Estos registros coexisten con crates.io, por lo que puede escribir programas que dependen de crates.io y su registro. Sin embargo, los subracks crates.io no pueden depender de un registro externo.
Para usar registros alternativos, debe agregar las siguientes líneas a .cargo/config . Este archivo puede estar en su directorio de inicio ( ~/.cargo/config ) o en el directorio del paquete.
[registries] my-registry = { index = "https://my-intranet:8080/git/index" }
Agregar dependencia de un registro alternativo es fácil. Cuando especifique la dependencia en Cargo.toml , use la clave de registry para que Cargo sepa que desea recibir la caja del registro alternativo:
[dependencies] other-crate = { version = "1.0", registry = "my-registry" }
Como autor de la caja, si desea publicar su caja en un registro alternativo, lo primero que debe hacer es guardar el token de autenticación en ~/.cargo/credentials utilizando el comando de cargo login :
cargo login --registry=my-registry
A continuación, puede usar el indicador --registry para especificar el registro en el que se publicará el rack:
cargo publish --registry=my-registry
Sobre cómo puede ejecutar su propio registro, puede encontrarlo en la documentación .
? en pruebas de documentación
¿Estaba RFC 1937 proponiendo agregar soporte de operador ? en fn main() , #[test] funciones y pruebas de documentación, lo que les permite devolver la Option<T> o el Result<T, E> donde la opción con un error da como resultado un código de terminación distinto de cero en el caso de fn main() o una prueba descartada en el caso de las pruebas .
El soporte en fn main() y #[test] ha implementado durante mucho tiempo . Sin embargo, el soporte en las pruebas de documentación se limitó a las pruebas en las que fn main() explícitamente presente.
? agregó soporte completo en esta versión ? en pruebas de documentación. Ahora puede escribir en sus pruebas de documentación esto:
En la parte inferior de la prueba de documentación, aún debe indicar el tipo de error que se utilizará.
Soporte para flujo de token personalizado en atributos de usuario
Las macros de procedimiento en Rust pueden definir los atributos de usuario que usan. Hasta ahora, estos atributos se han limitado a árboles de ruta y literales de acuerdo con la siguiente sintaxis:
#[foo(bar)] #[foo = "bar"] #[foo = 0] #[foo(bar = true)] #[foo(bar, baz(quux, foo = "bar"))]
A diferencia de las macros de procedimiento, estos atributos auxiliares no pueden aceptar una secuencia arbitraria de tokens en el delimitador, por lo que no puede escribir #[range(0..10)] o #[bound(T: MyTrait)] . En cambio, los bastidores de macros de procedimiento usaban cadenas para una sintaxis como esta, por ejemplo #[range("0..10")] .
Con esta versión, los atributos personalizados #[attr($tokens)] permiten el uso de tokens arbitrarios en $tokens , uniéndolos de acuerdo con las macros. Si usted es el autor de una macro caja de procedimientos, verifique si las cadenas se usan en la sintaxis de sus atributos de usuario y si se pueden reemplazar con una secuencia de tokens.
TryFrom y TryInto
Los TryInto TryFrom y TryInto se han estabilizado para admitir errores de conversión de tipo.
Por ejemplo, from_be_bytes y los métodos relacionados de tipos enteros reciben una matriz, pero los datos a menudo se leen a través de sectores. La conversión manual entre cortes y matrices es tediosa. Con nuevos rasgos, esto se puede hacer en la misma línea que .try_into() .
let num = u32::from_be_bytes(slice.try_into()?);
Para las conversiones que no pueden fallar, como u8 a u32 , se u32 el tipo Infallible . Debido a esto, TryFrom implementa automáticamente para todo lo que implementa el rasgo From . ¡En el futuro, esperamos hacer de Infallible alias para el ! (nunca)
fn before_exec en desuso en favor de unsafe fn pre_exec
En sistemas tipo Unix, la función CommandExt::before_exec le permitía programar un cierre antes de que exec llamara a exec .
Este cierre se realizó en el contexto del proceso secundario después de la bifurcación. Esto significa que los recursos, como los descriptores de archivos y las áreas de memoria, podrían duplicarse. En otras palabras, podría obtener una copia de un valor de tipo que no sea Copy en diferentes procesos, mientras que el original permanecería en el padre. Esto podría conducir a un comportamiento indefinido y romper bibliotecas que sugieren la ausencia de duplicación .
Por lo tanto, la función before_exec debe marcarse como unsafe . En esta versión, marcamos fn before_exec en desuso a favor de unsafe fn pre_exec . Al llamar a CommandExt::pre_exec debe asegurarse de que el cierre no viole los invariantes de la biblioteca creando duplicados no válidos. Si proporciona una biblioteca que se encuentra en una situación similar before_exec , piense en la obsolescencia y proporcione una alternativa con unsafe .
Estabilización de la biblioteca
En 1.34.0, el conjunto de tipos enteros atómicos estables con signo y sin signo se expandió, comenzando con 8 bits ( AtomicU8 ) y terminando con 64 bits.
NonZeroU8 enteros sin signo distintos de NonZeroU8 como NonZeroU8 se estabilizaron previamente . Gracias a esto, la Option<NonZeroU8> tiene el mismo tamaño que u8 . Las versiones firmadas como NonZeroI8 estabilizan en esta versión.
Las funciones iter::from_fn e iter::successors estabilizadas. El primero le permite crear un iterador desde FnMut() -> Option<T> . Para recuperar elementos de un vector de forma iterativa, ahora puede escribir from_fn(|| vec.pop()) . Mientras tanto, la segunda función crea un nuevo iterador, donde cada elemento siguiente se calcula en función del anterior.
Además, las siguientes API se han estabilizado:
Consulte las notas detalladas de la versión para obtener más detalles.