oxc-project/oxc · warning · OxcDiagnostic
Both sides of the logical operator are equivalent
Error message
Both sides of the logical operator are equivalent
What it means
The 'equivalent' variant of `oxc/const-comparisons`: the two operands of `&&`/`||` are equality comparisons over the same operand pair, possibly swapped — `a === b && b === a` (matched via `equality_relation` accepting same-order or swapped-order operands with identical operators). The expression always equals either side alone, so one comparison is redundant.
Source
Thrown at crates/oxc_linter/src/rules/oxc/const_comparisons.rs:65
OxcDiagnostic::warn(format!("This comparison will always evaluate to {evaluates_to}"))
.with_help(help)
.with_label(span);
if let Some(note) = precedence_note { diagnostic.with_note(note) } else { diagnostic }
}
fn identical_expressions_logical_operator(left_span: Span, right_span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Both sides of the logical operator are the same")
.with_help("This logical expression will always evaluate to the same value as the expression itself.")
.with_labels([
left_span.label("If this expression evaluates to true"),
right_span
.label("This expression will always evaluate to true"),
])
}
fn equivalent_expressions_logical_operator(left_span: Span, right_span: Span) -> OxcDiagnostic {
OxcDiagnostic::warn("Both sides of the logical operator are equivalent")
.with_help("This logical expression will always evaluate to the same value as either side.")
.with_labels([
left_span.label("If this expression evaluates to true"),
right_span.label("This equivalent expression will always evaluate to true"),
])
}
fn complementary_expressions_logical_operator(
always_truthy: bool,
left_span: Span,
right_span: Span,
) -> OxcDiagnostic {
let (left_label, right_label) = if always_truthy {
("If this expression evaluates to false", "This expression must evaluate to true")
} else {
("If this expression evaluates to true", "This expression cannot also evaluate to true")
};
View on GitHub (pinned to e1e7af627c)
Solutions
- Keep a single comparison: `a === b` (equality operators are symmetric)
- Delete the swapped duplicate
- If the second comparison was meant to test a different pair, fix the identifiers
Example fix
// before
if (a === b && b === a) { /* ... */ }
// after
if (a === b) { /* ... */ } Defensive patterns
Strategy: validation
Validate before calling
// .oxlintrc.json — correctness rule (on in the default category set)
{
"rules": { "oxc/const-comparisons": "error" }
}
// CLI: npx oxlint src/ Prevention
- Trust that `===` is symmetric: one comparison suffices
- Avoid hand-writing symmetry checks; use a deep-equal helper when order matters
- Run oxlint so equivalent-operand pairs are flagged
When it happens
Trigger: `a === b && b === a`; `a != b && b != a`; equality predicates whose operands were swapped in one copy during a refactor.
Common situations: Symmetry checks written 'for safety'; developers unsure whether `===` is symmetric; generated equality predicates and codemod rewrites that swap argument order in one copy.
Related errors
- Unexpected object literal comparison.
- Left-hand side of `&&` operator has no effect.
- Right-hand side of `&&` operator has no effect.
- Unexpected constant comparison
- Both sides of the logical operator are the same
AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20).
Data as JSON: /api/errors/23aaf69d0179d5ca.
Report an issue: GitHub.