bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Changed unwrap_or to unwrap_or_else in some places.

Browse source 
The discussion seems to have resolved that this lint is a bit "noisy" in
that applying it in all places would result in a reduction in
readability.

A few of the trivial functions (like `Path::new`) are fine to leave
outside of closures.

The general rule seems to be that anything that is obviously an
allocation (`Box`, `Vec`, `vec![]`) should be in a closure, even if it
is a 0-sized allocation.
This commit is contained in:
Nicholas-Baron 2020-11-06 13:24:55 -08:00
parent 38030ffb4e
commit 261ca04c92
14 changed files with 31 additions and 30 deletions
Download patch file Download diff file Expand all files Collapse all files

14
compiler/rustc_codegen_llvm/src/intrinsic.rs
View file

@ -979,12 +979,14 @@ fn generic_simd_intrinsic(
// Integer vector <i{in_bitwidth} x in_len>:
let (i_xn, in_elem_bitwidth) = match in_elem.kind() {
ty::Int(i) => {
(args[0].immediate(), i.bit_width().unwrap_or(bx.data_layout().pointer_size.bits()))
}
ty::Uint(i) => {
(args[0].immediate(), i.bit_width().unwrap_or(bx.data_layout().pointer_size.bits()))
}
ty::Int(i) => (
args[0].immediate(),
i.bit_width().unwrap_or_else(|| bx.data_layout().pointer_size.bits()),
),
ty::Uint(i) => (
args[0].immediate(),
i.bit_width().unwrap_or_else(|| bx.data_layout().pointer_size.bits()),
),
_ => return_error!(
"vector argument `{}`'s element type `{}`, expected integer element type",
in_ty,