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