bjoernager/rust
bjoernager/rust
1
Fork 0
Code Issues Pull requests Activity

Change span field accesses to method calls

Browse source
This commit is contained in:
Jana Dönszelmann 2025-02-09 22:49:28 +01:00
parent f43e549b88
commit 115b3b03b0
No known key found for this signature in database
27 changed files with 264 additions and 202 deletions
Download patch file Download diff file Expand all files Collapse all files

41
compiler/rustc_attr_parsing/src/lib.rs
View file

@ -1,8 +1,41 @@
//! Functions and types dealing with attributes and meta items.
//! Centralized logic for parsing and attributes.
//!
//! FIXME(Centril): For now being, much of the logic is still in `rustc_ast::attr`.
//! The goal is to move the definition of `MetaItem` and things that don't need to be in `syntax`
//! to this crate.
//! Part of a series of crates:
//! - rustc_attr_data_structures: contains types that the parsers parse into
//! - rustc_attr_parsing: this crate
//! - (in the future): rustc_attr_validation
//!
//! History: Check out [#131229](https://github.com/rust-lang/rust/issues/131229).
//! There used to be only one definition of attributes in the compiler: `ast::Attribute`.
//! These were then parsed or validated or both in places distributed all over the compiler.
//! This was a mess...
//!
//! Attributes are markers on items. Most are actually attribute-like proc-macros, and are expanded
//! but some remain as the so-called built-in attributes. These are not macros at all, and really
//! are just markers to guide the compilation process. An example is `#[inline(...)]` which changes
//! how code for functions is generated. Built-in attributes aren't macros because there's no rust
//! syntax they could expand to.
//!
//! In this crate, syntactical attributes (sequences of tokens that look like
//! `#[something(something else)]`) are parsed into more semantic attributes, markers on items.
//! Multiple syntactic attributes might influence a single semantic attribute. For example,
//! `#[stable(...)]` and `#[unstable()]` cannot occur together, and both semantically define
//! a "stability" of an item. So, the stability attribute has an
//! [`AttributeParser`](attributes::AttributeParser) that recognizes both the `#[stable()]`
//! and `#[unstable()]` syntactic attributes, and at the end produce a single [`AttributeKind::Stability`].
//!
//! As a rule of thumb, when a syntactical attribute can be applied more than once, they should be
//! combined into a single semantic attribute. For example:
//!
//! ```
//! #[repr(C)]
//! #[repr(packed)]
//! struct Meow {}
//! ```
//!
//! should result in a single `AttributeKind::Repr` containing a list of repr annotations, in this
//! case `C` and `packed`. This is equivalent to writing `#[repr(C, packed)]` in a single
//! syntactical annotation.
// tidy-alphabetical-start
#![allow(internal_features)]