Lanzamiento del lenguaje de programación Rust 1.51

Se ha publicado el lanzamiento del lenguaje de programación del sistema Rust 1.51, fundado por el proyecto Mozilla, pero ahora desarrollado bajo los auspicios de la organización independiente sin fines de lucro Rust Foundation. El lenguaje se centra en la seguridad de la memoria, proporciona administración automática de la memoria y proporciona los medios para lograr un alto paralelismo de tareas sin utilizar un recolector de basura o tiempo de ejecución (el tiempo de ejecución se reduce a la inicialización y el mantenimiento básicos de la biblioteca estándar).

La gestión automática de la memoria de Rust elimina errores al manipular punteros y protege contra problemas derivados de la manipulación de la memoria de bajo nivel, como el acceso a una región de memoria después de haber sido liberada, desreferencias de punteros nulos, desbordamientos de búfer, etc. Para distribuir bibliotecas, garantizar el ensamblaje y gestionar dependencias, el proyecto está desarrollando el administrador de paquetes Cargo. El repositorio crates.io es compatible con bibliotecas de alojamiento.

Principales novedades:

  • La funcionalidad asociada con el uso de genéricos constantes ha recibido el estatus de producto mínimo viable (MVP), dando luz verde para su uso generalizado. Los genéricos constantes permiten generalizar los tipos a valores constantes, es decir. utilice argumentos genéricos limitados a un rango de valores constantes, no tipos o vidas útiles. Esta característica le permite utilizar abstracción y tipos con parámetros enteros al crear rasgos para matrices de cualquier tamaño sin tener que crear un tipo separado para cada rango de valores válidos para garantizar que no haya ocurrencias fuera de límites.

    A partir de la versión actual, para matrices con tipo “[T; N]" (tipo T y tamaño N) proporciona la capacidad de abstraer el tipo y el tamaño utilizando valores con cualquier tipo entero, booleano y de carácter (los tipos struct y enum aún no son compatibles). Los genéricos constantes simplifican enormemente el desarrollo de bibliotecas; por ejemplo, para utilizar una matriz que no esté vinculada a un tipo y tamaño específicos, puede especificar: struct Array { // ^^^^^^^^^^^^^^^^^^^ definición de una lista genérica constante: [T; LONGITUD] // ^^^^^^ su uso }

    Cuando realmente se usa con esta definición de "Array » el compilador generará una versión monomórfica de Array: struct Array { lista: [u8; 32] }

  • Se ha estabilizado la API std::array::IntoIter, basada en genéricos constantes, con la que puedes crear iteradores por valor para cualquier array: fn main() { let array = [1, 2, 3, 4, 5] ; // Anteriormente, para iterar sobre un valor, tenías que llamar al método .iter() para el elemento en array.iter().copied() { println!("{}", item); } // Ahora puede especificar el elemento en std::array::IntoIter::new(array) { println!("{}", item); } }
  • El administrador de paquetes de carga ahora admite un nuevo campo de resolución en Cargo.toml, que se puede utilizar para habilitar la segunda versión de la función de resolución. La nueva versión del definidor evita combinar características de dependencia enumeradas en la sección "[características]" donde no es apropiado, por ejemplo, cuando se incluye una dependencia que solicita alguna característica estándar en macros y scripts de compilación, pero cuando se usa una característica no estándar. en el archivo ejecutable resultante.

    Hasta ahora, se combinaban las capacidades de un paquete mencionado varias veces en el gráfico de dependencia. Por ejemplo, si un proyecto incluye una dependencia foo que define las capacidades A y B, y este paquete se usa en los otros paquetes bar y baz, aunque bar depende de foo con la característica A y baz depende de foo con la característica B, entonces el resultado será cargo combinará estas características y compilará foo con las características A y B incluidas. Este método puede dar como resultado que una característica esté habilitada debido a que alguna dependencia es incompatible con el sistema de destino para el cual se realizó la compilación resultante. Por ejemplo, cuando desea utilizar una versión de foo con "#![no_std]" en un ejecutable creado con "#![no_std]", y al mismo tiempo utilizar foo con "std" durante la compilación. rs. Al especificar resolver="2" en Cargo.toml, el administrador de paquetes ahora intentará manejar correctamente este conflicto, separando las dependencias de desarrollo, host y destino.

  • Cargo implementa la opción split-debuginfo, configurada en la sección “[profile]”, y el indicador correspondiente “-Csplit-debuginfo=unpacked” en Rustc, ofreciendo la implementación de un nuevo método para guardar información de depuración, que elimina la necesidad de Llame a la utilidad dsymutil y acelera significativamente el proceso de compilación con información de depuración en macOS.
  • Makos estabilizados "ptr::addr_of!" y “ptr::addr_of_mut!”, que le permiten crear punteros sin formato para campos no alineados. utilizar std::ptr; #[repr(empaquetado)] struct Empaquetado { f1: u8, f2: u16, } let empaquetado = Empaquetado { f1: 1, f2: 2 }; // &packed.f2 creará un puntero no alineado que conducirá a un comportamiento indefinido let raw_f2 = ptr::addr_of!(packed.f2); afirmar_eq! (inseguro { raw_f2.read_unaligned() }, 2);
  • Una nueva parte de la API se ha transferido a la categoría estable, incluidos los siguientes métodos que se han estabilizado:
    • Arco::decrement_strong_count
    • Arco::increment_strong_count
    • Una vez::call_once_force
    • Vistazo::next_if_eq
    • Vistazo::next_if
    • Buscar::stream_position
    • matriz::IntoIter
    • pánico::panic_any
    • ptr::addr_of!
    • ptr::addr_of_mut!
    • rebanada::rellenar_con
    • rebanada::split_inclusive_mut
    • rebanada::split_inclusive
    • rebanada::strip_prefix
    • rebanada::strip_suffix
    • str::split_inclusive
    • sincronización::OnceState
    • tarea::despertar
  • Se ha implementado el tercer nivel de soporte para las plataformas i386-unknown-linux-gnu, i486-unknown-linux-gnu, aarch64_be-unknown-linux-gnu, aarch64-unknown-linux-gnu_ilp32 y aarch64_be-unknown-linux-gnu_ilp32. . El tercer nivel implica soporte básico, pero sin pruebas automatizadas, publicación de compilaciones oficiales ni verificación de si el código se puede compilar.

Fuente: opennet.ru

Añadir un comentario