Clippy lints / Style
Clippy lint · Style · checked with Clippy 0.1.99
clippy::writeln_empty_string: This lint warns when you use writeln!(buf, "") to print a newline
What it meansThis lint warns when you use writeln!(buf, "") to print a newline. It is in the style group and warns by default.
Does it matter?
You should use writeln!(buf), which is simpler.
Code that works but is not idiomatic Rust. Warns by default.
How to fix it
Clippy can fix this one for you: run cargo clippy --fix (add --allow-dirty if you have uncommitted changes). Review the diff before you commit.
Flagged
writeln!(buf, "");
Write this instead
writeln!(buf);
Turn it off, or on
Allow it where it does not fit your code, as narrowly as you can:
On one item
#[allow(clippy::writeln_empty_string)]
fn my_function() { /* ... */ }Whole crate (Cargo.toml)
[lints.clippy]
writeln_empty_string = "allow"One run
cargo clippy -- -A clippy::writeln-empty-stringThe [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
This lint warns when you use writeln!(buf, "") to
print a newline.
Why is this bad?
You should use writeln!(buf), which is simpler.
Example
writeln!(buf, "");
Use instead:
writeln!(buf);
From the Clippy lint list (0.1.99), part of the Rust project, MIT or Apache-2.0. Official entry.
Related lints
- needless_returnunneeded `return` statement
- new_without_defaultChecks for public types with a pub fn new() -> Self method and no implementation of Default
- len_zeroChecks for getting the length of something via .len() just to compare to zero, and suggests using .is_empty() where applicable
- while_let_on_iteratorChecks for while let expressions on iterators
- write_literalThis lint warns about the use of literals as write!/writeln! args
- write_with_newlineThis lint warns when you use write!() with a format string that ends in a newline
- wrong_self_conventionChecks for methods with certain name prefixes or suffixes, and which do not adhere to standard conventions regarding how self is taken. The actual rules are: PrefixPostfixself takenself type as_none&self or &mut selfany from_nonenoneany into_noneselfany is_none&mut self or &self or noneany to__mut&mut selfany to_not _mutselfCopy to_not _mut&selfnot Copy Note: Clippy doesn’t trigger methods with to_ prefix in: Traits definition. Clippy can not tell if a type that implements a trait is Copy or not. Traits implementation, when &self is taken. The method signature is controlled by the trait and often &self is required for all types that implement the trait (see e.g
- zero_ptr`0 as *const _` detected
All 847 Clippy lints · Rust compiler errors · Cargo.toml checker
Up next
Related lintclippy::needless_returnunneeded `return` statementRead it next →Did this answer your question?