Rust Crate Attributes: Where to Add #![feature(...)]

You will learn what a Rust crate attribute is, how #![...] differs from an item attribute such as #[...], and where crate-level settings belong. You will also learn why this particular if_let feature-gate message is from an old Rust compiler era: if let is stable in modern Rust and does not need a feature flag.

A crate is Rust's compilation unit. For a binary application, the crate root is usually src/main.rs. For a library, it is usually src/lib.rs.

A crate attribute configures the entire crate. It uses the inner attribute form:

#![attribute_name]

Inner attributes begin with #! and are normally placed at the very top of the crate root, before items such as use, mod, struct, and fn main.

For example, an old nightly-only feature gate looked like this:

#![feature(some_experimental_feature)]

fn main() {
    println!("Hello");
}

The compiler message in the question is historical. In very early Rust versions, if let required the if_let experimental feature. In current Rust, if let has long been stable, so you should not add #![feature(if_let)]. A modern compiler will reject it because that feature name is no longer needed or recognized.

If an old repository produces this message, it was written for an old Rust toolchain. Prefer updating the project and its dependencies, or use the toolchain version documented by that historical project rather than adding obsolete feature gates.

Think of a crate as a whole book:

• A crate attribute is an instruction printed inside the front cover. It affects the entire book.
• An item attribute is a sticky note attached to one chapter, function, module, or struct. It affects only that item.

The leading exclamation mark is the clue:

• #![...] means “apply this to the enclosing crate or module.”
• #[...] means “apply this to the next item.”

Because crate attributes are instructions for the whole program, Rust conventionally puts them at the top of main.rs or lib.rs.

Crate attributes use #![...] and go in the crate root.

// src/main.rs
#![allow(dead_code)]

fn unused_helper() {
    println!("This function is intentionally unused");
}

fn main() {
    println!("Program started");
}

Here, #![allow(dead_code)] applies to the whole binary crate, so Rust does not warn about unused_helper.

An attribute without ! applies only to the following item:

#[allow(dead_code)]
fn unused_helper() {
    println!("This function is intentionally unused");
}

fn main() {
    println!("Program started");
}

This version suppresses the warning only for unused_helper.

For historical nightly features, the placement would have been:

// src/lib.rs or src/main.rs
#![feature(example_feature)]

fn main() {
    // Code using that nightly feature
}

However, #![feature(...)] works only with a nightly Rust compiler, and only for active nightly features. Do not add a feature gate merely because an old tutorial or old compiler message mentions one.

Consider this crate root:

#![allow(unused_variables)]

fn main() {
    let temporary_value = 42;
    println!("Done");
}

Execution and compilation proceed as follows:

1. Rust begins compiling the crate from src/main.rs.
2. It reads #![allow(unused_variables)] as a crate-wide compiler setting.
3. Rust parses fn main and notices that temporary_value is never read.
4. Normally, that would produce an unused-variable warning.
5. The crate attribute tells the compiler to allow that warning category throughout this crate.
6. The compiled program runs main and prints:

Done

The attribute changes compiler diagnostics; it does not run as application code.

Crate attributes are commonly used for project-wide compiler and documentation settings:

• Control warnings during a migration: temporarily allow a warning while incrementally improving older code.

  #![allow(deprecated)]
  

• Require documentation for public APIs in a library.

  #![warn(missing_docs)]
  

• Configure conditional compilation for a platform-specific crate.

  #![cfg(target_os = "linux")]
  

• Build no_std software for embedded devices or restricted environments.

  #![no_std]
  

• Use an active experimental language capability when a project intentionally targets nightly Rust.

  #![feature(some_nightly_feature)]
  

Feature gates should be an explicit project decision. Most applications and libraries should target stable Rust whenever possible.

In production codebases, crate attributes are usually kept small and intentional because they can affect every module.

Common patterns include:

• Lint policy at the crate root

  #![warn(clippy::all)]
  #![deny(unsafe_op_in_unsafe_fn)]
  

  Teams use these to make quality and safety expectations consistent.

• Narrower lint exceptions on a specific item

  #[allow(clippy::too_many_arguments)]
  fn create_connection(host: &str, port: u16, user: &str, password: &str) {
      // ...
  }
  

  Prefer this narrow form over a crate-wide #![allow(...)] when only one function needs an exception.

