2510rs,rust,1.89
原文
1.89.0稳定版中有什么
显式推导常模板参数
Rust现在支持_作为常模板参数的参数,从周围的环境中推导值:
pub fn all_false<const LEN: usize>() -> [bool; LEN] {[false; _]
}
与允许_作为类型时的规则类似,在签名中禁止_作为常模板的参数:
//这是禁止的
pub const fn all_false<const LEN: usize>() -> [bool; _] {[false; LEN]
}
//这也是禁止的.
pub const ALL_FALSE: [bool; _] = all_false::<10>();
生命期语法不匹配的检查
函数签名的生命期省略是Rust语言的一个符合人体工程学的方面,但对新手和伪专家,它也可能是一个绊脚石.
这里
当在语法上甚至不明显有生命期的类型中,推导生命期时尤其如此:
//返回的`"std::slice::Iter"`类型有`生命期`,但没有视觉指示.`生命期`省略推导`返回类型`的`生命期`与"分数"的`生命期`相同.
fn items(scores: &[u8]) -> std::slice::Iter<u8> {scores.iter()
}
现在,默认,此类代码将生成警告(略).
早在2018年,作为rust_2018_idioms检查组的一部分,就首次试改善它,但对elided_lifetimes_in_paths检查的强烈反馈表明,它太钝了,因为它警告了对理解函数不重要的生命期:
use std::fmt;
struct Greeting;
impl fmt::Display for Greeting {fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {//-----^^^^^^^^^ 期望`生命期`参数.知道"格式化程序"有`生命期`对开发者没用"howdy".fmt(f)}
}
然后发现,当两者都发生时,想要清除的混乱就会:
1,生命期省略推导规则将输入生命期连接到输出``生命期
2,在句法上是否存在生命期并不明显
有两段Rust语法表明有生命期:&和',而'被细分为推导的生命期即'_,并叫做'a.当类型使用命名的生命期时,省略生命期不会为此类型推导生命期.
使用这些准则,可构建三组:
不言而喻,有生命期 | 允许省略生命期来推导生命期 | 示例. |
|---|---|---|
| 否 | 是 | ContainsLifetime |
| 是 | 是 | &T,&'_T,ContainsLifetime<'_> |
| 是 | 否 | &'a T,ContainsLifetime<'a> |
mismatched_lifetime_syntaxes检查函数的输入和输出是否属于同一组.
对上面的初始激励示例,&[u8]属于第二组,而std::slice::Iter<u8>属于第一组.
第一组的生命期是隐藏的.
1,因为输入和输出生命期属于不同组,因此检查将警告此函数,从而减少对值何时有视觉上不明显的有意义的生命期的混淆.
2,mismatched_lifetime_syntaxes检查替换了,专门针对命名生命期执行类似的操作的elided_named_lifetimes检查.
3,未来elided_lifetimes_in_paths检查的工作要按更集中的子检查分割它,并着眼于最终警告其中的子集.
更多x86目标功能
target_feature属性现在支持x86上的sha512,sm3,sm4,kl和widekl目标功能.此外,在x86上,还支持许多avx512内部函数和目标功能:
#[target_feature(enable = "avx512bw")]
pub fn cool_simd_code(/*..*/) -> /*...*/ {/*...*/
}
交叉编译的文档测试
现在,在运行cargo test --doc --target other_target时将测试doctest,会导致一定程度的破坏,因为现在正在测试的doctests可能会失败.
可用ignore-<target>注解doctest来禁止失败的测试,这里:
/// ```ignore-x86_64
/// panic!("something")
/// ```
pub fn my_function() { }
外部"C"函数中的i128和u128
i128和u128不再触发improper_ctypes_definitions检查,即在外部"C"函数中,这类可能会在没有警告就存在时.这有一些警告:
1,当Rust类型可用时,Rust类型与C中的(正)__int128的ABI和布局兼容.
2,在__int128不可用的平台上,i128和u128不一定与任何C类型对齐.
3,i128不一定与任何平台上的_BitInt(128)兼容,因为与x86-64上的情况一样,_BitInt(128)和__int128可能没有相同ABI.
这里
稳定的API
NonZero<char>
此处未枚举的x86的许多内部函数.
AVX512 intrinsics
SHA512, SM3 and SM4 intrinsics
File::lock
File::lock_shared
File::try_lock
File::try_lock_shared
File::unlock
NonNull::from_ref
NonNull::from_mut
NonNull::without_provenance
NonNull::with_exposed_provenance
NonNull::expose_provenance
OsString::leak
PathBuf::leak
Result::flatten
std::os::linux::net::TcpStreamExt::quickack
std::os::linux::net::TcpStreamExt::set_quickack
这些以前稳定的API,现在在常环境中是稳定的:
<[T; N]>::as_mut_slice
<[u8]>::eq_ignore_ascii_case
str::eq_ignore_ascii_case