Clippy lints / Pedantic
Clippy lint · Pedantic · checked with Clippy 0.1.99
clippy::linkedlist: Checks for usage of any LinkedList, suggesting to use a Vec or a VecDeque (formerly called RingBuf)
What it meansChecks for usage of any LinkedList, suggesting to use a Vec or a VecDeque (formerly called RingBuf). It is in the pedantic group and off by default.
Does it matter?
Gankra says: The TL;DR of LinkedList is that it’s built on a massive amount of pointers and indirection. It wastes memory, it has terrible cache locality, and is all-around slow. RingBuf, while “only” amortized for push/pop, should be faster in the general case for almost every possible workload, and isn’t even amortized at all if you can predict the capacity you need. LinkedLists are only really good if you’re doing a lot of merging or splitting of lists. This is because they can just mangle some pointers instead of actually copying the data. Even if you’re doing a lot of insertion in the middle of the list, RingBuf can still be better because of how expensive it is to seek to the middle of a LinkedList.
Stricter lints with some false positives. Off by default; opt in with clippy::pedantic.
How to fix it
Clippy does not fix this one automatically. Change the code by hand:
Flagged
let x: LinkedList<usize> = LinkedList::new();
Turn it off, or on
It is off by default. To use it, set it to warn or deny:
Whole crate (Cargo.toml)
[lints.clippy]
linkedlist = "warn"In code
#![warn(clippy::linkedlist)]One run
cargo clippy -- -W clippy::linkedlistThe [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.
Settings in clippy.toml
avoid-breaking-exported-api: Suppress lints whenever the suggested change would cause breakage for other crates.
Clippy's own documentation
What it does
Checks for usage of any LinkedList, suggesting to use a
Vec or a VecDeque (formerly called RingBuf).
Why is this bad?
Gankra says:
The TL;DR of
LinkedListis that it’s built on a massive amount of pointers and indirection. It wastes memory, it has terrible cache locality, and is all-around slow.RingBuf, while “only” amortized for push/pop, should be faster in the general case for almost every possible workload, and isn’t even amortized at all if you can predict the capacity you need.
LinkedLists are only really good if you’re doing a lot of merging or splitting of lists. This is because they can just mangle some pointers instead of actually copying the data. Even if you’re doing a lot of insertion in the middle of the list,RingBufcan still be better because of how expensive it is to seek to the middle of aLinkedList.
Known problems
False positives - the instances where using a
LinkedList makes sense are few and far between, but they can still happen.
Example
let x: LinkedList<usize> = LinkedList::new();
Configuration
-
avoid-breaking-exported-api: Suppress lints whenever the suggested change would cause breakage for other crates.(default:
true)
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- too_many_linesChecks for functions with a large amount of lines
- missing_errors_docChecks the doc comments of publicly visible functions that return a Result type and warns if there is no # Errors section
- must_use_candidateChecks for public functions that have no #[must_use] attribute, but return something not already marked must-use, have no mutable arg and mutate no statics
- large_futureslarge future with a size of 16385 bytes
- large_stack_arraysallocating a local array larger than 16384 bytes
- large_types_passed_by_valuethis argument (2048 byte) is passed by value, but might be more efficient if passed by reference (limit: 256 byte)
- macro_use_importsChecks for #[macro_use] use
- manual_assertonly a `panic!` in `if`-then statement
- manual_assert_eqused `assert!` with an equality comparison
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::too_many_linesChecks for functions with a large amount of linesRead it next →Did this answer your question?