-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
In a loop, in some cases, rustc seems to not understand that a boolean expression was used for sideeffects, and warns about unused logical operation. The following code can quickly replicate the problem.
use std::sync::{atomic::{AtomicBool, Ordering}, Arc};
fn main() {
let running = Arc::new(AtomicBool::from(true));
{
let running = Arc::clone(&running);
std::thread::spawn(move || {
running.swap(false, Ordering::Relaxed);
});
}
loop {
// ...
println!("Running....");
!running.load(Ordering::Relaxed) && break;
}
println!("Exhausted >.>");
}
The expected result is that rustc doesn't output a warning in this case.
Meta
- rustc version: 1.41.0
estebank and Bear-03
Metadata
Metadata
Assignees
Labels
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.C-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
RustyYato commentedon Feb 25, 2020
I don't think this is the intended use of logical operators, you should use an
if
, when side effects matter. This lint should help people stay away from mis-using operators in this way.nagisa commentedon Feb 25, 2020
While it is a bad style to do something like this, it is also perfectly valid code. As rustc’s lints are expected to have no false-positives, this is a genuine bug.
The stylistic preference should be linted by clippy, not rustc.
Centril commentedon Feb 25, 2020
For the record, I disagree that this is bad style, or it's at least debatable. It seems like it's taking advantage of the sugar that
&&
brings overif
, and Rust being a sideeffectful language, this should be expected.As for whether this should be linted against or not, it seems to me it should not, but cc @rust-lang/lang if there are objections.
eddyb commentedon Feb 25, 2020
I agree with @nagisa and @Centril,
&&
and||
should not be linted, they're control-flow operators, not value operators. Looks like operators like&
and|
also warn, so we can keep just those.estebank commentedon Mar 2, 2020
Pointers:
The code that needs to be modified is
rust/src/librustc_lint/unused.rs
Lines 37 to 111 in 18c275b
I believe you will have to explore the
ExprKind::Binary(_, _, rhs)
recursively to see if the leafrhs
is of type!
, and if that is the case, return early.The cases where the
lhs
is!
should already be handled by theunreachable_code
lint:eddyb commentedon Mar 2, 2020
I would just replace
Some(...)
withNone
on this line:As to lint correctly you'd probably also have to look at whether there any side-effects in the RHS.
spacekookie commentedon Mar 4, 2020
@estebank thanks! I'll try to have a look at this and post if I have any questions :)
UNUSED_MUST_USE
#76894lolbinarycat commentedon Sep 5, 2024
triage: still an issue on latest nightly
TilmanR commentedon May 24, 2025
I'm new to rust and a bit weird when it comes to styling, so I just ran into this issue while trying to make my early returns look distinct from "regular" if statements. (This helps me keep track of guard clauses.)
In such an extreme case the intention of a discarded result seems sufficiently clear. A fix for this would be marvelous.
Edit:
I took a look at the mentioned function on master, to see if I can figure out how to fix this. It's uncomfortably long and seems like a nightmare to maintain.