Skip to main content

rustc_macros/
lib.rs

1// tidy-alphabetical-start
2#![allow(
3    rustc::default_hash_types,
4    reason = "we like performance but can't use `rustc_data_structures`"
5)]
6#![deny(
7    rustc::potential_query_instability,
8    reason = "macros shall produce deterministic output/errors"
9)]
10#![feature(never_type)]
11#![feature(proc_macro_diagnostic)]
12#![feature(proc_macro_tracked_env)]
13// tidy-alphabetical-end
14
15use proc_macro::TokenStream;
16use synstructure::decl_derive;
17
18mod current_version;
19mod diagnostics;
20mod extension;
21mod lift;
22mod print_attribute;
23mod query;
24mod serialize;
25mod stable_hash;
26mod symbols;
27mod type_foldable;
28mod type_visitable;
29mod visitable;
30
31// Reads the rust version (e.g. "1.75.0") from the CFG_RELEASE env var and
32// produces a `RustcVersion` literal containing that version (e.g.
33// `RustcVersion { major: 1, minor: 75, patch: 0 }`).
34#[proc_macro]
35pub fn current_rustc_version(input: TokenStream) -> TokenStream {
36    current_version::current_version(input)
37}
38
39#[proc_macro]
40pub fn rustc_queries(input: TokenStream) -> TokenStream {
41    query::rustc_queries(input)
42}
43
44#[proc_macro]
45pub fn symbols(input: TokenStream) -> TokenStream {
46    symbols::symbols(input.into()).into()
47}
48
49/// Derive an extension trait for a given impl block. The trait name
50/// goes into the parenthesized args of the macro, for greppability.
51/// For example:
52/// ```
53/// use rustc_macros::extension;
54/// #[extension(pub trait Foo)]
55/// impl i32 { fn hello() {} }
56/// ```
57///
58/// expands to:
59/// ```
60/// pub trait Foo { fn hello(); }
61/// impl Foo for i32 { fn hello() {} }
62/// ```
63#[proc_macro_attribute]
64pub fn extension(attr: TokenStream, input: TokenStream) -> TokenStream {
65    extension::extension(attr, input)
66}
67
68decl_derive!(
69    [StableHash, attributes(stable_hash)] => stable_hash::stable_hash_derive
70);
71decl_derive!(
72    [StableHash_NoContext, attributes(stable_hash)] => stable_hash::stable_hash_no_context_derive
73);
74
75// Encoding and Decoding derives
76decl_derive!([Decodable_NoContext] =>
77    /// See docs on derive [`Decodable`].
78    ///
79    /// Derives `Decodable<D> for T where D: Decoder`.
80    serialize::decodable_nocontext_derive
81);
82decl_derive!([Encodable_NoContext] => serialize::encodable_nocontext_derive);
83decl_derive!([Decodable] =>
84    /// Derives `Decodable<D> for T where D: SpanDecoder`
85    ///
86    /// # Deriving decoding traits
87    ///
88    /// > Some shared docs about decoding traits, since this is likely the first trait you find
89    ///
90    /// The difference between these derives can be subtle!
91    /// At a high level, there's the `T: Decodable<D>` trait that says some type `T`
92    /// can be decoded using a decoder `D`. There are various decoders!
93    /// The different derives place different *trait* bounds on this type `D`.
94    ///
95    /// Even though this derive, based on its name, seems like the most vanilla one,
96    /// it actually places a pretty strict bound on `D`: `SpanDecoder`.
97    /// It means that types that derive this can contain spans, among other things,
98    /// and still be decoded. The reason this is hard is that at least in metadata,
99    /// spans can only be decoded later, once some information from the header
100    /// is already decoded to properly deal with spans.
101    ///
102    /// The hierarchy is roughly:
103    ///
104    /// - derive [`Decodable_NoContext`] is the most relaxed bounds that could be placed on `D`,
105    ///   and is only really suited for structs and enums containing primitive types.
106    /// - derive [`BlobDecodable`] may be a better default, than deriving `Decodable`:
107    ///   it places fewer requirements on `D`, while still allowing some complex types to be decoded.
108    /// - derive [`LazyDecodable`]: Only for types containing `Lazy{Array,Table,Value}`.
109    /// - derive [`Decodable`] for structures containing spans. Requires `D: SpanDecoder`
110    /// - derive [`TyDecodable`] for types that require access to the `TyCtxt` while decoding.
111    ///   For example: arena allocated types.
112    serialize::decodable_derive
113);
114decl_derive!([Encodable] => serialize::encodable_derive);
115decl_derive!([TyDecodable] =>
116    /// See docs on derive [`Decodable`].
117    ///
118    /// Derives `Decodable<D> for T where D: TyDecoder`.
119    serialize::type_decodable_derive
120);
121decl_derive!([TyEncodable] => serialize::type_encodable_derive);
122decl_derive!([LazyDecodable] =>
123    /// See docs on derive [`Decodable`].
124    ///
125    /// Derives `Decodable<D> for T where D: LazyDecoder`.
126    /// This constrains the decoder to be specifically the decoder that can decode
127    /// `LazyArray`s, `LazyValue`s amd `LazyTable`s in metadata.
128    /// Therefore, we only need this on things containing LazyArray really.
129    ///
130    /// Most decodable derives mirror an encodable derive.
131    /// [`LazyDecodable`] and [`BlobDecodable`] together roughly mirror [`MetadataEncodable`]
132    serialize::lazy_decodable_derive
133);
134decl_derive!([BlobDecodable] =>
135    /// See docs on derive [`Decodable`].
136    ///
137    /// Derives `Decodable<D> for T where D: BlobDecoder`.
138    ///
139    /// Most decodable derives mirror an encodable derive.
140    /// [`LazyDecodable`] and [`BlobDecodable`] together roughly mirror [`MetadataEncodable`]
141    serialize::blob_decodable_derive
142);
143decl_derive!([MetadataEncodable] =>
144    /// Most encodable derives mirror a decodable derive.
145    /// [`MetadataEncodable`] is roughly mirrored by the combination of [`LazyDecodable`] and [`BlobDecodable`]
146    serialize::meta_encodable_derive
147);
148
149decl_derive!(
150    [TypeFoldable, attributes(type_foldable)] =>
151    /// Derives `TypeFoldable` for the annotated `struct` or `enum` (`union` is not supported).
152    ///
153    /// The fold will produce a value of the same struct or enum variant as the input, with
154    /// each field respectively folded using the `TypeFoldable` implementation for its type.
155    /// However, if a field of a struct or an enum variant is annotated with
156    /// `#[type_foldable(identity)]` then that field will retain its incumbent value (and its
157    /// type is not required to implement `TypeFoldable`).
158    type_foldable::type_foldable_derive
159);
160decl_derive!(
161    [TypeVisitable, attributes(type_visitable)] =>
162    /// Derives `TypeVisitable` for the annotated `struct` or `enum` (`union` is not supported).
163    ///
164    /// Each field of the struct or enum variant will be visited in definition order, using the
165    /// `TypeVisitable` implementation for its type. However, if a field of a struct or an enum
166    /// variant is annotated with `#[type_visitable(ignore)]` then that field will not be
167    /// visited (and its type is not required to implement `TypeVisitable`).
168    type_visitable::type_visitable_derive
169);
170decl_derive!(
171    [Walkable, attributes(visitable)] =>
172    /// Derives `Walkable` for the annotated `struct` or `enum` (`union` is not supported).
173    ///
174    /// Each field of the struct or enum variant will be visited in definition order, using the
175    /// `Walkable` implementation for its type. However, if a field of a struct or an enum
176    /// variant is annotated with `#[visitable(ignore)]` then that field will not be
177    /// visited (and its type is not required to implement `Walkable`).
178    visitable::visitable_derive
179);
180decl_derive!([Lift, attributes(lift)] => lift::lift_derive);
181decl_derive!(
182    [Diagnostic, attributes(
183        // struct and field attributes
184        diag,
185        help,
186        help_once,
187        note,
188        note_once,
189        warning,
190        // field attributes
191        primary_span,
192        label,
193        subdiagnostic,
194        suggestion,
195        suggestion_short,
196        suggestion_hidden,
197        suggestion_verbose)] =>
198        #[doc = "See <https://rustc-dev-guide.rust-lang.org/diagnostics/diagnostic-structs.html#derivediagnostic>"]
199        diagnostics::diagnostic_derive
200);
201decl_derive!(
202    [Subdiagnostic, attributes(
203        // struct/variant attributes
204        label,
205        help,
206        help_once,
207        note,
208        note_once,
209        warning,
210        subdiagnostic,
211        suggestion,
212        suggestion_short,
213        suggestion_hidden,
214        suggestion_verbose,
215        multipart_suggestion,
216        multipart_suggestion_short,
217        multipart_suggestion_hidden,
218        // field attributes
219        primary_span,
220        suggestion_part,
221        applicability)] => diagnostics::subdiagnostic_derive
222);
223
224/// This macro creates a translatable `DiagMessage` from a fluent format string.
225/// It should be used in places where a translatable message is needed, but struct diagnostics are undesired.
226///
227/// This macro statically checks that the message is valid Fluent, but not that variables in the Fluent message actually exist.
228#[proc_macro]
229pub fn msg(input: TokenStream) -> TokenStream {
230    diagnostics::msg_macro(input)
231}
232
233decl_derive! {
234    [PrintAttribute] =>
235    /// Derives `PrintAttribute` for `AttributeKind`.
236    /// This macro is pretty specific to `rustc_hir::attrs` and likely not that useful in
237    /// other places. It's deriving something close to `Debug` without printing some extraneous
238    /// things like spans.
239    print_attribute::print_attribute
240}