rucc_types/kind.rs
1//! What a C type is made of, before any of it has been interned.
2//!
3//! Design: `spec/07-types-and-semantics.md` section 7.1.
4//!
5//! Everything here is `Copy` and small, because [`TypeKind`] is the interning key and a key
6//! that owns a heap allocation cannot be hashed cheaply or compared cheaply. The two parts of
7//! a type that are genuinely variable length, a function's parameter list and a record's
8//! members, live in side tables and are referred to by index.
9
10use std::num::NonZeroU32;
11
12use rucc_base::Symbol;
13use rucc_target::Convention;
14
15use crate::TypeId;
16
17/// The qualifiers a type can carry.
18///
19/// A bitmask in the interning key rather than a chain of wrapper nodes, so `const int` is one
20/// entry in the table beside `int` rather than a node pointing at it. That makes stripping
21/// qualifiers a field read instead of a walk, which matters because almost every semantic rule
22/// in C is stated on the unqualified type.
23///
24/// `_Atomic` is deliberately not here. C lets it be written in the same position as a
25/// qualifier, but `_Atomic(T)` is a different type from `T` with its own size and alignment,
26/// so it is a type constructor, [`TypeKind::Atomic`], and the parser is what maps the
27/// qualifier spelling onto it.
28#[derive(Debug, Clone, Copy, PartialEq, Eq, Default, Hash, PartialOrd, Ord)]
29pub struct Qualifiers(u8);
30
31impl Qualifiers {
32 /// No qualifiers.
33 pub const NONE: Qualifiers = Qualifiers(0);
34 /// `const`.
35 pub const CONST: Qualifiers = Qualifiers(1);
36 /// `volatile`.
37 pub const VOLATILE: Qualifiers = Qualifiers(2);
38 /// `restrict`.
39 pub const RESTRICT: Qualifiers = Qualifiers(4);
40 /// `__seg_fs`, the x86 named address space counted from the `%fs` segment base.
41 ///
42 /// A named address space is a qualifier in the C extension that defines them (ISO/IEC TR
43 /// 18037) and in gcc, so it lives here with the other three. Two pointers to the same type in
44 /// different address spaces are different types, which the table gets for free by keeping
45 /// the qualifier on the pointee, and lvalue conversion drops it the way it drops `const`.
46 pub const SEG_FS: Qualifiers = Qualifiers(8);
47 /// `__seg_gs`, the same for the `%gs` segment base, which is what the Linux percpu
48 /// accessors on x86 use from 6.9.
49 pub const SEG_GS: Qualifiers = Qualifiers(16);
50 /// Both address space qualifiers, for asking which one a type is in.
51 pub const SPACES: Qualifiers = Qualifiers(8 | 16);
52
53 /// Whether every qualifier in `other` is present here.
54 #[inline]
55 #[must_use]
56 pub const fn has(self, other: Qualifiers) -> bool {
57 self.0 & other.0 == other.0
58 }
59
60 /// This set with `other` added.
61 #[inline]
62 #[must_use]
63 pub const fn with(self, other: Qualifiers) -> Qualifiers {
64 Qualifiers(self.0 | other.0)
65 }
66
67 /// This set with `other` removed.
68 #[inline]
69 #[must_use]
70 pub const fn without(self, other: Qualifiers) -> Qualifiers {
71 Qualifiers(self.0 & !other.0)
72 }
73
74 /// The address space qualifier on this set, which is [`Qualifiers::NONE`] for the generic
75 /// one.
76 #[inline]
77 #[must_use]
78 pub const fn space(self) -> Qualifiers {
79 Qualifiers(self.0 & Self::SPACES.0)
80 }
81
82 /// Whether there are no qualifiers at all.
83 #[inline]
84 #[must_use]
85 pub const fn is_none(self) -> bool {
86 self.0 == 0
87 }
88}
89
90/// The standard integer types, the character types kept apart from them, and `__int128`.
91///
92/// `Char` is its own kind rather than an alias for one of the other two. The standard makes
93/// plain `char` a third type distinct from both `signed char` and `unsigned char` even though
94/// it has the same range as one of them, and a compiler that folds it into whichever one the
95/// target picked gets `char *` and `signed char *` wrongly deemed compatible.
96///
97/// `__int128` is here rather than modelled as a `_BitInt(128)`, because the two are different
98/// types with different layouts: `__int128` is sixteen bytes aligned to sixteen on every
99/// target we have, and `_BitInt(128)` is aligned to its granule, which is eight on x86-64. It
100/// is available everywhere for us, since all three architectures are 64-bit, and GCC has it
101/// on every 64-bit target. It is deliberately not an extended integer type in the sense the
102/// standard means, which is what keeps `intmax_t` sixty four bits wide the way GCC has it.
103#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
104pub enum IntKind {
105 /// `char`, whose signedness is a target property.
106 Char,
107 /// `signed char`.
108 SChar,
109 /// `unsigned char`.
110 UChar,
111 /// `short`.
112 Short,
113 /// `unsigned short`.
114 UShort,
115 /// `int`.
116 Int,
117 /// `unsigned int`.
118 UInt,
119 /// `long`, the width that separates LP64 from Windows LLP64.
120 Long,
121 /// `unsigned long`.
122 ULong,
123 /// `long long`.
124 LongLong,
125 /// `unsigned long long`.
126 ULongLong,
127 /// `__int128`.
128 Int128,
129 /// `unsigned __int128`.
130 UInt128,
131}
132
133impl IntKind {
134 /// Every integer kind, in rank order, with `__int128` last.
135 ///
136 /// The order is what the internal index agrees with, and it is also the order the standard
137 /// walks when it picks the type of an integer constant, so a table walk over the candidate
138 /// list for a suffix is a walk over a slice of this. `__int128` is at the end because that
139 /// is where GCC reaches for it: after every standard type has been tried and none of them
140 /// was wide enough.
141 pub const ALL: [IntKind; 13] = [
142 IntKind::Char,
143 IntKind::SChar,
144 IntKind::UChar,
145 IntKind::Short,
146 IntKind::UShort,
147 IntKind::Int,
148 IntKind::UInt,
149 IntKind::Long,
150 IntKind::ULong,
151 IntKind::LongLong,
152 IntKind::ULongLong,
153 IntKind::Int128,
154 IntKind::UInt128,
155 ];
156
157 /// A dense index, so that one of these can select a slot in a fixed size array.
158 pub(crate) const fn index(self) -> usize {
159 match self {
160 IntKind::Char => 0,
161 IntKind::SChar => 1,
162 IntKind::UChar => 2,
163 IntKind::Short => 3,
164 IntKind::UShort => 4,
165 IntKind::Int => 5,
166 IntKind::UInt => 6,
167 IntKind::Long => 7,
168 IntKind::ULong => 8,
169 IntKind::LongLong => 9,
170 IntKind::ULongLong => 10,
171 IntKind::Int128 => 11,
172 IntKind::UInt128 => 12,
173 }
174 }
175
176 /// Whether this type is signed, given what the target says about plain `char`.
177 ///
178 /// The argument is there because `char` is the one integer type whose signedness is not
179 /// in the standard. It is signed on x86-64 and unsigned on AArch64 Linux, and a compiler
180 /// that assumes either one is the source of a whole genre of bug report.
181 #[must_use]
182 pub const fn is_signed(self, char_is_signed: bool) -> bool {
183 match self {
184 IntKind::Char => char_is_signed,
185 IntKind::SChar
186 | IntKind::Short
187 | IntKind::Int
188 | IntKind::Long
189 | IntKind::LongLong
190 | IntKind::Int128 => true,
191 IntKind::UChar
192 | IntKind::UShort
193 | IntKind::UInt
194 | IntKind::ULong
195 | IntKind::ULongLong
196 | IntKind::UInt128 => false,
197 }
198 }
199
200 /// The integer conversion rank, as an ordering rather than as a number from the standard.
201 ///
202 /// The standard gives no values, only a set of relations, and every one of them is a
203 /// comparison between two ranks. Signed and unsigned of the same width share a rank, which
204 /// is what makes the usual arithmetic conversions between them pick the unsigned type
205 /// rather than the wider one.
206 #[must_use]
207 pub const fn rank(self) -> u8 {
208 match self {
209 IntKind::Char | IntKind::SChar | IntKind::UChar => 1,
210 IntKind::Short | IntKind::UShort => 2,
211 IntKind::Int | IntKind::UInt => 3,
212 IntKind::Long | IntKind::ULong => 4,
213 IntKind::LongLong | IntKind::ULongLong => 5,
214 // Above `long long`, which is what makes `__int128 + unsigned long long` an
215 // `__int128` rather than an unsigned type. Both compilers agree.
216 IntKind::Int128 | IntKind::UInt128 => 6,
217 }
218 }
219
220 /// The same width with the other signedness.
221 ///
222 /// `char` maps to `unsigned char` and back to `signed char`, which is the mapping the
223 /// usual arithmetic conversions need and is not a round trip. That asymmetry is the type
224 /// system telling the truth: there is no way back to plain `char` from either of the
225 /// other two.
226 #[must_use]
227 pub const fn flip_sign(self) -> IntKind {
228 match self {
229 IntKind::Char | IntKind::SChar => IntKind::UChar,
230 IntKind::UChar => IntKind::SChar,
231 IntKind::Short => IntKind::UShort,
232 IntKind::UShort => IntKind::Short,
233 IntKind::Int => IntKind::UInt,
234 IntKind::UInt => IntKind::Int,
235 IntKind::Long => IntKind::ULong,
236 IntKind::ULong => IntKind::Long,
237 IntKind::LongLong => IntKind::ULongLong,
238 IntKind::ULongLong => IntKind::LongLong,
239 IntKind::Int128 => IntKind::UInt128,
240 IntKind::UInt128 => IntKind::Int128,
241 }
242 }
243
244 /// How the type is spelled in a diagnostic.
245 #[must_use]
246 pub const fn as_str(self) -> &'static str {
247 match self {
248 IntKind::Char => "char",
249 IntKind::SChar => "signed char",
250 IntKind::UChar => "unsigned char",
251 IntKind::Short => "short",
252 IntKind::UShort => "unsigned short",
253 IntKind::Int => "int",
254 IntKind::UInt => "unsigned int",
255 IntKind::Long => "long",
256 IntKind::ULong => "unsigned long",
257 IntKind::LongLong => "long long",
258 IntKind::ULongLong => "unsigned long long",
259 IntKind::Int128 => "__int128",
260 IntKind::UInt128 => "unsigned __int128",
261 }
262 }
263}
264
265/// The real floating types.
266///
267/// Nine of them, which is three standard ones and six from C23 Annex H. The interchange types
268/// `_Float16`, `_Float32`, `_Float64` and `_Float128` name an IEEE format outright, and the
269/// extended types `_Float32x` and `_Float64x` name whatever the target has that is wider than
270/// the interchange type they are named after, which makes `_Float64x` the x87 format on x86 and
271/// quad precision on AArch64. None of them is the standard type it shares a format with:
272/// `_Float64` and `double` are both binary64 and are two types, which `_Generic` can tell apart
273/// and which decides what `_Float64 + double` is.
274///
275/// `_Float128x` is a type no target gcc supports has, so it is not here. The three decimal
276/// floating types from C23 are, and they are real floating types like the others in every way
277/// except the one that matters most: a decimal and a binary type never meet in an operation, so
278/// the usual arithmetic conversions have no answer for the pair and the program is refused.
279#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
280pub enum FloatKind {
281 /// `_Float16`, always the binary16 format.
282 Float16,
283 /// `float`, always the binary32 format.
284 Float,
285 /// `_Float32`, always the binary32 format, and not the same type as `float`.
286 Float32,
287 /// `double`, always the binary64 format.
288 Double,
289 /// `_Float32x`, the format the target has that is wider than `_Float32`, which is binary64
290 /// everywhere this compiles for.
291 Float32x,
292 /// `_Float64`, always the binary64 format, and not the same type as `double`.
293 Float64,
294 /// `long double`, whose format is a target property and is not always distinct from
295 /// `double`. It is 80 bits of x87 on SysV x86-64, quad precision on AArch64 Linux, and
296 /// the same as `double` on Apple and Windows.
297 LongDouble,
298 /// `_Float64x`, the format the target has that is wider than `_Float64`. That is the x87
299 /// eighty bit format on x86-64 and quad precision on AArch64 and RISC-V, and unlike
300 /// `long double` it does not become a `double` on Apple or on Windows.
301 Float64x,
302 /// `_Float128`, always the binary128 format.
303 Float128,
304 /// `_Decimal32`, the decimal32 format in the binary integer encoding.
305 Decimal32,
306 /// `_Decimal64`, the decimal64 format in the binary integer encoding.
307 Decimal64,
308 /// `_Decimal128`, the decimal128 format in the binary integer encoding.
309 Decimal128,
310}
311
312impl FloatKind {
313 /// Every real floating type, in the order they are written above.
314 ///
315 /// Not in rank order, because there is no such order to put them in: which of `long double`
316 /// and `_Float64x` is the wider one is a question about the target, and on Apple the answer
317 /// is the second.
318 pub const ALL: [FloatKind; 12] = [
319 FloatKind::Float16,
320 FloatKind::Float,
321 FloatKind::Float32,
322 FloatKind::Double,
323 FloatKind::Float32x,
324 FloatKind::Float64,
325 FloatKind::LongDouble,
326 FloatKind::Float64x,
327 FloatKind::Float128,
328 FloatKind::Decimal32,
329 FloatKind::Decimal64,
330 FloatKind::Decimal128,
331 ];
332
333 /// A dense index, so that one of these can select a slot in a fixed size array.
334 pub(crate) const fn index(self) -> usize {
335 match self {
336 FloatKind::Float16 => 0,
337 FloatKind::Float => 1,
338 FloatKind::Float32 => 2,
339 FloatKind::Double => 3,
340 FloatKind::Float32x => 4,
341 FloatKind::Float64 => 5,
342 FloatKind::LongDouble => 6,
343 FloatKind::Float64x => 7,
344 FloatKind::Float128 => 8,
345 FloatKind::Decimal32 => 9,
346 FloatKind::Decimal64 => 10,
347 FloatKind::Decimal128 => 11,
348 }
349 }
350
351 /// Whether this is one of the three decimal types.
352 #[must_use]
353 pub const fn is_decimal(self) -> bool {
354 matches!(self, FloatKind::Decimal32 | FloatKind::Decimal64 | FloatKind::Decimal128)
355 }
356
357 /// What decides between two of these when they have the same format.
358 ///
359 /// Two real floating types can be the same format and still be two types, and then the
360 /// format cannot say which of them an operation on both of them produces. C23 answers with
361 /// the family first: an interchange type wins over the standard type it shares a format
362 /// with, and the standard type wins over an extended one, so `double + _Float64` is a
363 /// `_Float64` and `double + _Float32x` is a `double`. Inside a family it is the usual order,
364 /// which only ever comes up between `double` and `long double` on the targets where the
365 /// second one is the first one.
366 ///
367 /// Higher wins. This is not an ordering on the types on its own, because it says nothing
368 /// about the formats: `_Float32` sits above `long double` here and loses to it everywhere it
369 /// meets it.
370 #[must_use]
371 pub const fn tie_break(self) -> u8 {
372 match self {
373 FloatKind::Float32x => 0,
374 FloatKind::Float64x => 1,
375 FloatKind::Float => 4,
376 FloatKind::Double => 5,
377 FloatKind::LongDouble => 6,
378 FloatKind::Float16 => 8,
379 FloatKind::Float32 => 9,
380 FloatKind::Float64 => 10,
381 FloatKind::Float128 => 11,
382 // Never compared with a binary type, and each decimal is its own format, so these
383 // only have to be distinct.
384 FloatKind::Decimal32 => 12,
385 FloatKind::Decimal64 => 13,
386 FloatKind::Decimal128 => 14,
387 }
388 }
389
390 /// How the type is spelled in a diagnostic.
391 #[must_use]
392 pub const fn as_str(self) -> &'static str {
393 match self {
394 FloatKind::Float16 => "_Float16",
395 FloatKind::Float => "float",
396 FloatKind::Float32 => "_Float32",
397 FloatKind::Double => "double",
398 FloatKind::Float32x => "_Float32x",
399 FloatKind::Float64 => "_Float64",
400 FloatKind::LongDouble => "long double",
401 FloatKind::Float64x => "_Float64x",
402 FloatKind::Float128 => "_Float128",
403 FloatKind::Decimal32 => "_Decimal32",
404 FloatKind::Decimal64 => "_Decimal64",
405 FloatKind::Decimal128 => "_Decimal128",
406 }
407 }
408}
409
410/// How many elements an array has, which is four different answers in C.
411#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
412pub enum ArrayLen {
413 /// `int a[4]`. The count of elements, not the size in bytes.
414 Fixed(u64),
415 /// `int a[]`, an incomplete array type. It has an element type and no size, and it is
416 /// completed by an initializer or by a later declaration.
417 Unknown,
418 /// `int a[*]`, a variably modified type in a prototype, where the size exists but is not
419 /// available to the declaration that mentions it.
420 Star,
421 /// `int a[n]`, a variable length array. The size expression stays in the AST, and the
422 /// type carries only the identity of the one that made it, because two variable length
423 /// arrays written with the same element type are still distinct types.
424 Variable(VlaId),
425}
426
427/// The identity of one variable length array's size expression.
428///
429/// An opaque number handed out by whoever is building the type, which in practice is
430/// semantic analysis walking a declarator. This crate never looks inside it; it is here so
431/// that interning two variable length arrays does not accidentally make them the same type.
432#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
433pub struct VlaId(pub u32);
434
435/// Whether a record is a `struct` or a `union`.
436#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
437pub enum RecordKind {
438 /// `struct`, whose members are laid out one after another.
439 Struct,
440 /// `union`, whose members all start at offset zero.
441 Union,
442}
443
444impl RecordKind {
445 /// How the keyword is spelled in a diagnostic.
446 #[must_use]
447 pub const fn as_str(self) -> &'static str {
448 match self {
449 RecordKind::Struct => "struct",
450 RecordKind::Union => "union",
451 }
452 }
453}
454
455/// What a type is, with its qualifiers stripped off into [`Type::quals`].
456///
457/// This is `Copy` and sixteen bytes, which is what lets it be the interning key directly.
458/// Function types and record types are the two that carry a variable amount of information,
459/// and both of them are an index into a table this crate owns.
460#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
461pub enum TypeKind {
462 /// `void`.
463 Void,
464 /// `bool`, which C23 spells without an underscore and which is one byte with two values.
465 Bool,
466 /// One of the standard integer types.
467 Int(IntKind),
468 /// One of the real floating types.
469 Float(FloatKind),
470 /// `_Complex T`, holding the type of each half.
471 ///
472 /// `T` is a real floating type in C and may also be an integer one, which is a GNU
473 /// extension gcc has always had and which `_Complex int` is. The half's own type is held
474 /// rather than a floating kind, because the two spellings are the same type in every way
475 /// but what a half is, and a kind could only say the floating half of that.
476 Complex(TypeId),
477 /// `_BitInt(N)` and `unsigned _BitInt(N)`.
478 ///
479 /// A distinct kind rather than an integer type with a width, because these do not take
480 /// part in the integer promotions and folding them in with the standard types is how
481 /// that rule gets forgotten.
482 BitInt {
483 /// Whether the type is signed. A signed `_BitInt(1)` is legal and holds `0` and `-1`.
484 signed: bool,
485 /// The declared width in bits, which is what the standard calls `N`.
486 width: u32,
487 },
488 /// A pointer to the given type.
489 Pointer(TypeId),
490 /// `_Atomic(T)`, which is a type and not a qualifier. See [`Qualifiers`].
491 Atomic(TypeId),
492 /// An array of the given element type.
493 Array {
494 /// The element type.
495 elem: TypeId,
496 /// How many of them there are, which may be unknown.
497 len: ArrayLen,
498 },
499 /// A function type, whose parameter list is in this crate's side table.
500 Function(FunctionId),
501 /// A GNU vector type, `__attribute__((vector_size(n)))`.
502 Vector {
503 /// The element type, which must be a scalar.
504 elem: TypeId,
505 /// How many elements there are.
506 len: u32,
507 },
508 /// A `struct` or `union`, identified by its declaration rather than by its members.
509 Record(RecordId),
510 /// An `enum`, identified by its declaration.
511 Enum(EnumId),
512 /// A typedef name, which is sugar over whatever it was declared as.
513 ///
514 /// Every semantic decision reads [`Types::canonical`](crate::Types::canonical) and never
515 /// sees this; every diagnostic reads the type as written and sees nothing else, so the
516 /// error says `size_t` rather than `unsigned long`. Compilers that drop the sugar produce
517 /// messages nobody can act on, and compilers that decide on the sugar produce wrong
518 /// answers, and both are common.
519 Typedef {
520 /// The name, for printing.
521 name: Symbol,
522 /// What it was declared as.
523 underlying: TypeId,
524 /// What `__attribute__((aligned(n)))` on the typedef asked an object of it to be
525 /// aligned to, and [`None`] when it asked for nothing.
526 ///
527 /// The one thing a typedef changes about the type behind it, and the reason the
528 /// alignment is on this node rather than in a table beside it: two typedefs of one
529 /// underlying type that ask for different alignments are two types, so the alignment
530 /// has to be part of what the table interns them by.
531 ///
532 /// It is what the type is aligned to and not a floor on it. Written on a declaration
533 /// the attribute only ever raises, and written on a typedef GCC lets it lower as well,
534 /// so `typedef int L __attribute__((aligned(2)))` really is an `int` at a multiple of
535 /// two and `struct { char c; L x; }` really is six bytes.
536 align: Option<NonZeroU32>,
537 /// Whether `__attribute__((may_alias))` was written on the typedef.
538 ///
539 /// An access through a type that says this may read or write an object of any type, the
540 /// way an access through a character type may. It is on this node for the reason the
541 /// alignment is: `typedef int A __attribute__((may_alias))` and `int` are the same type to
542 /// everything but the alias analysis, and that has to be able to tell them apart.
543 may_alias: bool,
544 },
545}
546
547/// A type with its qualifiers, which together are one entry in the type table.
548#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
549pub struct Type {
550 /// What the type is.
551 pub kind: TypeKind,
552 /// What it is qualified with.
553 pub quals: Qualifiers,
554}
555
556impl Type {
557 /// An unqualified type of the given kind.
558 #[must_use]
559 pub const fn new(kind: TypeKind) -> Type {
560 Type { kind, quals: Qualifiers::NONE }
561 }
562}
563
564/// The identity of a function type in [`Types`](crate::Types).
565///
566/// Deduplicated by content, so two declarations written with the same return type, the same
567/// parameters and the same variadic flag share one of these and therefore one [`TypeId`].
568#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
569pub struct FunctionId(pub(crate) u32);
570
571/// The identity of a `struct` or `union` declaration in [`Types`](crate::Types).
572///
573/// Not deduplicated by content, because record types in C are nominal. Two `struct` types
574/// written with the same members in the same translation unit are different types, and the
575/// looser relation that does hold between them is compatibility rather than identity.
576#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
577pub struct RecordId(pub(crate) u32);
578
579/// The identity of an `enum` declaration in [`Types`](crate::Types).
580#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
581pub struct EnumId(pub(crate) u32);
582
583/// A function type.
584#[derive(Debug, Clone, PartialEq, Eq, Hash)]
585pub struct FunctionType {
586 /// What it returns.
587 pub ret: TypeId,
588 /// The parameter types, after the adjustments a parameter declaration gets: an array
589 /// parameter has already decayed to a pointer and a function parameter to a function
590 /// pointer, because those adjustments are part of forming the type and not part of
591 /// calling it.
592 pub params: Vec<TypeId>,
593 /// Whether the list ends in `...`.
594 pub variadic: bool,
595 /// Whether there was a prototype at all.
596 ///
597 /// `int f()` declares an unprototyped function before C23 and a function taking no
598 /// arguments from C23 onwards, and the difference is visible in what calls are checked
599 /// and in what the composite type of a redeclaration is. The dialect decides which
600 /// meaning `()` gets, and this records the decision rather than repeating it.
601 pub prototyped: bool,
602 /// Which calling convention a call to it and its own body use.
603 ///
604 /// Part of the type because gcc makes it part of the type: a pointer to an `ms_abi` function
605 /// and a pointer to an ordinary one are pointers to different types on Linux, and a function
606 /// declared once each way has conflicting types. [`Convention::Target`] is the target's own
607 /// whichever attribute named it, so `ms_abi` on Windows changes nothing about a type and
608 /// neither does `sysv_abi` anywhere else, and a type that never met an attribute is the same
609 /// type as one that met the attribute naming the target's convention.
610 pub convention: Convention,
611}