-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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 leafrhsis of type!, and if that is the case, return early.The cases where the
lhsis!should already be handled by theunreachable_codelint:eddyb commentedon Mar 2, 2020
I would just replace
Some(...)withNoneon 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