oxc-project/oxc · warning · OxcDiagnostic

Unexpected use of `{operator:?}`.

Error message

Unexpected use of `{operator:?}`.

What it means

Diagnostic from the oxlint rule `no-bitwise` (crates/oxc_linter/src/rules/eslint/no_bitwise.rs). It fires on use of bitwise operators (`&`, `|`, `^`, `~`, `<<`, `>>`, `>>>`) and bitwise-assignment forms. The rule assumes bitwise operators in typical application code are typos for logical operators (`&&`, `||`); the message renders the operator with Rust `{:?}` formatting, so it appears quoted, e.g. Unexpected use of `"&"`. The config supports an `allow` list of operator exceptions.

Source

Thrown at crates/oxc_linter/src/rules/eslint/no_bitwise.rs:18

use oxc_ast::AstKind;
use oxc_diagnostics::OxcDiagnostic;
use oxc_macros::declare_oxc_lint;
use oxc_span::Span;
use oxc_str::CompactStr;
use oxc_syntax::operator::BinaryOperator;
use schemars::JsonSchema;
use serde::Deserialize;
use serde_json::Value;

use crate::{
    AstNode,
    context::LintContext,
    rule::{DefaultRuleConfig, Rule},
};

fn no_bitwise_diagnostic(operator: &str, span: Span) -> OxcDiagnostic {
    OxcDiagnostic::warn(format!("Unexpected use of `{operator:?}`."))
        .with_help("bitwise operators are not allowed, maybe you mistyped `&&` or `||`?")
        .with_label(span)
}

#[derive(Debug, Default, Clone, Deserialize)]
pub struct NoBitwise(Box<NoBitwiseConfig>);

#[derive(Debug, Default, Clone, JsonSchema, Deserialize)]
#[serde(rename_all = "camelCase", default, deny_unknown_fields)]
pub struct NoBitwiseConfig {
    /// The `allow` option permits the given list of bitwise operators to be used
    /// as exceptions to this rule.
    ///
    /// For example `{ "allow": ["~"] }` would allow the use of the bitwise operator
    /// `~` without restriction. Such as in the following:
    ///
    /// ```javascript
    /// ~[1,2,3].indexOf(1) === -1;

View on GitHub (pinned to e1e7af627c)

Solutions

1. If the operator is a typo, replace it with the logical operator: `a && b`, `a || b`.
2. If the bitwise use is intentional (masks, hashing, binary protocols), allow it via config: `{ "rules": { "no-bitwise": ["error", { "allow": ["&", "|", "^", "<<", ">>", ">>>"] }] } }` in .oxlintrc.json.
3. For isolated intentional uses, suppress inline with `// oxlint-disable-next-line no-bitwise`.
4. Where truly needed for performance, extract flag logic into a named helper module and allow the rule only in that directory.

Example fix

// before
if (mode & 2) { /* ... */ }

// after (typo case)
if (mode && hasFlag(mode, 2)) { /* ... */ }

// after (intentional case: .oxlintrc.json)
// { "rules": { "no-bitwise": ["error", { "allow": ["&"] }] } }

// Audit which bitwise operators your codebase actually uses before enabling the rule
const used = execSync("rg -o '[&|^~]|<<|>>>?|>>' src/ | sort | uniq -c").toString();
// then configure .oxlintrc.json allow list from this inventory

When it happens

Trigger: Any BinaryExpression with a bitwise operator, UnaryExpression with `~`, or an assignment expression with a bitwise compound operator that is not in the configured `allow` array — e.g. `if (a & b)`, `flags |= MASK`, `x = ~y`.

Common situations: Teams that adopted the eslint `no-bitwise` restriction migrating configs to oxlint; accidental `&`/`|` in place of `&&`/`||` in conditions; legacy flag-manipulation code (permission masks, color channel math) passing through a config without an `allow` entry.

Related errors

• Unexpected console statement.
• Unexpected use of `continue` statement.
• `@yields` tag is required when using `@generator` tag.
• Use of `{method_name}` is not allowed
• The description for the @ts-{ts_comment_name} directive must

AI-assisted analysis of oxc-project/oxc@e1e7af627c (2026-08-20). Data as JSON: /api/errors/6ae5da9c45e282b0. Report an issue: GitHub.