> ## Documentation Index
> Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Rust Deny Attribute
The `deny` attribute is a compiler directive used to elevate the severity of specific lints or lint groups to compilation errors. When the Rust compiler (`rustc`) or a linter (like Clippy) encounters code that violates a rule specified within a `deny` attribute, it emits a compiler error and aborts the build prior to the code generation phase. The compiler does not short-circuit upon finding a violation; it continues analyzing the code to report as many errors and lint violations as possible before terminating.
## Syntax and Application
The attribute can be applied at different levels of the Abstract Syntax Tree (AST) using either inner or outer attribute syntax. It accepts a comma-separated list of lint identifiers or lint groups.
**Inner Attribute Syntax (`#![...]`)**
Applies to the enclosing scope, typically placed at the top of the crate root (`main.rs` or `lib.rs`) or a module file.
```rust theme={"dark"}
#![deny(missing_docs, unused_imports)]
#![deny(clippy::all)]
```
**Outer Attribute Syntax (`#[...]`)**
Applies lexically to the specific item that immediately follows it, such as a function, struct, or module, including all of its descendants.
```rust theme={"dark"}
#[deny(non_camel_case_types)]
struct my_struct { // Compiler error: type `my_struct` should have an upper camel case name
id: i32,
}
```
## Scope and Overriding Mechanics
The `deny` attribute operates using lexical scoping. A lint level defined at a higher level of the AST propagates downward to all child nodes.
Crucially, `deny` establishes a strict baseline but **can be overridden** in narrower scopes. If a parent module denies a lint, a child module or specific function can explicitly downgrade that lint's severity using the `allow` or `warn` attributes.
```rust theme={"dark"}
#![deny(unused_variables)] // Denied globally for this file
fn strict_function() {
let a = 1; // Compiler error: unused variable `a`
}
#[allow(unused_variables)] // Overrides the global `deny` for this function only
fn relaxed_function() {
let b = 2; // Allowed by the override; no lint error triggered here
}
```
## `deny` vs. `forbid`
While both `deny` and `forbid` trigger compilation errors upon lint violations, their overriding mechanics differ strictly:
* **`deny`**: Can be overridden by `allow` or `warn` in a narrower scope.
* **`forbid`**: Locks the lint level. It cannot be overridden. If a lint is forbidden, any subsequent attempt to use `#[allow(...)]` or `#[warn(...)]` on that same lint in a child scope will itself trigger a compilation error.
Tired of Poor Rust Skills? Fix That With Deep Grasping!
Learn More
