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}