• Conditional modules

  #[cfg(feature = "json")]
  mod json_output;
  

  This is an item attribute, not a crate attribute, because it controls one module.

• Nightly features

  A project using nightly normally documents its required toolchain in rust-toolchain.toml and pins or regularly tests it. Feature gates belong in the crate roots that use them, not in arbitrary source files.

For an old repository, first inspect README.md, rust-toolchain.toml, and Cargo.toml. They may identify the intended Rust version. Updating the code for modern stable Rust is generally more maintainable than reviving obsolete feature gates.

Putting a crate attribute inside main

This is invalid because attributes configure code during parsing and compilation, not while the function runs:

fn main() {
    #![allow(dead_code)] // Incorrect
}

Put it before fn main instead:

#![allow(dead_code)]

fn main() {
    println!("Hello");
}

Using #[...] when you mean #![...]

This applies only to the next item, not the whole crate:

#[allow(dead_code)]
fn helper() {}

Use #![allow(dead_code)] at the crate root only when the setting should apply globally.

Adding obsolete feature gates

This is not appropriate in modern Rust:

#![feature(if_let)]

if let is stable. Write it directly:

let value = Some(5);

if let Some(number) = value {
    println!("Found {number}");
}

Assuming #![feature(...)] works on stable Rust

Feature gates require nightly Rust. On stable, Rust reports an error similar to “#![feature] may not be used on the stable release channel.” Check the project's toolchain requirements before using one.

Hiding useful warnings globally

A broad setting such as #![allow(warnings)] can conceal real problems. Prefer fixing warnings or suppressing a specific lint on the smallest necessary item.

Rust language feature gates and Cargo features are different:

• A Rust feature gate enables an experimental compiler capability and requires nightly.
• A Cargo feature is a package-defined configuration switch, often used to make dependencies or modules optional.

For example:

[features]
json = []

is a Cargo feature declaration, not a Rust compiler feature gate.

// Crate-wide attribute: put at the top of src/main.rs or src/lib.rs
#![warn(missing_docs)]

// Item-only attribute: put immediately before an item
#[derive(Debug)]
struct User {
    name: String,
}

• #![...] is an inner attribute.
• #[...] is an outer attribute.
• A binary crate root is usually src/main.rs.
• A library crate root is usually src/lib.rs.
• Put crate attributes before use, mod, structs, and functions.
• #![feature(...)] requires a nightly compiler.
• Do not add #![feature(if_let)] today: if let is stable.
• Prefer narrow #[allow(...)] attributes over broad crate-wide #![allow(...)] settings.
• Cargo features in Cargo.toml are separate from Rust #![feature(...)] gates.

Where do I put a crate attribute in Rust?

Place it at the beginning of the crate root: usually src/main.rs for an executable or src/lib.rs for a library.

What does #! mean in Rust attributes?

It marks an inner attribute. It applies to the enclosing crate or module rather than only to the next item.

Do I need #![feature(if_let)] in modern Rust?

No. if let is stable in modern Rust. An old project reporting otherwise was built for a much older compiler version.

Can I use #![feature(...)] on stable Rust?

No. Rust language feature gates are limited to nightly Rust. Use stable alternatives whenever they exist.

Is a Cargo feature the same as #![feature(...)]?

No. Cargo features are package configuration options declared in Cargo.toml. #![feature(...)] enables an experimental Rust compiler feature.

Why does an old Rust repository fail to compile today?

Its source code, dependencies, or build assumptions may target an older Rust release. Check its documentation and toolchain files, then update the code or use the documented historical toolchain.

Should I put #![allow(...)] in every Rust project?

Usually no. Warnings often identify useful cleanup work. Allow a lint only when you understand why it is safe, and scope the exception as narrowly as possible.

• Rust attributes — The general #[...] and #![...] annotation system.
• Inner and outer attributes — The scope difference between crate/module attributes and item attributes.
• Crates and crate roots — Explains why main.rs and lib.rs are special files.
• Rust toolchains — Stable, beta, and nightly Rust determine which compiler features are available.
• Feature gates — Controls access to experimental Rust language capabilities.
• Cargo features — Package-level optional configuration, distinct from compiler feature gates.
• Conditional compilation with cfg — Uses attributes to include code only on certain platforms or configurations.
• Rust lints — Compiler diagnostics controlled by allow, warn, deny, and forbid.