Clippy lints / Correctness
Clippy lint · Correctness · checked with Clippy 0.1.99
clippy::unit_return_expecting_ord: this closure returns the unit type which also implements Ord
What it meansChecks for functions that expect closures of type Fn(…) -> Ord where the implemented closure returns the unit type. The lint also suggests to remove the semi-colon at the end of the statement if present. It is in the correctness group and denied by default (the build fails).
What you see
error: this closure returns the unit type which also implements Ord --> main.rs:4:19 | 4 | twins.sort_by_key(|x| { x.1; }); | ^^^ | help: probably caused by this trailing semicolon --> main.rs:4:28 | 4 | twins.sort_by_key(|x| { x.1; }); | ^ = help: for further information visit https://rust-lang.github.io/rust-clippy/stable/index.html#unit_return_expecting_ord = note: `#[deny(clippy::unit_return_expecting_ord)]` on by default
Real output of Clippy 0.1.99 (Rust 1.99) on the example below. Names and line numbers in yours will differ.
Does it matter?
Likely, returning the unit type is unintentional, and could simply be caused by an extra semi-colon. Since () implements Ord it doesn’t cause a compilation error. This is the same reasoning behind the unit_cmp lint.
Code that is almost certainly wrong. Denied by default: the build fails until you fix it or allow it.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
let mut twins = vec![(1, 1), (2, 2)];
twins.sort_by_key(|x| { x.1; });
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::unit_return_expecting_ord)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
unit_return_expecting_ord = "allow"One run
cargo clippy -- -A clippy::unit-return-expecting-ordThe [lints] table needs Rust 1.74 or newer. In a workspace, put it under [workspace.lints.clippy] and add [lints] workspace = true to each member.
Clippy's own documentation
What it does
Checks for functions that expect closures of type Fn(…) -> Ord where the implemented closure returns the unit type. The lint also suggests to remove the semi-colon at the end of the statement if present.
Why is this bad?
Likely, returning the unit type is unintentional, and could simply be caused by an extra semi-colon. Since () implements Ord it doesn’t cause a compilation error. This is the same reasoning behind the unit_cmp lint.
Known problems
If returning unit is intentional, then there is no way of specifying this without triggering needless_return lint
Example
let mut twins = vec![(1, 1), (2, 2)];
twins.sort_by_key(|x| { x.1; });
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- uninit_vecChecks for set_len() call that creates Vec with uninitialized elements. This is commonly caused by calling set_len() right after allocating or reserving a buffer with new(), default(), with_capacity(), or reserve()
- unit_cmpChecks for comparisons to unit
- unit_hashDetects ().hash(_)
- unsound_collection_transmutetransmute from `std::vec::Vec<u16>` to `std::vec::Vec<u32>` with mismatched layout is unsound
- unused_io_amountwritten amount is not handled
- useless_attributeChecks for extern crate and use items annotated with lint attributes. This lint permits lint attributes for lints emitted on the items themself. For use items these lints are: ambiguous_glob_reexports dead_code deprecated hidden_glob_reexports unreachable_pub unused unused_braces unused_import_braces clippy::disallowed_types clippy::enum_glob_use clippy::macro_use_imports clippy::module_name_repetitions clippy::redundant_pub_crate clippy::single_component_path_imports clippy::unsafe_removed_from_name clippy::wildcard_imports For extern crate items these lints are: unused_imports on items with #[macro_use]
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::uninit_vecChecks for set_len() call that creates Vec with uninitialized elements. This is commonly caused by calling set_len() right after allocating or reserving a buffer with new(), default(), with_capacity(), or reserve()Read it next →Did this answer your question?