Rust 1.36.0版本:未来特性,分配稳定和MaybeUninit

在此,我向大家介绍了大家最喜欢的编程语言Rust的新版本的出版物翻译。


引言


Rust编程语言团队很高兴地宣布一个新版本1.36.0。 Rust是一种编程语言,它使每个人都可以开发可靠且快速的软件。


如果您使用rustup安装了rustup版本的Rust,那么获取当前版本将不会很困难:


 $ rustup update stable 

如果您仍然没有rustup ,则可以从我们网站上的相应页面获取它 。 可以在GitHub上获得此版本的详细评论


稳定版包含哪些内容?


此版本进行了许多更改,包括稳定期待已久的Future特性,alloc allocMaybeUninit<T>结构, NLL Rust 2015HashMap<K, V>的新实现以及对Cargo中--offline标志的支持。


下面介绍了最重要的更改,但是您也可以查看详细的创新清单,以提高认知度。


未来稳定


Rust 1.36.0 稳定了期待已久的 Future


我们希望这项创新将使流行的板条箱,图书馆和整个生态系统为async / .await做准备,该.await计划在不久的将来得到稳定。


配电架稳定


在1.36.0版之前,标准库由stdcoreproc_macrocore具有基本功能(例如IteratorCopy ),并且可以在带有#![no_std]环境中使用,因为它没有施加任何要求。 同时, std板条箱提供了Box<T>类的类型,以及操作系统(全局分配器)的功能。


从Rust 1.36.0开始,依赖于全局分配器的std板条箱组件(例如Vec<T> )现在可以在alloc alloc 。 同时, std正在重新导出这些组件。


尽管使用#![no_std]箱的#![no_std]仍然需要nightly频道,但是c #![no_std]可以在稳定的Rust中使用#![no_std] alloc


我们还注意到,所有依赖项中的“常规”程序(不带#![no_std] )都可以包含上述带#![no_std]的库。 我们希望这将有助于开发与#![no_std]兼容的生态系统。


如果您是需要分配原语才能运行的库的开发人员,建议您在lib.rs文件的开头使用以下语法将您的库标记为与#![no_std]兼容:


 #![no_std] extern crate alloc; use alloc::vec::Vec; 

MaybeUninit place mem ::未初始化


在Rust的mem::uninitialized版本中, mem::uninitialized函数使您可以取消初始化检查,因为它认为您已经初始化了类型T而无需执行任何操作。 此功能的用途之一是数组的“惰性”分配。


但是,假设所有值均已正确初始化,那么mem::uninitalized是一个过于危险的操作,因此无法与Rust编译器正确使用。


例如,调用mem::uninitialized::<bool>()将立即导致未定义的行为 ,因为从Rust的角度来看,未初始化的位是零( false )或unity( true ),并且上述模式中只有两个适用于bool类型。


为了解决这种情况,在Rust 1.36.0中稳定MaybeUninit<T>类型。 Rust编译器不再假定MaybeUninit<T>MaybeUninit<T>的初始化类型T 这样,您可以更安全地执行渐进式初始化,并在确定maybe_t: MaybeUninit<T>包含初始化的类型T时最终使用.assume_init() T


由于MaybeUninit<T>是从Rust 1.38开始的更安全的选择,因此mem::uninitialized函数将被标记为过时的。


要了解有关未初始化内存mem::uninitializedMaybeUninit<T> ,请阅读Alexis Bessessner文章 。 标准库还包含有关MaybeUninit<T>足够文档。


NLL for Rust 2015


在Rust 1.31.0的公告中,我们向您介绍了NLL(非词汇生命周期),这是一种语言创新,使链接控制器(借用检查程序)更智能,更友好。 例如,现在您可以这样编写:


 fn main() { let mut x = 5; let y = &x; let z = &mut x; //     1.31.0 } 

在1.31.0,NLL仅在Rust 2018时才稳定,并且假定我们将来会将其转移到Rust 2015。 这是在Rust 1.36.0中完成的,NLL在Rust 2015中可用。


两种版本都支持NLL,因此我们即将删除旧的链接控制器。 但是,不幸的是,旧的链接控制器接受了应该接受的错误代码


因此,NLL现在处于“迁移”阶段,在该阶段中,如果NLL链接控制器不批准会批准旧的基于AST的链接控制器的代码,我们将发出警告而不是错误。 我们建议您查看受影响的公共包装箱清单


要了解有关NLL,MIR,如何解决相关完整性问题以及如何使用出现的编译器警告进行操作的更多信息,请阅读Felix Klok的文章


新的HashMap实施


在Rust 1.36.0中,以前的HashMap<K, V> hashbrown基于SwissTable设计的哈希棕色hashbrown代替 。 接口保持不变,但是当前的实现平均速度更快,并且占用的内存更少。 但是,请注意,标准实现仍使用SipHash 1-3算法。


-货运中的离线支持


在大多数构建过程中,Cargo不会使用您的网络。 但是,在某些时候,例如,当添加新的依赖项时,Cargo仍将尝试访问网络。 有时,这种行为是不可接受的(在隔离的系统中或在飞机上)。


Rust 1.36.0稳定了新标记--offline 。 该标志将覆盖依赖关系解析算法,而不是使用本地缓存的依赖关系。


如果在没有断开网络连接的情况下无法使用请求的板条箱,则货运将错误退出。 要在离开网络之前预先填充本地缓存,请使用cargo fetch命令,该命令将加载特定项目的所有必需依赖项。


要了解有关--offline--offline更多信息,请阅读Nick Cameron的文章此处对货运的其他更改进行了详细说明。


图书馆变更



其他变化


1.36.0版中的详细更改说明可用于Rust标准库 CargoClippy


成员1.36.0


很多人一起创建了Rust 1.36.0。 没有你们大家,我们不可能做到这一点, 谢谢


来自翻译


如果您对Rust语言有任何疑问,他们将可以在俄语电报聊天对新手进行的类似聊天中为您提供帮助。


Source: https://habr.com/ru/post/zh-CN458848/


All Articles