Forbid Attribute

The forbid attribute is a compiler directive in Rust that sets the severity level of a specified lint or lint group to a fatal error while simultaneously preventing that level from being overridden. It is the strictest lint level available in the Rust compiler (rustc). Unlike the deny attribute, which also turns lints into errors, forbid establishes an immutable state for the lint within the lexical scope and item hierarchy; once applied, the specified lint cannot be downgraded in any nested scopes.

Syntax

The attribute can be applied as an inner attribute (affecting the entire enclosing crate or module) or an outer attribute (affecting a specific item, statement, or expression, and its descendants). Multiple lints can be passed as a comma-separated list.

// Inner attribute syntax (typically placed at the top of lib.rs or main.rs)
#![forbid(lint_name, another_lint_name)]

// Outer attribute syntax (placed above a function, struct, module, statement, or expression)
#[forbid(lint_group_name)]
fn example_function() {}

Manifest Configuration (Cargo.toml)

As of Rust 1.74, the idiomatic method for configuring global lint levels is through the [lints] table in the Cargo.toml manifest. This applies the forbid level across the entire crate without requiring source code attributes or command-line flags.

[lints.rust]
unused_variables = "forbid"

[lints.clippy]
all = "forbid"

Command-Line Configuration

The forbid level can also be applied globally during compilation using the command-line interface. This is achieved by passing the -F or --forbid flag directly to rustc or through Cargo.

# Using rustc directly
rustc -F unused_variables main.rs


# Using Cargo with a built-in compiler lint
cargo rustc -- -F unused_variables


# Using Cargo to forbid Clippy lints (requires the clippy driver)
cargo clippy -- -F clippy::all

Compiler Behavior and Mechanics

When rustc processes a forbid directive, it enforces two strict rules:

1. Compilation Failure: Any code violating the forbidden lint will emit a compiler error, ensuring the build ultimately fails. The compiler does not halt immediately upon encountering the violation; it continues analyzing the code to report as many errors as possible in the current compilation phase before terminating.
2. Override Rejection: Any attempt to redefine the lint level using #[allow(...)], #[warn(...)], or #[deny(...)] further down the item hierarchy will trigger an E0453 compiler error (“allow/warn/deny overruled by outer forbid”).

Mechanical Demonstration

The following code illustrates the mechanical difference between a standard lint violation and an illegal override attempt under a forbid directive:

// Enforce the forbid level for the entire module/crate
#![forbid(unused_variables)]

fn standard_violation() {
    // ERROR: unused variable: `x`
    // The compiler flags this as an error and will fail the build,
    // but continues checking the rest of the file.
    let x = 5; 
}

fn override_attempt() {
    // ERROR[E0453]: allow(unused_variables) overruled by outer forbid
    // The compiler rejects the attribute itself, regardless of whether 
    // a variable is actually unused.
    #[allow(unused_variables)]
    let y = 10;
}

Interaction with Lint Groups

When forbid is applied to a lint group (e.g., rust_2018_idioms or clippy::all), the immutability applies to every individual lint contained within that group. Attempting to allow a specific, single lint that belongs to a forbidden group will result in the same E0453 override error.

#[forbid(nonstandard_style)]
mod example_module {
    // ERROR[E0453]: allow(non_camel_case_types) overruled by outer forbid
    // `non_camel_case_types` is a constituent of the `nonstandard_style` group.
    #[allow(non_camel_case_types)]
    struct my_struct;
}

Master Rust with Deep Grasping Methodology!

Learn More