1//! Centralized logic for parsing and attributes.2//!3//! ## Architecture4//! This crate is part of a series of crates and modules that handle attribute processing.5//! - [rustc_hir::attrs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/index.html): Defines the data structures that store parsed attributes6//! - [rustc_attr_parsing](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_attr_parsing/index.html): This crate, handles the parsing of attributes7//! - (planned) rustc_attr_validation: Will handle attribute validation, logic currently handled in `rustc_passes`8//!9//! The separation between data structures and parsing follows the principle of separation of concerns.10//! Data structures (`rustc_hir::attrs`) define what attributes look like after parsing.11//! This crate (`rustc_attr_parsing`) handles how to convert raw tokens into those structures.12//! This split allows other parts of the compiler to use the data structures without needing13//! the parsing logic, making the codebase more modular and maintainable.14//!15//! ## Background16//! Previously, the compiler had a single attribute definition (`ast::Attribute`) with parsing and17//! validation scattered throughout the codebase. This was reorganized for better maintainability18//! (see [#131229](https://github.com/rust-lang/rust/issues/131229)).19//!20//! ## Types of Attributes21//! In Rust, attributes are markers that can be attached to items. They come in two main categories.22//!23//! ### 1. Active Attributes24//! These are attribute-like proc-macros that expand into other Rust code.25//! They can be either user-defined or compiler-provided. Examples of compiler-provided active attributes:26//! - `#[derive(...)]`: Expands into trait implementations27//! - `#[cfg()]`: Expands based on configuration28//! - `#[cfg_attr()]`: Conditional attribute application29//!30//! ### 2. Inert Attributes31//! These are pure markers that don't expand into other code. They guide the compilation process.32//! They can be user-defined (in proc-macro helpers) or built-in. Examples of built-in inert attributes:33//! - `#[stable()]`: Marks stable API items34//! - `#[inline()]`: Suggests function inlining35//! - `#[repr()]`: Controls type representation36//!37//! ```text38//! Active Inert39//! ┌──────────────────────┬──────────────────────┐40//! │ (mostly in) │ these are parsed │41//! │ rustc_builtin_macros │ here! │42//! │ │ │43//! │ #[derive(...)] │ #[stable()] │44//! Built-in │ #[cfg()] │ #[inline()] │45//! │ #[cfg_attr()] │ #[repr()] │46//! │ │ │47//! ├──────────────────────┼──────────────────────┤48//! │ │ │49//! │ │ `b` in │50//! │ │ #[proc_macro_derive( │51//! User created │ #[proc_macro_attr()] │ a, │52//! │ │ attributes(b) │53//! │ │ ] │54//! └──────────────────────┴──────────────────────┘55//! ```56//!57//! ## How This Crate Works58//! In this crate, syntactical attributes (sequences of tokens that look like59//! `#[something(something else)]`) are parsed into more semantic attributes, markers on items.60//! Multiple syntactic attributes might influence a single semantic attribute. For example,61//! `#[stable(...)]` and `#[unstable()]` cannot occur together, and both semantically define62//! a "stability" of an item. So, the stability attribute has an63//! [`AttributeParser`](attributes::AttributeParser) that recognizes both the `#[stable()]`64//! and `#[unstable()]` syntactic attributes, and at the end produce a single65//! [`AttributeKind::Stability`](rustc_hir::attrs::AttributeKind::Stability).66//!67//! When multiple instances of the same attribute are allowed, they're combined into a single68//! semantic attribute. For example:69//!70//! ```rust71//! #[repr(C)]72//! #[repr(packed)]73//! struct Meow {}74//! ```75//!76//! This is equivalent to `#[repr(C, packed)]` and results in a single `AttributeKind::Repr`77//! containing both `C` and `packed` annotations.78//!79//! ## Early attribute parsing80//!81//! While lowering to the HIR, all attributes are parsed using the attribute parsers.82//! However, sometimes an attributes' parsed form is needed before the HIR is constructed.83//! This is referred to as "early" attribute parsing,84//! and is performed using the `parse_limited_*` family of functions on `AttributeParser`.8586// tidy-alphabetical-start87#![feature(decl_macro)]88#![feature(iter_intersperse)]89#![feature(try_blocks)]90#![recursion_limit = "256"]91// tidy-alphabetical-end9293#[macro_use]94/// All the individual attribute parsers for each of rustc's built-in attributes.95mod attributes;9697/// All the important types given to attribute parsers when parsing98pub(crate) mod context;99100/// Code that other crates interact with, to actually parse a list (or sometimes single)101/// attribute.102mod interface;103104/// Despite this entire module called attribute parsing and the term being a little overloaded,105/// in this module the code lives that actually breaks up tokenstreams into semantic pieces of attributes,106/// like lists or name-value pairs.107pub mod parser;108109mod early_parsed;110mod errors;111mod safety;112mod session_diagnostics;113mod target_checking;114pub mod validate_attr;115116pub use attributes::AttributeSafety;117pub use attributes::cfg::{118 CFG_TEMPLATE, EvalConfigResult, eval_config_entry, parse_cfg, parse_cfg_attr, parse_cfg_entry,119};120pub use attributes::cfg_select::*;121pub use attributes::util::{is_builtin_attr, parse_version};122pub use context::{OmitDoc, ShouldEmit};123pub use interface::{AttributeParser, EmitAttribute};124pub use rustc_parse::parser::Recovery;125pub use session_diagnostics::ParsedDescription;