AttrDocTable.inc source code [llvm_projects/build/tools/clang/lib/AST/AttrDocTable.inc]

1	/===- TableGen'erated file -------------------------------------- C++ --===\
2	\| \|
3	\| Clang attribute documentation \|
4	\| \|
5	\| Automatically generated file, do not edit! \|
6	\| From: Attr.td \|
7	\| \|
8	\===----------------------------------------------------------------------===/
9
10
11	static const char AttrDoc_AArch64SVEPcs[] = R"reST(On AArch64 targets, this attribute changes the calling convention of a
12	function to preserve additional Scalable Vector registers and Scalable
13	Predicate registers relative to the default calling convention used for
14	AArch64.
15
16	This means it is more efficient to call such functions from code that performs
17	extensive scalable vector and scalable predicate calculations, because fewer
18	live SVE registers need to be saved. This property makes it well-suited for SVE
19	math library functions, which are typically leaf functions that require a small
20	number of registers.
21
22	However, using this attribute also means that it is more expensive to call
23	a function that adheres to the default calling convention from within such
24	a function. Therefore, it is recommended that this attribute is only used
25	for leaf functions.
26
27	For more information, see the documentation for `aarch64_sve_pcs` in the
28	ARM C Language Extension (ACLE) documentation.
29
30	[aarch64_sve_pcs]: https://github.com/ARM-software/acle/blob/main/main/acle.md#scalable-vector-extension-procedure-call-standard-attribute)reST";
31
32	static const char AttrDoc_AArch64VectorPcs[] = R"reST(On AArch64 targets, this attribute changes the calling convention of a
33	function to preserve additional floating-point and Advanced SIMD registers
34	relative to the default calling convention used for AArch64.
35
36	This means it is more efficient to call such functions from code that performs
37	extensive floating-point and vector calculations, because fewer live SIMD and FP
38	registers need to be saved. This property makes it well-suited for e.g.
39	floating-point or vector math library functions, which are typically leaf
40	functions that require a small number of registers.
41
42	However, using this attribute also means that it is more expensive to call
43	a function that adheres to the default calling convention from within such
44	a function. Therefore, it is recommended that this attribute is only used
45	for leaf functions.
46
47	For more information, see the documentation for [aarch64_vector_pcs][aarch64_vector_pcs] on
48	the Arm Developer website.
49
50	[aarch64_vector_pcs]: https://developer.arm.com/products/software-development-tools/hpc/arm-compiler-for-hpc/vector-function-abi)reST";
51
52	static const char AttrDoc_AMDGPUAvailableVisible[] = R"reST(This attribute controls availability and visibility as described in the [AMDGPU
53	Memory Model](https://llvm.org/docs/AMDGPUMemoryModel.html). When placed on
54	an atomic expression or fence, the resulting atomic or fence instruction carries
55	the corresponding AV Metadata.
56
57	The attribute takes a string literal as an argument, which currently has only
58	one supported value:
59
60	- `"none"`: Disable MakeAvailable and MakeVisible semantics on release and
61	acquire operations respectively.
62
63	```c++
64	[[clang::amdgpu_av("none")]] __atomic_thread_fence(__ATOMIC_SEQ_CST);
65	[[clang::amdgpu_av("none")]] __atomic_fetch_add(ptr, 1, __ATOMIC_ACQ_REL);
66
67	// Also works with _Atomic type qualifier operations.
68	_Atomic int *p;
69	[[clang::amdgpu_av("none")]] *p += 1;
70	```)reST";
71
72	static const char AttrDoc_AMDGPUFlatWorkGroupSize[] = R"reST(The flat work-group size is the number of work-items in the work-group size
73	specified when the kernel is dispatched. It is the product of the sizes of the
74	x, y, and z dimension of the work-group.
75
76	Clang supports the
77	`__attribute__((amdgpu_flat_work_group_size(<min>, <max>)))` attribute for the
78	AMDGPU target. This attribute may be attached to a kernel function definition
79	and is an optimization hint.
80
81	`<min>` parameter specifies the minimum flat work-group size, and `<max>`
82	parameter specifies the maximum flat work-group size (must be greater than
83	`<min>`) to which all dispatches of the kernel will conform. Passing `0, 0`
84	as `<min>, <max>` implies the default behavior (`128, 256`).
85
86	If specified, the AMDGPU target backend might be able to produce better machine
87	code for barriers and perform scratch promotion by estimating available group
88	segment size.
89
90	An error will be given if:
91	: - Specified values violate subtarget specifications;
92	- Specified values are not compatible with values provided through other
93	attributes.)reST";
94
95	static const char AttrDoc_AMDGPUMaxNumWorkGroups[] = R"reST(This attribute specifies the max number of work groups when the kernel
96	is dispatched.
97
98	Clang supports the
99	`__attribute__((amdgpu_max_num_work_groups(<x>, <y>, <z>)))` or
100	`[[clang::amdgpu_max_num_work_groups(<x>, <y>, <z>)]]` attribute for the
101	AMDGPU target. This attribute may be attached to HIP or OpenCL kernel function
102	definitions and is an optimization hint.
103
104	The `<x>` parameter specifies the maximum number of work groups in the x dimension.
105	Similarly `<y>` and `<z>` are for the y and z dimensions respectively.
106	Each of the three values must be greater than 0 when provided. The `<x>` parameter
107	is required, while `<y>` and `<z>` are optional with default value of 1.
108
109	If specified, the AMDGPU target backend might be able to produce better machine
110	code.
111
112	An error will be given if:
113	: - Specified values violate subtarget specifications;
114	- Specified values are not compatible with values provided through other
115	attributes.)reST";
116
117	static const char AttrDoc_AMDGPUNamedBarrierWrapper[] = R"reST()reST";
118
119	static const char AttrDoc_AMDGPUNumSGPR[] = R"reST(:::{warning}
120	These attributes are deprecated. Use the `amdgpu_waves_per_eu` attribute to
121	control SGPR and VGPR usage instead.
122	:::
123
124	Clang supports the `__attribute__((amdgpu_num_sgpr(<num_sgpr>)))` and
125	`__attribute__((amdgpu_num_vgpr(<num_vgpr>)))` attributes for the AMDGPU
126	target. These attributes may be attached to a kernel function definition and are
127	an optimization hint.
128
129	If these attributes are specified, then the AMDGPU target backend will attempt
130	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
131	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
132	allocation requirements or constraints of the subtarget. Passing `0` as
133	`num_sgpr` and/or `num_vgpr` implies the default behavior (no limits).
134
135	These attributes can be used to test the AMDGPU target backend. It is
136	recommended that the `amdgpu_waves_per_eu` attribute be used to control
137	resources such as SGPRs and VGPRs since it is aware of the limits for different
138	subtargets.
139
140	An error will be given if:
141	: - Specified values violate subtarget specifications;
142	- Specified values are not compatible with values provided through other
143	attributes;
144	- The AMDGPU target backend is unable to create machine code that can meet the
145	request.)reST";
146
147	static const char AttrDoc_AMDGPUNumVGPR[] = R"reST(:::{warning}
148	These attributes are deprecated. Use the `amdgpu_waves_per_eu` attribute to
149	control SGPR and VGPR usage instead.
150	:::
151
152	Clang supports the `__attribute__((amdgpu_num_sgpr(<num_sgpr>)))` and
153	`__attribute__((amdgpu_num_vgpr(<num_vgpr>)))` attributes for the AMDGPU
154	target. These attributes may be attached to a kernel function definition and are
155	an optimization hint.
156
157	If these attributes are specified, then the AMDGPU target backend will attempt
158	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
159	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
160	allocation requirements or constraints of the subtarget. Passing `0` as
161	`num_sgpr` and/or `num_vgpr` implies the default behavior (no limits).
162
163	These attributes can be used to test the AMDGPU target backend. It is
164	recommended that the `amdgpu_waves_per_eu` attribute be used to control
165	resources such as SGPRs and VGPRs since it is aware of the limits for different
166	subtargets.
167
168	An error will be given if:
169	: - Specified values violate subtarget specifications;
170	- Specified values are not compatible with values provided through other
171	attributes;
172	- The AMDGPU target backend is unable to create machine code that can meet the
173	request.)reST";
174
175	static const char AttrDoc_AMDGPUWavesPerEU[] = R"reST(A compute unit (CU) is responsible for executing the wavefronts of a work-group.
176	It is composed of one or more execution units (EU), which are responsible for
177	executing the wavefronts. An EU can have enough resources to maintain the state
178	of more than one executing wavefront. This allows an EU to hide latency by
179	switching between wavefronts in a similar way to symmetric multithreading on a
180	CPU. In order to allow the state for multiple wavefronts to fit on an EU, the
181	resources used by a single wavefront have to be limited. For example, the number
182	of SGPRs and VGPRs. Limiting such resources can allow greater latency hiding,
183	but can result in having to spill some register state to memory.
184
185	Clang supports the `__attribute__((amdgpu_waves_per_eu(<min>[, <max>])))`
186	attribute for the AMDGPU target. This attribute may be attached to a kernel
187	function definition and is an optimization hint.
188
189	`<min>` parameter specifies the requested minimum number of waves per EU, and
190	optional `<max>` parameter specifies the requested maximum number of waves
191	per EU (must be greater than `<min>` if specified). If `<max>` is omitted,
192	then there is no restriction on the maximum number of waves per EU other than
193	the one dictated by the hardware for which the kernel is compiled. Passing
194	`0, 0` as `<min>, <max>` implies the default behavior (no limits).
195
196	If specified, this attribute allows an advanced developer to tune the number of
197	wavefronts that are capable of fitting within the resources of an EU. The AMDGPU
198	target backend can use this information to limit resources, such as number of
199	SGPRs, number of VGPRs, size of available group and private memory segments, in
200	such a way that guarantees that at least `<min>` wavefronts and at most
201	`<max>` wavefronts are able to fit within the resources of an EU. Requesting
202	more wavefronts can hide memory latency but limits available registers which
203	can result in spilling. Requesting fewer wavefronts can help reduce cache
204	thrashing, but can reduce memory latency hiding.
205
206	This attribute controls the machine code generated by the AMDGPU target backend
207	to ensure it is capable of meeting the requested values. However, when the
208	kernel is executed, there may be other reasons that prevent meeting the request,
209	for example, there may be wavefronts from other kernels executing on the EU.
210
211	An error will be given if:
212	: - Specified values violate subtarget specifications;
213	- Specified values are not compatible with values provided through other
214	attributes;
215
216	The AMDGPU target backend will emit a warning whenever it is unable to
217	create machine code that meets the request.)reST";
218
219	static const char AttrDoc_ARMInterrupt[] = R"reST(Clang supports the GNU style `__attribute__((interrupt("TYPE")))` attribute on
220	ARM targets. This attribute may be attached to a function definition and
221	instructs the backend to generate appropriate function entry/exit code so that
222	it can be used directly as an interrupt service routine.
223
224	The parameter passed to the interrupt attribute is optional, but if
225	provided it must be a string literal with one of the following values: "IRQ",
226	"FIQ", "SWI", "ABORT", "UNDEF".
227
228	The semantics are as follows:
229
230	- If the function is AAPCS, Clang instructs the backend to realign the stack to
231	8 bytes on entry. This is a general requirement of the AAPCS at public
232	interfaces, but may not hold when an exception is taken. Doing this allows
233	other AAPCS functions to be called.
234
235	- If the CPU is M-class this is all that needs to be done since the architecture
236	itself is designed in such a way that functions obeying the normal AAPCS ABI
237	constraints are valid exception handlers.
238
239	- If the CPU is not M-class, the prologue and epilogue are modified to save all
240	non-banked registers that are used, so that upon return the user-mode state
241	will not be corrupted. Note that to avoid unnecessary overhead, only
242	general-purpose (integer) registers are saved in this way. If VFP operations
243	are needed, that state must be saved manually.
244
245	Specifically, interrupt kinds other than "FIQ" will save all core registers
246	except "lr" and "sp". "FIQ" interrupts will save r0-r7.
247
248	- If the CPU is not M-class, the return instruction is changed to one of the
249	canonical sequences permitted by the architecture for exception return. Where
250	possible the function itself will make the necessary "lr" adjustments so that
251	the "preferred return address" is selected.
252
253	Unfortunately the compiler is unable to make this guarantee for an "UNDEF"
254	handler, where the offset from "lr" to the preferred return address depends on
255	the execution state of the code which generated the exception. In this case
256	a sequence equivalent to "movs pc, lr" will be used.)reST";
257
258	static const char AttrDoc_ARMInterruptSaveFP[] = R"reST(Clang supports the GNU style `__attribute__((interrupt_save_fp("TYPE")))`
259	on ARM targets. This attribute behaves the same way as the ARM interrupt
260	attribute, except the general purpose floating point registers are also saved,
261	along with FPEXC and FPSCR. Note, even on M-class CPUs, where the floating
262	point context can be automatically saved depending on the FPCCR, the general
263	purpose floating point registers will be saved.)reST";
264
265	static const char AttrDoc_ARMSaveFP[] = R"reST()reST";
266
267	static const char AttrDoc_AVRInterrupt[] = R"reST(Clang supports the GNU style `__attribute__((interrupt))` attribute on
268	AVR targets. This attribute may be attached to a function definition and instructs
269	the backend to generate appropriate function entry/exit code so that it can be used
270	directly as an interrupt service routine.
271
272	On the AVR, the hardware globally disables interrupts when an interrupt is executed.
273	The first instruction of an interrupt handler declared with this attribute is a SEI
274	instruction to re-enable interrupts. See also the signal attribute that
275	does not insert a SEI instruction.)reST";
276
277	static const char AttrDoc_AVRSignal[] = R"reST(Clang supports the GNU style `__attribute__((signal))` attribute on
278	AVR targets. This attribute may be attached to a function definition and instructs
279	the backend to generate appropriate function entry/exit code so that it can be used
280	directly as an interrupt service routine.
281
282	Interrupt handler functions defined with the signal attribute do not re-enable interrupts.)reST";
283
284	static const char AttrDoc_AbiTag[] = R"reST(The `abi_tag` attribute can be applied to a function, variable, class or
285	inline namespace declaration to modify the mangled name of the entity. It gives
286	the ability to distinguish between different versions of the same entity but
287	with different ABI versions supported. For example, a newer version of a class
288	could have a different set of data members and thus have a different size. Using
289	the `abi_tag` attribute, it is possible to have different mangled names for
290	a global variable of the class type. Therefore, the old code could keep using
291	the old mangled name and the new code will use the new mangled name with tags.)reST";
292
293	static const char AttrDoc_AcquireCapability[] = R"reST(Marks a function as acquiring a capability.)reST";
294
295	static const char AttrDoc_AcquireHandle[] = R"reST(If this annotation is on a function or a function type it is assumed to return
296	a new handle. In case this annotation is on an output parameter,
297	the function is assumed to fill the corresponding argument with a new
298	handle. The attribute requires a string literal argument which used to
299	identify the handle with later uses of `use_handle` or
300	`release_handle`.
301
302	```c++
303	// Output arguments from Zircon.
304	zx_status_t zx_socket_create(uint32_t options,
305	zx_handle_t __attribute__((acquire_handle("zircon"))) * out0,
306	zx_handle_t* out1 [[clang::acquire_handle("zircon")]]);
307
308
309	// Returned handle.
310	[[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
311	int open(const char *path, int oflag, ... ) __attribute__((acquire_handle("tag")));
312	```)reST";
313
314	static const char AttrDoc_AcquiredAfter[] = R"reST(No documentation.)reST";
315
316	static const char AttrDoc_AcquiredBefore[] = R"reST(No documentation.)reST";
317
318	static const char AttrDoc_AddressSpace[] = R"reST(:::{Note}
319	This attribute is mainly intended to be used by target headers
320	provided by the toolchain. End users should prefer the documented, named
321	address space annotations for their platform, such as the
322	[OpenCL address spaces], `__global__`, `__local__`, or something else.
323	:::
324
325	The `address_space` attribute functions as a type qualifier that allows the
326	programmer to specify the address space for a pointer or reference type.
327	Qualified pointer types are considered distinct types for the purposes of
328	overload resolution. The attribute takes a single, non-negative integer
329	constant expression identifying the address space. For example:
330
331	```c
332	int * __attribute__((address_space(1))) ptr;
333
334	void foo(__attribute__((address_space(2))) float *buf);
335	```
336
337	Only one address space qualifier may be applied to a given pointer or reference
338	type. Where address spaces are allowed (e.g., variables, parameters, return
339	types) and what values are valid depends on the target and language mode.
340
341	The meaning of each value is defined by the target; multiple address spaces are
342	used in environments such as OpenCL, CUDA, HIP, and other GPU programming
343	models to distinguish global, local, constant, and private memory. See for
344	example the address spaces defined in the [NVPTX Usage Guide][nvptx usage guide] and the
345	[AMDGPU Usage Guide][amdgpu usage guide].
346
347	Address spaces may partially overlap or be entirely distinct. The compiler may
348	reject attempts to convert between distinct, incompatible address spaces.
349	Pointer width may vary between different address spaces, so some explicit casts
350	may truncate.
351
352	For more information, refer to [ISO TR18037][iso tr18037], which covers embedded C language
353	extensions. Section 5 covers named address spaces.
354
355	[amdgpu usage guide]: https://llvm.org/docs/AMDGPUUsage.html#address-spaces
356	[iso tr18037]: https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip
357	[nvptx usage guide]: https://llvm.org/docs/NVPTXUsage.html#address-spaces)reST";
358
359	static const char AttrDoc_Alias[] = R"reST(No documentation.)reST";
360
361	static const char AttrDoc_AlignMac68k[] = R"reST()reST";
362
363	static const char AttrDoc_AlignNatural[] = R"reST()reST";
364
365	static const char AttrDoc_AlignValue[] = R"reST(The align_value attribute can be added to the typedef of a pointer type or the
366	declaration of a variable of pointer or reference type. It specifies that the
367	pointer will point to, or the reference will bind to, only objects with at
368	least the provided alignment. This alignment value must be some positive power
369	of 2.
370
371	```c
372	typedef double * aligned_double_ptr __attribute__((align_value(64)));
373	void foo(double & x __attribute__((align_value(128))),
374	aligned_double_ptr y) { ... }
375	```
376
377	If the pointer value does not have the specified alignment at runtime, the
378	behavior of the program is undefined.)reST";
379
380	static const char AttrDoc_Aligned[] = R"reST(No documentation.)reST";
381
382	static const char AttrDoc_AllocAlign[] = R"reST(Use `__attribute__((alloc_align(<parameter-index>)))` on a declaration with a
383	function prototype to specify that the prototype's return value (which must be a
384	pointer type) is at least as aligned as the value of the indicated parameter.
385	This includes functions, Objective-C methods, blocks, and declarations of
386	function pointer, member function pointer, function reference, and block pointer
387	types. The attribute can also be applied to typedef or type alias declarations
388	whose underlying type has a function prototype.
389
390	The parameter is given by its index in the list of formal parameters; the first
391	parameter has index 1 unless the function is a C++ non-static member function,
392	in which case the first parameter has index 2 to account for the implicit `this`
393	parameter.
394
395	```c++
396	// The returned pointer has the alignment specified by the first parameter.
397	void *a(size_t align) __attribute__((alloc_align(1)));
398
399	// The function pointer's returned pointer has the alignment specified by
400	// the first parameter of the pointed-to function.
401	void (allocator)(size_t align) __attribute__((alloc_align(1)));
402
403	// The returned pointer has the alignment specified by the second parameter.
404	void b(void v, size_t align) __attribute__((alloc_align(2)));
405
406	// The returned pointer has the alignment specified by the second visible
407	// parameter, however it must be adjusted for the implicit 'this' parameter.
408	void Foo::b(void v, size_t align) __attribute__((alloc_align(3)));
409	```
410
411	Note that this attribute merely informs the compiler that a function always
412	returns a sufficiently aligned pointer. It does not cause the compiler to
413	emit code to enforce that alignment. The behavior is undefined if the returned
414	pointer is not sufficiently aligned.)reST";
415
416	static const char AttrDoc_AllocSize[] = R"reST(The `alloc_size` attribute can be placed on functions that return pointers in
417	order to hint to the compiler how many bytes of memory will be available at the
418	returned pointer. `alloc_size` takes one or two arguments.
419
420	- `alloc_size(N)` implies that argument number N equals the number of
421	available bytes at the returned pointer.
422	- `alloc_size(N, M)` implies that the product of argument number N and
423	argument number M equals the number of available bytes at the returned
424	pointer.
425
426	Argument numbers are 1-based.
427
428	An example of how to use `alloc_size`
429
430	```c
431	void *my_malloc(int a) __attribute__((alloc_size(1)));
432	void *my_calloc(int a, int b) __attribute__((alloc_size(1, 2)));
433
434	int main() {
435	void *const p = my_malloc(100);
436	assert(__builtin_object_size(p, 0) == 100);
437	void *const a = my_calloc(20, 5);
438	assert(__builtin_object_size(a, 0) == 100);
439	}
440	```
441
442	When `-Walloc-size` is enabled, this attribute allows the compiler to
443	diagnose cases when the allocated memory is insufficient for the size of the
444	type the returned pointer is cast to.
445
446	```c
447	void *my_malloc(int a) __attribute__((alloc_size(1)));
448	void consumer_func(int *);
449
450	int main() {
451	int *ptr = my_malloc(sizeof(int)); // no warning
452	int *w = my_malloc(1); // warning: allocation of insufficient size '1' for type 'int' with size '4'
453	consumer_func(my_malloc(1)); // warning: allocation of insufficient size '1' for type 'int' with size '4'
454	}
455	```
456
457	:::{Note}
458	This attribute works differently in clang than it does in GCC.
459	Specifically, clang will only trace `const` pointers (as above); we give up
460	on pointers that are not marked as `const`. In the vast majority of cases,
461	this is unimportant, because LLVM has support for the `alloc_size`
462	attribute. However, this may cause mildly unintuitive behavior when used with
463	other attributes, such as `enable_if`.
464	:::)reST";
465
466	static const char AttrDoc_Allocating[] = R"reST(Declares that a function potentially allocates heap memory, and prevents any potential inference
467	of `nonallocating` by the compiler.)reST";
468
469	static const char AttrDoc_AlwaysDestroy[] = R"reST(The `always_destroy` attribute specifies that a variable with static or thread
470	storage duration should have its exit-time destructor run. This attribute is the
471	default unless clang was invoked with -fno-c++-static-destructors.
472
473	If a variable is explicitly declared with this attribute, Clang will silence
474	otherwise applicable `-Wexit-time-destructors` warnings.)reST";
475
476	static const char AttrDoc_AlwaysInline[] = R"reST(Inlining heuristics are disabled and inlining is always attempted regardless of
477	optimization level.
478
479	`[[clang::always_inline]]` spelling can be used as a statement attribute; other
480	spellings of the attribute are not supported on statements. If a statement is
481	marked `[[clang::always_inline]]` and contains calls, the compiler attempts
482	to inline those calls.
483
484	```c
485	int example(void) {
486	int i;
487	[[clang::always_inline]] foo(); // attempts to inline foo
488	[[clang::always_inline]] i = bar(); // attempts to inline bar
489	[[clang::always_inline]] return f(42, baz(bar())); // attempts to inline everything
490	}
491	```
492
493	A declaration statement, which is a statement, is not a statement that can have an
494	attribute associated with it (the attribute applies to the declaration, not the
495	statement in that case). So this use case will not work:
496
497	```c
498	int example(void) {
499	[[clang::always_inline]] int i = bar();
500	return i;
501	}
502	```
503
504	This attribute does not guarantee that inline substitution actually occurs.
505
506	\<ins>Note: applying this attribute to a coroutine at the `-O0` optimization level
507	has no effect; other optimization levels may only partially inline and result in a
508	diagnostic.\</ins>
509
510	See also [the Microsoft Docs on Inline Functions][the microsoft docs on inline functions], [the GCC Common Function
511	Attribute docs][the gcc common function attribute docs], and [the GCC Inline docs][the gcc inline docs].
512
513	[the gcc common function attribute docs]: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
514	[the gcc inline docs]: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
515	[the microsoft docs on inline functions]: https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp)reST";
516
517	static const char AttrDoc_AnalyzerNoReturn[] = R"reST(No documentation.)reST";
518
519	static const char AttrDoc_Annotate[] = R"reST(The `annotate` attribute is used to add annotations to declarations or statements,
520	typically for use by static analysis tools that are not integrated into the
521	core Clang compiler (e.g., Clang-Tidy checks or out-of-tree Clang-based tools).
522	It is a counterpart to the `annotate_type` attribute, which serves the same
523	purpose, but for types.
524
525	The attribute takes a mandatory string literal argument specifying the
526	annotation category and an arbitrary number of optional arguments that provide
527	additional information specific to the annotation category. The optional
528	arguments must be constant expressions of arbitrary type.
529
530	For example:
531
532	```c++
533	[[clang::annotate("category1", "foo", 1)]] void func(int val [[clang::annotate("category2")]]) {
534	[[clang::annotate("category3")]] if (val) {
535
536	}
537	}
538	```)reST";
539
540	static const char AttrDoc_AnnotateType[] = R"reST(This attribute is used to add annotations to types, typically for use by static
541	analysis tools that are not integrated into the core Clang compiler (e.g.,
542	Clang-Tidy checks or out-of-tree Clang-based tools). It is a counterpart to the
543	`annotate` attribute, which serves the same purpose, but for declarations.
544
545	The attribute takes a mandatory string literal argument specifying the
546	annotation category and an arbitrary number of optional arguments that provide
547	additional information specific to the annotation category. The optional
548	arguments must be constant expressions of arbitrary type.
549
550	For example:
551
552	```c++
553	int* [[clang::annotate_type("category1", "foo", 1)]] f(int[[clang::annotate_type("category2")]] *);
554	```
555
556	The attribute does not have any effect on the semantics of the type system,
557	neither type checking rules, nor runtime semantics. In particular:
558
559	- `std::is_same<T, T [[clang::annotate_type("foo")]]>` is true for all types
560	`T`.
561	- It is not permissible for overloaded functions or template specializations
562	to differ merely by an `annotate_type` attribute.
563	- The presence of an `annotate_type` attribute will not affect name
564	mangling.)reST";
565
566	static const char AttrDoc_AnyX86Interrupt[] = R"reST(Clang supports the GNU style `__attribute__((interrupt))` attribute on X86
567	targets. This attribute may be attached to a function definition and instructs
568	the backend to generate appropriate function entry/exit code so that it can be
569	used directly as an interrupt service routine.
570
571	Interrupt handlers have access to the stack frame pushed onto the stack by the processor,
572	and return using the `IRET` instruction. All registers in an interrupt handler are callee-saved.
573	Exception handlers also have access to the error code pushed onto the stack by the processor,
574	when applicable.
575
576	An interrupt handler must take the following arguments:
577
578	```c
579	__attribute__ ((interrupt))
580	void f (struct stack_frame *frame) {
581	...
582	}
583	```
584
585	Where `struct stack_frame` is a suitable struct matching the stack frame pushed
586	by the processor.
587
588	An exception handler must take the following arguments:
589
590	```c
591	__attribute__ ((interrupt))
592	void g (struct stack_frame *frame, unsigned long code) {
593	...
594	}
595	```
596
597	On 32-bit targets, the `code` argument should be of type `unsigned int`.
598
599	Exception handlers should only be used when an error code is pushed by the processor.
600	Using the incorrect handler type will crash the system.
601
602	Interrupt and exception handlers cannot be called by other functions and must have return type `void`.
603
604	Interrupt and exception handlers should only call functions with the 'no_caller_saved_registers'
605	attribute, or should be compiled with the '-mgeneral-regs-only' flag to avoid saving unused
606	non-GPR registers.)reST";
607
608	static const char AttrDoc_AnyX86NoCallerSavedRegisters[] = R"reST(Use this attribute to indicate that the specified function has no
609	caller-saved registers. That is, all registers are callee-saved except for
610	registers used for passing parameters to the function or returning parameters
611	from the function.
612	The compiler saves and restores any modified registers that were not used for
613	passing or returning arguments to the function.
614
615	The user can call functions specified with the 'no_caller_saved_registers'
616	attribute from an interrupt handler without saving and restoring all
617	call-clobbered registers.
618
619	Functions specified with the 'no_caller_saved_registers' attribute should only
620	call other functions with the 'no_caller_saved_registers' attribute, or should be
621	compiled with the '-mgeneral-regs-only' flag to avoid saving unused non-GPR registers.
622
623	Note that 'no_caller_saved_registers' attribute is not a calling convention.
624	In fact, it only overrides the decision of which registers should be saved by
625	the caller, but not how the parameters are passed from the caller to the callee.
626
627	For example:
628
629	```c
630	__attribute__ ((no_caller_saved_registers, fastcall))
631	void f (int arg1, int arg2) {
632	...
633	}
634	```
635
636	In this case parameters 'arg1' and 'arg2' will be passed in registers.
637	In this case, on 32-bit x86 targets, the function 'f' will use ECX and EDX as
638	register parameters. However, it will not assume any scratch registers and
639	should save and restore any modified registers except for ECX and EDX.)reST";
640
641	static const char AttrDoc_AnyX86NoCfCheck[] = R"reST(Jump Oriented Programming attacks rely on tampering with addresses used by
642	indirect call / jmp, e.g. redirect control-flow to non-programmer
643	intended bytes in the binary.
644	X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow
645	Enforcement Technology (CET). IBT instruments ENDBR instructions used to
646	specify valid targets of indirect call / jmp.
647	The `nocf_check` attribute has two roles:
648	1\. Appertains to a function - do not add ENDBR instruction at the beginning of
649	the function.
650	2\. Appertains to a function pointer - do not track the target function of this
651	pointer (by adding nocf_check prefix to the indirect-call instruction).)reST";
652
653	static const char AttrDoc_ArcWeakrefUnavailable[] = R"reST(No documentation.)reST";
654
655	static const char AttrDoc_ArgumentWithTypeTag[] = R"reST(Use `__attribute__((argument_with_type_tag(arg_kind, arg_idx,
656	type_tag_idx)))` on a function declaration to specify that the function
657	accepts a type tag that determines the type of some other argument.
658
659	This attribute is primarily useful for checking arguments of variadic functions
660	(`pointer_with_type_tag` can be used in most non-variadic cases).
661
662	In the attribute prototype above:
663	: - `arg_kind` is an identifier that should be used when annotating all
664	applicable type tags.
665	- `arg_idx` provides the position of a function argument. The expected type of
666	this function argument will be determined by the function argument specified
667	by `type_tag_idx`. In the code example below, "3" means that the type of the
668	function's third argument will be determined by `type_tag_idx`.
669	- `type_tag_idx` provides the position of a function argument. This function
670	argument will be a type tag. The type tag will determine the expected type of
671	the argument specified by `arg_idx`. In the code example below, "2" means
672	that the type tag associated with the function's second argument should agree
673	with the type of the argument specified by `arg_idx`.
674
675	For example:
676
677	```c++
678	int fcntl(int fd, int cmd, ...)
679	__attribute__(( argument_with_type_tag(fcntl,3,2) ));
680	// The function's second argument will be a type tag; this type tag will
681	// determine the expected type of the function's third argument.
682	```)reST";
683
684	static const char AttrDoc_ArmAgnostic[] = R"reST(The `__arm_agnostic` keyword applies to prototyped function types and
685	affects the function's calling convention for a given state S. This
686	attribute allows the user to describe a function that preserves S, without
687	requiring the function to share S with its callers and without making
688	the assumption that S exists.
689
690	If a function has the `__arm_agnostic(S)` attribute and calls a function
691	without this attribute, then the function's object code will contain code
692	to preserve state S. Otherwise, the function's object code will be the same
693	as if it did not have the attribute.
694
695	The attribute takes string arguments to describe state S. The supported
696	states are:
697
698	- `"sme_za_state"` for state enabled by PSTATE.ZA, such as ZA and ZT0.
699
700	The attribute `__arm_agnostic("sme_za_state")` cannot be used in conjunction
701	with `__arm_in(S)`, `__arm_out(S)`, `__arm_inout(S)` or
702	`__arm_preserves(S)` where state S describes state enabled by PSTATE.ZA,
703	such as "za" or "zt0".)reST";
704
705	static const char AttrDoc_ArmBuiltinAlias[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics.
706	It allows the intrinsic functions to
707	be declared using the names defined in ACLE, and still be recognized
708	as clang builtins equivalent to the underlying name. For example,
709	`arm_mve.h` declares the function `vaddq_u32` with
710	`__attribute__((__clang_arm_mve_alias(__builtin_arm_mve_vaddq_u32)))`,
711	and similarly, one of the type-overloaded declarations of `vaddq`
712	will have the same attribute. This ensures that both functions are
713	recognized as that clang builtin, and in the latter case, the choice
714	of which builtin to identify the function as can be deferred until
715	after overload resolution.
716
717	This attribute can only be used to set up the aliases for certain Arm
718	intrinsic functions; it is intended for use only inside `arm_*.h`
719	and is not a general mechanism for declaring arbitrary aliases for
720	clang builtin functions.
721
722	In order to avoid duplicating the attribute definitions for similar
723	purpose for other architecture, there is a general form for the
724	attribute `clang_builtin_alias`.)reST";
725
726	static const char AttrDoc_ArmIn[] = R"reST(The `__arm_in` keyword applies to prototyped function types and specifies
727	that the function shares a given state S with its caller. For `__arm_in`, the
728	function takes the state S as input and returns with the state S unchanged.
729
730	The attribute takes string arguments to instruct the compiler which state
731	is shared. The supported states for S are:
732
733	- `"za"` for Matrix Storage (requires SME)
734
735	The attributes `__arm_in(S)`, `__arm_out(S)`, `__arm_inout(S)` and
736	`__arm_preserves(S)` are all mutually exclusive for the same state S.)reST";
737
738	static const char AttrDoc_ArmInOut[] = R"reST(The `__arm_inout` keyword applies to prototyped function types and specifies
739	that the function shares a given state S with its caller. For `__arm_inout`,
740	the function takes the state S as input and returns new state for S.
741
742	The attribute takes string arguments to instruct the compiler which state
743	is shared. The supported states for S are:
744
745	- `"za"` for Matrix Storage (requires SME)
746
747	The attributes `__arm_in(S)`, `__arm_out(S)`, `__arm_inout(S)` and
748	`__arm_preserves(S)` are all mutually exclusive for the same state S.)reST";
749
750	static const char AttrDoc_ArmLocallyStreaming[] = R"reST(The `__arm_locally_streaming` keyword applies to function declarations
751	and specifies that all the statements in the function are executed in
752	streaming mode. This means that:
753
754	- the function requires that the target processor implements the Scalable Matrix
755	Extension (SME).
756	- the program automatically puts the machine into streaming mode before
757	executing the statements and automatically restores the previous mode
758	afterwards.
759
760	Clang manages PSTATE.SM automatically; it is not the source code's
761	responsibility to do this. For example, Clang will emit code to enable
762	streaming mode at the start of the function, and disable streaming mode
763	at the end of the function.)reST";
764
765	static const char AttrDoc_ArmMveStrictPolymorphism[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics for the Arm
766	MVE instruction set. It is used to define the vector types used by the MVE
767	intrinsics.
768
769	Its effect is to modify the behavior of a vector type with respect to function
770	overloading. If a candidate function for overload resolution has a parameter
771	type with this attribute, then the selection of that candidate function will be
772	disallowed if the actual argument can only be converted via a lax vector
773	conversion. The aim is to prevent spurious ambiguity in ARM MVE polymorphic
774	intrinsics.
775
776	```c++
777	void overloaded(uint16x8_t vector, uint16_t scalar);
778	void overloaded(int32x4_t vector, int32_t scalar);
779	uint16x8_t myVector;
780	uint16_t myScalar;
781
782	// myScalar is promoted to int32_t as a side effect of the addition,
783	// so if lax vector conversions are considered for myVector, then
784	// the two overloads are equally good (one argument conversion
785	// each). But if the vector has the __clang_arm_mve_strict_polymorphism
786	// attribute, only the uint16x8_t,uint16_t overload will match.
787	overloaded(myVector, myScalar + 1);
788	```
789
790	However, this attribute does not prohibit lax vector conversions in contexts
791	other than overloading.
792
793	```c++
794	uint16x8_t function();
795
796	// This is still permitted with lax vector conversion enabled, even
797	// if the vector types have __clang_arm_mve_strict_polymorphism
798	int32x4_t result = function();
799	```)reST";
800
801	static const char AttrDoc_ArmNew[] = R"reST(The `__arm_new` keyword applies to function declarations and specifies
802	that the function will create a new scope for state S.
803
804	The attribute takes string arguments to instruct the compiler for which state
805	to create new scope. The supported states for S are:
806
807	- `"za"` for Matrix Storage (requires SME)
808
809	For state `"za"`, this means that:
810
811	- the function requires that the target processor implements the Scalable Matrix
812	Extension (SME).
813	- the function will commit any lazily saved ZA data.
814	- the function will create a new ZA context and enable PSTATE.ZA.
815	- the function will disable PSTATE.ZA (by setting it to 0) before returning.
816
817	For `__arm_new("za")` functions Clang will set up the ZA context automatically
818	on entry to the function and disable it before returning. For example, if ZA is
819	in a dormant state Clang will generate the code to commit a lazy-save and set up
820	a new ZA state before executing user code.)reST";
821
822	static const char AttrDoc_ArmOut[] = R"reST(The `__arm_out` keyword applies to prototyped function types and specifies
823	that the function shares a given state S with its caller. For `__arm_out`,
824	the function ignores the incoming state for S and returns new state for S.
825
826	The attribute takes string arguments to instruct the compiler which state
827	is shared. The supported states for S are:
828
829	- `"za"` for Matrix Storage (requires SME)
830
831	The attributes `__arm_in(S)`, `__arm_out(S)`, `__arm_inout(S)` and
832	`__arm_preserves(S)` are all mutually exclusive for the same state S.)reST";
833
834	static const char AttrDoc_ArmPreserves[] = R"reST(The `__arm_preserves` keyword applies to prototyped function types and
835	specifies that the function does not read a given state S and returns
836	with state S unchanged.
837
838	The attribute takes string arguments to instruct the compiler which state
839	is shared. The supported states for S are:
840
841	- `"za"` for Matrix Storage (requires SME)
842
843	The attributes `__arm_in(S)`, `__arm_out(S)`, `__arm_inout(S)` and
844	`__arm_preserves(S)` are all mutually exclusive for the same state S.)reST";
845
846	static const char AttrDoc_ArmStreaming[] = R"reST(The `__arm_streaming` keyword applies to prototyped function types and specifies
847	that the function has a "streaming interface". This means that:
848
849	- the function requires that the processor implements the Scalable Matrix
850	Extension (SME).
851	- the function must be entered in streaming mode (that is, with PSTATE.SM
852	set to 1)
853	- the function must return in streaming mode
854
855	Clang manages PSTATE.SM automatically; it is not the source code's
856	responsibility to do this. For example, if a non-streaming
857	function calls an `__arm_streaming` function, Clang generates code
858	that switches into streaming mode before calling the function and
859	switches back to non-streaming mode on return.)reST";
860
861	static const char AttrDoc_ArmStreamingCompatible[] = R"reST(The `__arm_streaming_compatible` keyword applies to prototyped function types and
862	specifies that the function has a "streaming compatible interface". This
863	means that:
864
865	- the function may be entered in either non-streaming mode (PSTATE.SM=0) or
866	in streaming mode (PSTATE.SM=1).
867	- the function must return in the same mode as it was entered.
868	- the code executed in the function is compatible with either mode.
869
870	Clang manages PSTATE.SM automatically; it is not the source code's
871	responsibility to do this. Clang will ensure that the generated code in
872	streaming-compatible functions is valid in either mode (PSTATE.SM=0 or
873	PSTATE.SM=1). For example, if an `__arm_streaming_compatible` function calls a
874	non-streaming function, Clang generates code to temporarily switch out of streaming
875	mode before calling the function and switch back to streaming-mode on return if
876	`PSTATE.SM` is `1` on entry of the caller. If `PSTATE.SM` is `0` on
877	entry to the `__arm_streaming_compatible` function, the call will be executed
878	without changing modes.)reST";
879
880	static const char AttrDoc_Artificial[] = R"reST(The `artificial` attribute can be applied to an inline function. If such a
881	function is inlined, the attribute indicates that debuggers should associate
882	the resulting instructions with the call site, rather than with the
883	corresponding line within the inlined callee.)reST";
884
885	static const char AttrDoc_AsmLabel[] = R"reST(This attribute can be used on a function or variable to specify its symbol name.
886
887	On some targets, all C symbols are prefixed by default with a single character,
888	typically `_`. This was done historically to distinguish them from symbols
889	used by other languages. (This prefix is also added to the standard Itanium
890	C++ ABI prefix on "mangled" symbol names, so that e.g. on such targets the true
891	symbol name for a C++ variable declared as `int cppvar;` would be
892	`__Z6cppvar`; note the two underscores.) This prefix is not added to the
893	symbol names specified by the `__asm` attribute; programmers wishing to match
894	a C symbol name must compensate for this.
895
896	For example, consider the following C code:
897
898	```c
899	int var1 __asm("altvar") = 1; // "altvar" in symbol table.
900	int var2 = 1; // "_var2" in symbol table.
901
902	void func1(void) __asm("altfunc");
903	void func1(void) {} // "altfunc" in symbol table.
904	void func2(void) {} // "_func2" in symbol table.
905	```
906
907	Clang's implementation of this attribute is compatible with GCC's, [documented here](https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html).
908
909	While it is possible to use this attribute to name a special symbol used
910	internally by the compiler, such as an LLVM intrinsic, this is neither
911	recommended nor supported and may cause the compiler to crash or miscompile.
912	Users who wish to gain access to intrinsic behavior are strongly encouraged to
913	request new builtin functions.)reST";
914
915	static const char AttrDoc_AssertCapability[] = R"reST(Marks a function that dynamically tests whether a capability is held, and halts
916	the program if it is not held.)reST";
917
918	static const char AttrDoc_AssumeAligned[] = R"reST(Use `__attribute__((assume_aligned(<alignment>[,<offset>]))` on a function
919	declaration to specify that the return value of the function (which must be a
920	pointer type) has the specified offset, in bytes, from an address with the
921	specified alignment. The offset is taken to be zero if omitted.
922
923	```c++
924	// The returned pointer value has 32-byte alignment.
925	void *a() __attribute__((assume_aligned (32)));
926
927	// The returned pointer value is 4 bytes greater than an address having
928	// 32-byte alignment.
929	void *b() __attribute__((assume_aligned (32, 4)));
930	```
931
932	Note that this attribute provides information to the compiler regarding a
933	condition that the code already ensures is true. It does not cause the compiler
934	to enforce the provided alignment assumption.)reST";
935
936	static const char AttrDoc_Atomic[] = R"reST(The `atomic` attribute can be applied to compound statements to override or
937	further specify the default atomic code-generation behavior, especially on
938	targets such as AMDGPU. You can annotate compound statements with options
939	to modify how atomic instructions inside that statement are emitted at the IR
940	level.
941
942	For details, see the documentation for
943	{ref}`@atomic <langext-atomic-code-generation>`)reST";
944
945	static const char AttrDoc_Availability[] = R"reST(The `availability` attribute can be placed on declarations to describe the
946	lifecycle of that declaration relative to operating system versions. Consider
947	the function declaration for a hypothetical function `f`:
948
949	```c++
950	void f(void) __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
951	```
952
953	The availability attribute states that `f` was introduced in macOS 10.4,
954	deprecated in macOS 10.6, and obsoleted in macOS 10.7. This information
955	is used by Clang to determine when it is safe to use `f`: for example, if
956	Clang is instructed to compile code for macOS 10.5, a call to `f()`
957	succeeds. If Clang is instructed to compile code for macOS 10.6, the call
958	succeeds but Clang emits a warning specifying that the function is deprecated.
959	Finally, if Clang is instructed to compile code for macOS 10.7, the call
960	fails because `f()` is no longer available.
961
962	Clang is instructed to compile code for a minimum deployment version using
963	the `-target` or `-mtargetos` command line arguments. For example,
964	macOS 10.7 would be specified as `-target x86_64-apple-macos10.7` or
965	`-mtargetos=macos10.7`. Variants like Mac Catalyst are specified as
966	`-target arm64-apple-ios15.0-macabi` or `-mtargetos=ios15.0-macabi`
967
968	The availability attribute is a comma-separated list starting with the
969	platform name and then including clauses specifying important milestones in the
970	declaration's lifetime (in any order) along with additional information. Those
971	clauses can be:
972
973	introduced=version
974
975	: The first version in which this declaration was introduced.
976
977	deprecated=version
978
979	: The first version in which this declaration was deprecated, meaning that
980	users should migrate away from this API.
981
982	obsoleted=version
983
984	: The first version in which this declaration was obsoleted, meaning that it
985	was removed completely and can no longer be used.
986
987	unavailable
988
989	: This declaration is never available on this platform.
990
991	message=string-literal
992
993	: Additional message text that Clang will provide when emitting a warning or
994	error about use of a deprecated or obsoleted declaration. Useful to direct
995	users to replacement APIs.
996
997	replacement=string-literal
998
999	: Additional message text that Clang will use to provide Fix-It when emitting
1000	a warning about use of a deprecated declaration. The Fix-It will replace
1001	the deprecated declaration with the new declaration specified.
1002
1003	environment=identifier
1004
1005	: Target environment in which this declaration is available. If present,
1006	the availability attribute applies only to targets with the same platform
1007	and environment. The parameter is currently supported only in HLSL.
1008
1009	Multiple availability attributes can be placed on a declaration, which may
1010	correspond to different platforms. For most platforms, the availability
1011	attribute with the platform corresponding to the target platform will be used;
1012	any others will be ignored. However, the availability for `watchOS` and
1013	`tvOS` can be implicitly inferred from an `iOS` availability attribute.
1014	Any explicit availability attributes for those platforms are still preferred over
1015	the implicitly inferred availability attributes. If no availability attribute
1016	specifies availability for the current target platform, the availability
1017	attributes are ignored. Supported platforms are:
1018
1019	`iOS`
1020	`macOS`
1021	`tvOS`
1022	`watchOS`
1023	`iOSApplicationExtension`
1024	`macOSApplicationExtension`
1025	`tvOSApplicationExtension`
1026	`watchOSApplicationExtension`
1027	`macCatalyst`
1028	`macCatalystApplicationExtension`
1029	`visionOS`
1030	`visionOSApplicationExtension`
1031	`driverkit`
1032	`anyAppleOS`
1033	`swift`
1034	`android`
1035	`fuchsia`
1036	`ohos`
1037	`zos`
1038	`ShaderModel`
1039
1040	Some platforms have alias names:
1041
1042	`ios`
1043	`macos`
1044	`macosx (deprecated)`
1045	`tvos`
1046	`watchos`
1047	`ios_app_extension`
1048	`macos_app_extension`
1049	`macosx_app_extension (deprecated)`
1050	`tvos_app_extension`
1051	`watchos_app_extension`
1052	`maccatalyst`
1053	`maccatalyst_app_extension`
1054	`visionos`
1055	`visionos_app_extension`
1056	`anyappleos`
1057	`shadermodel`
1058
1059	Supported environment names for the ShaderModel platform:
1060
1061	`pixel`
1062	`vertex`
1063	`geometry`
1064	`hull`
1065	`domain`
1066	`compute`
1067	`raygeneration`
1068	`intersection`
1069	`anyhit`
1070	`closesthit`
1071	`miss`
1072	`callable`
1073	`mesh`
1074	`amplification`
1075	`library`
1076
1077	The special platform `anyAppleOS` (alias: `anyappleos`) is a shorthand that
1078	applies the availability attribute to all Apple Darwin platforms. An explicit
1079	platform-specific availability attribute takes precedence over an `anyAppleOS`
1080	attribute for that platform. Versions specified with `anyAppleOS` must be at
1081	least 26.0, which is the first OS release where all supported Apple platforms
1082	share a unified version number.
1083
1084	A declaration can typically be used even when deploying back to a platform
1085	version prior to when the declaration was introduced. When this happens, the
1086	declaration is [weakly linked](https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html),
1087	as if the `weak_import` attribute were added to the declaration. A
1088	weakly-linked declaration may or may not be present a run-time, and a program
1089	can determine whether the declaration is present by checking whether the
1090	address of that declaration is non-NULL.
1091
1092	The flag `strict` disallows using API when deploying back to a
1093	platform version prior to when the declaration was introduced. An
1094	attempt to use such API before its introduction causes a hard error.
1095	Weakly-linking is almost always a better API choice, since it allows
1096	users to query availability at runtime.
1097
1098	If there are multiple declarations of the same entity, the availability
1099	attributes must either match on a per-platform basis or later
1100	declarations must not have availability attributes for that
1101	platform. For example:
1102
1103	```c
1104	void g(void) __attribute__((availability(macos,introduced=10.4)));
1105	void g(void) __attribute__((availability(macos,introduced=10.4))); // okay, matches
1106	void g(void) __attribute__((availability(ios,introduced=4.0))); // okay, adds a new platform
1107	void g(void); // okay, inherits both macos and ios availability from above.
1108	void g(void) __attribute__((availability(macos,introduced=10.5))); // error: mismatch
1109	```
1110
1111	When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,:
1112
1113	```objc
1114	@interface A
1115	- (id)method __attribute__((availability(macos,introduced=10.4)));
1116	- (id)method2 __attribute__((availability(macos,introduced=10.4)));
1117	@end
1118
1119	@interface B : A
1120	- (id)method __attribute__((availability(macos,introduced=10.3))); // okay: method moved into base class later
1121	- (id)method __attribute__((availability(macos,introduced=10.5))); // error: this method was available via the base class in 10.4
1122	@end
1123	```
1124
1125	Starting with the macOS 10.12 SDK, the `API_AVAILABLE` macro from
1126	`<os/availability.h>` can simplify the spelling:
1127
1128	```objc
1129	@interface A
1130	- (id)method API_AVAILABLE(macos(10.11)));
1131	- (id)otherMethod API_AVAILABLE(macos(10.11), ios(11.0));
1132	@end
1133	```
1134
1135	Availability attributes can also be applied using a `#pragma clang attribute`.
1136	Any explicit availability attribute whose platform corresponds to the target
1137	platform is applied to a declaration regardless of the availability attributes
1138	specified in the pragma. For example, in the code below,
1139	`hasExplicitAvailabilityAttribute` will use the `macOS` availability
1140	attribute that is specified with the declaration, whereas
1141	`getsThePragmaAvailabilityAttribute` will use the `macOS` availability
1142	attribute that is applied by the pragma.
1143
1144	```c
1145	#pragma clang attribute push (__attribute__((availability(macOS, introduced=10.12))), apply_to=function)
1146	void getsThePragmaAvailabilityAttribute(void);
1147	void hasExplicitAvailabilityAttribute(void) __attribute__((availability(macos,introduced=10.4)));
1148	#pragma clang attribute pop
1149	```
1150
1151	For platforms like `watchOS` and `tvOS`, whose availability attributes can
1152	be implicitly inferred from an `iOS` availability attribute, the logic is
1153	slightly more complex. The explicit and the pragma-applied availability
1154	attributes whose platform corresponds to the target platform are applied as
1155	described in the previous paragraph. However, the implicitly inferred attributes
1156	are applied to a declaration only when there is no explicit or pragma-applied
1157	availability attribute whose platform corresponds to the target platform. For
1158	example, the function below will receive the `tvOS` availability from the
1159	pragma rather than using the inferred `iOS` availability from the declaration:
1160
1161	```c
1162	#pragma clang attribute push (__attribute__((availability(tvOS, introduced=12.0))), apply_to=function)
1163	void getsThePragmaTVOSAvailabilityAttribute(void) __attribute__((availability(iOS,introduced=11.0)));
1164	#pragma clang attribute pop
1165	```
1166
1167	The compiler is also able to apply implicitly inferred attributes from a pragma
1168	as well. For example, when targeting `tvOS`, the function below will receive
1169	a `tvOS` availability attribute that is implicitly inferred from the `iOS`
1170	availability attribute applied by the pragma:
1171
1172	```c
1173	#pragma clang attribute push (__attribute__((availability(iOS, introduced=12.0))), apply_to=function)
1174	void infersTVOSAvailabilityFromPragma(void);
1175	#pragma clang attribute pop
1176	```
1177
1178	The implicit attributes that are inferred from explicitly specified attributes
1179	whose platform corresponds to the target platform are applied to the declaration
1180	even if there is an availability attribute that can be inferred from a pragma.
1181	For example, the function below will receive the `tvOS, introduced=11.0`
1182	availability that is inferred from the attribute on the declaration rather than
1183	inferring availability from the pragma:
1184
1185	```c
1186	#pragma clang attribute push (__attribute__((availability(iOS, unavailable))), apply_to=function)
1187	void infersTVOSAvailabilityFromAttributeNextToDeclaration(void)
1188	__attribute__((availability(iOS,introduced=11.0)));
1189	#pragma clang attribute pop
1190	```
1191
1192	Also see the documentation for
1193	{ref}`@available <langext-objective-c-available>`)reST";
1194
1195	static const char AttrDoc_AvailableOnlyInDefaultEvalMethod[] = R"reST(No documentation.)reST";
1196
1197	static const char AttrDoc_BPFFastCall[] = R"reST(Functions annotated with this attribute are likely to be inlined by BPF JIT.
1198	It is assumed that inlined implementation uses less caller saved registers,
1199	than a regular function.
1200	Specifically, the following registers are likely to be preserved:
1201	- `R0` if function return value is `void`;
1202	- `R2-R5` if function takes 1 argument;
1203	- `R3-R5` if function takes 2 arguments;
1204	- `R4-R5` if function takes 3 arguments;
1205	- `R5` if function takes 4 arguments;
1206
1207	For such functions Clang generates code pattern that allows BPF JIT
1208	to recognize and remove unnecessary spills and fills of the preserved
1209	registers.)reST";
1210
1211	static const char AttrDoc_BPFPreserveAccessIndex[] = R"reST(Clang supports the `__attribute__((preserve_access_index))`
1212	attribute for the BPF target. This attribute may be attached to a
1213	struct or union declaration, where if -g is specified, it enables
1214	preserving struct or union member access debuginfo indices of this
1215	struct or union, similar to clang `__builtin_preserve_access_index()`.)reST";
1216
1217	static const char AttrDoc_BPFPreserveStaticOffset[] = R"reST(Clang supports the `__attribute__((preserve_static_offset))`
1218	attribute for the BPF target. This attribute may be attached to a
1219	struct or union declaration. Reading or writing fields of types having
1220	such annotation is guaranteed to generate LDX/ST/STX instruction with
1221	offset corresponding to the field.
1222
1223	For example:
1224
1225	```c
1226	struct foo {
1227	int a;
1228	int b;
1229	};
1230
1231	struct bar {
1232	int a;
1233	struct foo b;
1234	} __attribute__((preserve_static_offset));
1235
1236	void buz(struct bar *g) {
1237	g->b.a = 42;
1238	}
1239	```
1240
1241	The assignment to `g`'s field would produce an ST instruction with
1242	offset 8: `*(u32)(r1 + 8) = 42;`.
1243
1244	Without this attribute generated instructions might be different,
1245	depending on optimizations behavior. E.g. the example above could be
1246	rewritten as `r1 += 8; *(u32)(r1 + 0) = 42;`.)reST";
1247
1248	static const char AttrDoc_BTFDeclTag[] = R"reST(Clang supports the `__attribute__((btf_decl_tag("ARGUMENT")))` attribute for
1249	all targets. This attribute may be attached to a struct/union, struct/union
1250	field, function, function parameter, variable or typedef declaration. If -g is
1251	specified, the `ARGUMENT` info will be preserved in IR and be emitted to
1252	dwarf. For BPF targets, the `ARGUMENT` info will be emitted to .BTF ELF
1253	section too.)reST";
1254
1255	static const char AttrDoc_BTFTypeTag[] = R"reST(Clang supports the `__attribute__((btf_type_tag("ARGUMENT")))` attribute for
1256	all targets. It only has effect when `-g` is specified on the command line.
1257
1258	The attribute can be applied to a pointer type, in which case the tag is
1259	associated with the pointee type, e.g.:
1260
1261	```c
1262	int __attribute__((btf_type_tag("tag"))) *p;
1263	```
1264
1265	It can also be applied to the underlying type of a typedef, in which case the
1266	tag follows the typedef down to its base type, e.g.:
1267
1268	```c
1269	typedef struct foo __attribute__((btf_type_tag("tag"))) foo_t;
1270	```
1271
1272	The following is the corresponding btf:
1273
1274	```
1275	...
1276	[2] TYPE_TAG 'tag' type_id=4
1277	[3] TYPEDEF 'foo_t' type_id=2
1278	[4] STRUCT 'foo' size=4 vlen=1
1279	'c' type_id=5 bits_offset=0
1280	[5] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
1281	...
1282	```
1283
1284	The attribute is currently silently ignored in any other position (note: this
1285	scenario may be diagnosed in the future).
1286
1287	The `ARGUMENT` string will be preserved in IR and emitted to DWARF for the
1288	types used in variable declarations, function declarations, or typedef
1289	declarations.
1290
1291	For BPF targets, the `ARGUMENT` string will also be emitted to .BTF ELF
1292	section.)reST";
1293
1294	static const char AttrDoc_Blocking[] = R"reST(Declares that a function potentially blocks, and prevents any potential inference of `nonblocking`
1295	by the compiler.)reST";
1296
1297	static const char AttrDoc_Blocks[] = R"reST(No documentation.)reST";
1298
1299	static const char AttrDoc_Builtin[] = R"reST()reST";
1300
1301	static const char AttrDoc_BuiltinAlias[] = R"reST(This attribute is used in the implementation of the C intrinsics.
1302	It allows the C intrinsic functions to be declared using the names defined
1303	in target builtins, and still be recognized as clang builtins equivalent to the
1304	underlying name. For example, `riscv_vector.h` declares the function `vadd`
1305	with `__attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1)))`.
1306	This ensures that both functions are recognized as that clang builtin,
1307	and in the latter case, the choice of which builtin to identify the
1308	function as can be deferred until after overload resolution.
1309
1310	This attribute can only be used to set up the aliases for certain ARM/RISC-V
1311	C intrinsic functions; it is intended for use only inside `arm_*.h` and
1312	`riscv_*.h` and is not a general mechanism for declaring arbitrary aliases
1313	for clang builtin functions.)reST";
1314
1315	static const char AttrDoc_C11NoReturn[] = R"reST(A function declared as `_Noreturn` shall not return to its caller. The
1316	compiler will generate a diagnostic for a function declared as `_Noreturn`
1317	that appears to be capable of returning to its caller. Despite being a type
1318	specifier, the `_Noreturn` attribute cannot be specified on a function
1319	pointer type.)reST";
1320
1321	static const char AttrDoc_CDecl[] = R"reST(No documentation.)reST";
1322
1323	static const char AttrDoc_CFAuditedTransfer[] = R"reST(No documentation.)reST";
1324
1325	static const char AttrDoc_CFConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1326	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1327	convention (e.g. functions starting with "get" are assumed to return at
1328	`+0`).
1329
1330	It can be overridden using a family of the following attributes. In
1331	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
1332	a function communicates that the object is returned at `+1`, and the caller
1333	is responsible for freeing it.
1334	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
1335	specifies that the object is returned at `+0` and the ownership remains with
1336	the callee.
1337	The annotation `__attribute__((ns_consumes_self))` specifies that
1338	the Objective-C method call consumes the reference to `self`, e.g. by
1339	attaching it to a supplied parameter.
1340	Additionally, parameters can have an annotation
1341	`__attribute__((ns_consumed))`, which specifies that passing an owned object
1342	as that parameter effectively transfers the ownership, and the caller is no
1343	longer responsible for it.
1344	These attributes affect code generation when interacting with ARC code, and
1345	they are used by the Clang Static Analyzer.
1346
1347	In C programs using CoreFoundation, a similar set of attributes:
1348	`__attribute__((cf_returns_not_retained))`,
1349	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
1350	have the same respective semantics when applied to CoreFoundation objects.
1351	These attributes affect code generation when interacting with ARC code, and
1352	they are used by the Clang Static Analyzer.
1353
1354	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1355	the same attribute family is present:
1356	`__attribute__((os_returns_not_retained))`,
1357	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
1358	with the same respective semantics.
1359	Similar to `__attribute__((ns_consumes_self))`,
1360	`__attribute__((os_consumes_this))` specifies that the method call consumes
1361	the reference to "this" (e.g., when attaching it to a different object supplied
1362	as a parameter).
1363	Out parameters (parameters the function is meant to write into,
1364	either via pointers-to-pointers or references-to-pointers)
1365	may be annotated with `__attribute__((os_returns_retained))`
1366	or `__attribute__((os_returns_not_retained))` which specifies that the object
1367	written into the out parameter should (or respectively should not) be released
1368	after use.
1369	Since often out parameters may or may not be written depending on the exit
1370	code of the function,
1371	annotations `__attribute__((os_returns_retained_on_zero))`
1372	and `__attribute__((os_returns_retained_on_non_zero))` specify that
1373	an out parameter at `+1` is written if and only if the function returns a zero
1374	(respectively non-zero) error code.
1375	Observe that return-code-dependent out parameter annotations are only
1376	available for retained out parameters, as non-retained object do not have to be
1377	released by the callee.
1378	These attributes are only used by the Clang Static Analyzer.
1379
1380	The family of attributes `X_returns_X_retained` can be added to functions,
1381	C++ methods, and Objective-C methods and properties.
1382	Attributes `X_consumed` can be added to parameters of methods, functions,
1383	and Objective-C methods.)reST";
1384
1385	static const char AttrDoc_CFGuard[] = R"reST(Code can indicate CFG checks are not wanted with the `__declspec(guard(nocf))`
1386	attribute. This directs the compiler to not insert any CFG checks for the entire
1387	function. This approach is typically used only sparingly in specific situations
1388	where the programmer has manually inserted "CFG-equivalent" protection. The
1389	programmer knows that they are calling through some read-only function table
1390	whose address is obtained through read-only memory references and for which the
1391	index is masked to the function table limit. This approach may also be applied
1392	to small wrapper functions that are not inlined and that do nothing more than
1393	make a call through a function pointer. Since incorrect usage of this directive
1394	can compromise the security of CFG, the programmer must be very careful using
1395	the directive. Typically, this usage is limited to very small functions that
1396	only call one function.
1397
1398	`Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`)reST";
1399
1400	static const char AttrDoc_CFICanonicalJumpTable[] = R"reST(Use `__attribute__((cfi_canonical_jump_table))` on a function declaration to
1401	make the function's CFI jump table canonical. See {ref}`the CFI documentation
1402	<cfi-canonical-jump-tables>` for more details.)reST";
1403
1404	static const char AttrDoc_CFISalt[] = R"reST(The `cfi_salt` attribute specifies a string literal that is used as a salt
1405	for Control-Flow Integrity (CFI) checks to distinguish between functions with
1406	the same type signature. This attribute can be applied to function declarations,
1407	function definitions, and function pointer typedefs.
1408
1409	The attribute prevents function pointers from being replaced with pointers to
1410	functions that have a compatible type, which can be a CFI bypass vector.
1411
1412	Syntax:
1413
1414	- GNU-style: `__attribute__((cfi_salt("<salt_string>")))`
1415	- C++11-style: `[[clang::cfi_salt("<salt_string>")]]`
1416
1417	Usage:
1418
1419	The attribute takes a single string literal argument that serves as the salt.
1420	Functions or function types with different salt values will have different CFI
1421	hashes, even if they have identical type signatures.
1422
1423	Motivation:
1424
1425	In large codebases like the Linux kernel, there are often hundreds of functions
1426	with identical type signatures that are called indirectly:
1427
1428	```
1429	1662 functions with void (*)(void)
1430	1179 functions with int (*)(void)
1431	...
1432	```
1433
1434	By salting the CFI hashes, you can make CFI more robust by ensuring that
1435	functions intended for different purposes have distinct CFI identities.
1436
1437	Type Compatibility:
1438
1439	- Functions with different salt values are considered to have incompatible types
1440	- Function pointers with different salt values cannot be assigned to each other
1441	- All declarations of the same function must use the same salt value
1442
1443	Example:
1444
1445	```c
1446	// Header file - define convenience macros
1447	#define __cfi_salt(s) __attribute__((cfi_salt(s)))
1448
1449	// Typedef for regular function pointers
1450	typedef int (*fptr_t)(void);
1451
1452	// Typedef for salted function pointers
1453	typedef int (*fptr_salted_t)(void) __cfi_salt("pepper");
1454
1455	struct widget_ops {
1456	fptr_t init; // Regular CFI
1457	fptr_salted_t exec; // Salted CFI
1458	fptr_t cleanup; // Regular CFI
1459	};
1460
1461	// Function implementations
1462	static int widget_init(void) { return 0; }
1463	static int widget_exec(void) __cfi_salt("pepper") { return 1; }
1464	static int widget_cleanup(void) { return 0; }
1465
1466	static struct widget_ops ops = {
1467	.init = widget_init, // OK - compatible types
1468	.exec = widget_exec, // OK - both use "pepper" salt
1469	.cleanup = widget_cleanup // OK - compatible types
1470	};
1471
1472	// Using C++11 attribute syntax
1473	void secure_callback(void) [[clang::cfi_salt("secure")]];
1474
1475	// This would cause a compilation error:
1476	// fptr_t bad_ptr = widget_exec; // Error: incompatible types
1477	```
1478
1479	Notes:
1480
1481	- The salt string can contain non-NULL ASCII characters, including spaces and
1482	quotes
1483	- This attribute only applies to function types; using it on non-function
1484	types will generate a warning
1485	- All declarations and definitions of the same function must use identical
1486	salt values
1487	- The attribute affects type compatibility during compilation and CFI hash
1488	generation during code generation)reST";
1489
1490	static const char AttrDoc_CFIUncheckedCallee[] = R"reST(`cfi_unchecked_callee` is a function type attribute which prevents the
1491	compiler from instrumenting
1492	{doc}`Control Flow Integrity <ControlFlowIntegrity>` checks on indirect
1493	function calls. This also includes control flow checks added by
1494	`-fsanitize=function`; see {ref}`Available checks <ubsan-checks>`.
1495	Specifically, the attribute has the following semantics:
1496
1497	1. Indirect calls to a function type with this attribute will not be instrumented with CFI. That is,
1498	the indirect call will not be checked. Note that this only changes the behavior for indirect calls
1499	on pointers to function types having this attribute. It does not prevent all indirect function calls
1500	for a given type from being checked.
1501	2. All direct references to a function whose type has this attribute will always reference the
1502	function definition rather than an entry in the CFI jump table.
1503	3. When a pointer to a function with this attribute is implicitly cast to a pointer to a function
1504	without this attribute, the compiler will give a warning saying this attribute is discarded. This
1505	warning can be silenced with an explicit cast. Note an explicit cast just disables the warning, so
1506	direct references to a function with a `cfi_unchecked_callee` attribute will still reference the
1507	function definition rather than the CFI jump table.
1508
1509	```c
1510	#define CFI_UNCHECKED_CALLEE __attribute__((cfi_unchecked_callee))
1511
1512	void no_cfi() CFI_UNCHECKED_CALLEE {}
1513
1514	void (*with_cfi)() = no_cfi; // warning: implicit conversion discards `cfi_unchecked_callee` attribute.
1515	// `with_cfi` also points to the actual definition of `no_cfi` rather than
1516	// its jump table entry.
1517
1518	void invoke(void (CFI_UNCHECKED_CALLEE *func)()) {
1519	func(); // CFI will not instrument this indirect call.
1520
1521	void (*func2)() = func; // warning: implicit conversion discards `cfi_unchecked_callee` attribute.
1522
1523	func2(); // CFI will instrument this indirect call. Users should be careful however because if this
1524	// references a function with type `cfi_unchecked_callee`, then the CFI check may incorrectly
1525	// fail because the reference will be to the function definition rather than the CFI jump
1526	// table entry.
1527	}
1528	```
1529
1530	This attribute can only be applied on functions or member functions. This attribute can be a good
1531	alternative to `no_sanitize("cfi")` if you only want to disable innstrumentation for specific indirect
1532	calls rather than applying `no_sanitize("cfi")` on the whole function containing indirect call. Note
1533	that `cfi_unchecked_attribute` is a type attribute doesn't disable CFI instrumentation on a function
1534	body.)reST";
1535
1536	static const char AttrDoc_CFReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1537	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1538	convention (e.g. functions starting with "get" are assumed to return at
1539	`+0`).
1540
1541	It can be overridden using a family of the following attributes. In
1542	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
1543	a function communicates that the object is returned at `+1`, and the caller
1544	is responsible for freeing it.
1545	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
1546	specifies that the object is returned at `+0` and the ownership remains with
1547	the callee.
1548	The annotation `__attribute__((ns_consumes_self))` specifies that
1549	the Objective-C method call consumes the reference to `self`, e.g. by
1550	attaching it to a supplied parameter.
1551	Additionally, parameters can have an annotation
1552	`__attribute__((ns_consumed))`, which specifies that passing an owned object
1553	as that parameter effectively transfers the ownership, and the caller is no
1554	longer responsible for it.
1555	These attributes affect code generation when interacting with ARC code, and
1556	they are used by the Clang Static Analyzer.
1557
1558	In C programs using CoreFoundation, a similar set of attributes:
1559	`__attribute__((cf_returns_not_retained))`,
1560	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
1561	have the same respective semantics when applied to CoreFoundation objects.
1562	These attributes affect code generation when interacting with ARC code, and
1563	they are used by the Clang Static Analyzer.
1564
1565	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1566	the same attribute family is present:
1567	`__attribute__((os_returns_not_retained))`,
1568	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
1569	with the same respective semantics.
1570	Similar to `__attribute__((ns_consumes_self))`,
1571	`__attribute__((os_consumes_this))` specifies that the method call consumes
1572	the reference to "this" (e.g., when attaching it to a different object supplied
1573	as a parameter).
1574	Out parameters (parameters the function is meant to write into,
1575	either via pointers-to-pointers or references-to-pointers)
1576	may be annotated with `__attribute__((os_returns_retained))`
1577	or `__attribute__((os_returns_not_retained))` which specifies that the object
1578	written into the out parameter should (or respectively should not) be released
1579	after use.
1580	Since often out parameters may or may not be written depending on the exit
1581	code of the function,
1582	annotations `__attribute__((os_returns_retained_on_zero))`
1583	and `__attribute__((os_returns_retained_on_non_zero))` specify that
1584	an out parameter at `+1` is written if and only if the function returns a zero
1585	(respectively non-zero) error code.
1586	Observe that return-code-dependent out parameter annotations are only
1587	available for retained out parameters, as non-retained object do not have to be
1588	released by the callee.
1589	These attributes are only used by the Clang Static Analyzer.
1590
1591	The family of attributes `X_returns_X_retained` can be added to functions,
1592	C++ methods, and Objective-C methods and properties.
1593	Attributes `X_consumed` can be added to parameters of methods, functions,
1594	and Objective-C methods.)reST";
1595
1596	static const char AttrDoc_CFReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1597	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1598	convention (e.g. functions starting with "get" are assumed to return at
1599	`+0`).
1600
1601	It can be overridden using a family of the following attributes. In
1602	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
1603	a function communicates that the object is returned at `+1`, and the caller
1604	is responsible for freeing it.
1605	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
1606	specifies that the object is returned at `+0` and the ownership remains with
1607	the callee.
1608	The annotation `__attribute__((ns_consumes_self))` specifies that
1609	the Objective-C method call consumes the reference to `self`, e.g. by
1610	attaching it to a supplied parameter.
1611	Additionally, parameters can have an annotation
1612	`__attribute__((ns_consumed))`, which specifies that passing an owned object
1613	as that parameter effectively transfers the ownership, and the caller is no
1614	longer responsible for it.
1615	These attributes affect code generation when interacting with ARC code, and
1616	they are used by the Clang Static Analyzer.
1617
1618	In C programs using CoreFoundation, a similar set of attributes:
1619	`__attribute__((cf_returns_not_retained))`,
1620	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
1621	have the same respective semantics when applied to CoreFoundation objects.
1622	These attributes affect code generation when interacting with ARC code, and
1623	they are used by the Clang Static Analyzer.
1624
1625	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1626	the same attribute family is present:
1627	`__attribute__((os_returns_not_retained))`,
1628	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
1629	with the same respective semantics.
1630	Similar to `__attribute__((ns_consumes_self))`,
1631	`__attribute__((os_consumes_this))` specifies that the method call consumes
1632	the reference to "this" (e.g., when attaching it to a different object supplied
1633	as a parameter).
1634	Out parameters (parameters the function is meant to write into,
1635	either via pointers-to-pointers or references-to-pointers)
1636	may be annotated with `__attribute__((os_returns_retained))`
1637	or `__attribute__((os_returns_not_retained))` which specifies that the object
1638	written into the out parameter should (or respectively should not) be released
1639	after use.
1640	Since often out parameters may or may not be written depending on the exit
1641	code of the function,
1642	annotations `__attribute__((os_returns_retained_on_zero))`
1643	and `__attribute__((os_returns_retained_on_non_zero))` specify that
1644	an out parameter at `+1` is written if and only if the function returns a zero
1645	(respectively non-zero) error code.
1646	Observe that return-code-dependent out parameter annotations are only
1647	available for retained out parameters, as non-retained object do not have to be
1648	released by the callee.
1649	These attributes are only used by the Clang Static Analyzer.
1650
1651	The family of attributes `X_returns_X_retained` can be added to functions,
1652	C++ methods, and Objective-C methods and properties.
1653	Attributes `X_consumed` can be added to parameters of methods, functions,
1654	and Objective-C methods.)reST";
1655
1656	static const char AttrDoc_CFUnknownTransfer[] = R"reST(No documentation.)reST";
1657
1658	static const char AttrDoc_CPUDispatch[] = R"reST(The `cpu_specific` and `cpu_dispatch` attributes are used to define and
1659	resolve multiversioned functions. This form of multiversioning provides a
1660	mechanism for declaring versions across translation units and manually
1661	specifying the resolved function list. A specified CPU defines a set of minimum
1662	features that are required for the function to be called. The result of this is
1663	that future processors execute the most restrictive version of the function the
1664	new processor can execute.
1665
1666	In addition, unlike the ICC implementation of this feature, the selection of the
1667	version does not consider the manufacturer or microarchitecture of the processor.
1668	It tests solely the list of features that are both supported by the specified
1669	processor and present in the compiler-rt library. This can be surprising at times,
1670	as the runtime processor may be from a completely different manufacturer, as long
1671	as it supports the same feature set.
1672
1673	This can additionally be surprising, as some processors are indistringuishable from
1674	others based on the list of testable features. When this happens, the variant
1675	is selected in an unspecified manner.
1676
1677	Function versions are defined with `cpu_specific`, which takes one or more CPU
1678	names as a parameter. For example:
1679
1680	```c
1681	// Declares and defines the ivybridge version of single_cpu.
1682	__attribute__((cpu_specific(ivybridge)))
1683	void single_cpu(void){}
1684
1685	// Declares and defines the atom version of single_cpu.
1686	__attribute__((cpu_specific(atom)))
1687	void single_cpu(void){}
1688
1689	// Declares and defines both the ivybridge and atom version of multi_cpu.
1690	__attribute__((cpu_specific(ivybridge, atom)))
1691	void multi_cpu(void){}
1692	```
1693
1694	A dispatching (or resolving) function can be declared anywhere in a project's
1695	source code with `cpu_dispatch`. This attribute takes one or more CPU names
1696	as a parameter (like `cpu_specific`). Functions marked with `cpu_dispatch`
1697	are not expected to be defined, only declared. If such a marked function has a
1698	definition, any side effects of the function are ignored; trivial function
1699	bodies are permissible for ICC compatibility.
1700
1701	```c
1702	// Creates a resolver for single_cpu above.
1703	__attribute__((cpu_dispatch(ivybridge, atom)))
1704	void single_cpu(void){}
1705
1706	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1707	// translation unit.
1708	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1709	void multi_cpu(void){}
1710	```
1711
1712	Note that it is possible to have a resolving function that dispatches based on
1713	more or fewer options than are present in the program. Specifying fewer will
1714	result in the omitted options not being considered during resolution. Specifying
1715	a version for resolution that isn't defined in the program will result in a
1716	linking failure.
1717
1718	It is also possible to specify a CPU name of `generic` which will be resolved
1719	if the executing processor doesn't satisfy the features required in the CPU
1720	name. The behavior of a program executing on a processor that doesn't satisfy
1721	any option of a multiversioned function is undefined.)reST";
1722
1723	static const char AttrDoc_CPUSpecific[] = R"reST(The `cpu_specific` and `cpu_dispatch` attributes are used to define and
1724	resolve multiversioned functions. This form of multiversioning provides a
1725	mechanism for declaring versions across translation units and manually
1726	specifying the resolved function list. A specified CPU defines a set of minimum
1727	features that are required for the function to be called. The result of this is
1728	that future processors execute the most restrictive version of the function the
1729	new processor can execute.
1730
1731	In addition, unlike the ICC implementation of this feature, the selection of the
1732	version does not consider the manufacturer or microarchitecture of the processor.
1733	It tests solely the list of features that are both supported by the specified
1734	processor and present in the compiler-rt library. This can be surprising at times,
1735	as the runtime processor may be from a completely different manufacturer, as long
1736	as it supports the same feature set.
1737
1738	This can additionally be surprising, as some processors are indistringuishable from
1739	others based on the list of testable features. When this happens, the variant
1740	is selected in an unspecified manner.
1741
1742	Function versions are defined with `cpu_specific`, which takes one or more CPU
1743	names as a parameter. For example:
1744
1745	```c
1746	// Declares and defines the ivybridge version of single_cpu.
1747	__attribute__((cpu_specific(ivybridge)))
1748	void single_cpu(void){}
1749
1750	// Declares and defines the atom version of single_cpu.
1751	__attribute__((cpu_specific(atom)))
1752	void single_cpu(void){}
1753
1754	// Declares and defines both the ivybridge and atom version of multi_cpu.
1755	__attribute__((cpu_specific(ivybridge, atom)))
1756	void multi_cpu(void){}
1757	```
1758
1759	A dispatching (or resolving) function can be declared anywhere in a project's
1760	source code with `cpu_dispatch`. This attribute takes one or more CPU names
1761	as a parameter (like `cpu_specific`). Functions marked with `cpu_dispatch`
1762	are not expected to be defined, only declared. If such a marked function has a
1763	definition, any side effects of the function are ignored; trivial function
1764	bodies are permissible for ICC compatibility.
1765
1766	```c
1767	// Creates a resolver for single_cpu above.
1768	__attribute__((cpu_dispatch(ivybridge, atom)))
1769	void single_cpu(void){}
1770
1771	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1772	// translation unit.
1773	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1774	void multi_cpu(void){}
1775	```
1776
1777	Note that it is possible to have a resolving function that dispatches based on
1778	more or fewer options than are present in the program. Specifying fewer will
1779	result in the omitted options not being considered during resolution. Specifying
1780	a version for resolution that isn't defined in the program will result in a
1781	linking failure.
1782
1783	It is also possible to specify a CPU name of `generic` which will be resolved
1784	if the executing processor doesn't satisfy the features required in the CPU
1785	name. The behavior of a program executing on a processor that doesn't satisfy
1786	any option of a multiversioned function is undefined.)reST";
1787
1788	static const char AttrDoc_CUDAClusterDims[] = R"reST(In CUDA/HIP programming, the `cluster_dims` attribute, conventionally exposed as the
1789	`__cluster_dims__` macro, can be applied to a kernel function to set the dimensions of a
1790	thread block cluster, which is an optional level of hierarchy and made up of thread blocks.
1791	`__cluster_dims__` defines the cluster size as `(X, Y, Z)`, where each value is the number
1792	of thread blocks in that dimension. The `cluster_dims` and `no_cluster` attributes are
1793	mutually exclusive.
1794
1795	```
1796	__global__ __cluster_dims__(2, 1, 1) void kernel(...) {
1797	...
1798	}
1799	```)reST";
1800
1801	static const char AttrDoc_CUDAConstant[] = R"reST(No documentation.)reST";
1802
1803	static const char AttrDoc_CUDADevice[] = R"reST(No documentation.)reST";
1804
1805	static const char AttrDoc_CUDADeviceBuiltinSurfaceType[] = R"reST(The `device_builtin_surface_type` attribute can be applied to a class
1806	template when declaring the surface reference. A surface reference variable
1807	could be accessed on the host side and, on the device side, might be translated
1808	into an internal surface object, which is established through surface bind and
1809	unbind runtime APIs.)reST";
1810
1811	static const char AttrDoc_CUDADeviceBuiltinTextureType[] = R"reST(The `device_builtin_texture_type` attribute can be applied to a class
1812	template when declaring the texture reference. A texture reference variable
1813	could be accessed on the host side and, on the device side, might be translated
1814	into an internal texture object, which is established through texture bind and
1815	unbind runtime APIs.)reST";
1816
1817	static const char AttrDoc_CUDAGlobal[] = R"reST(No documentation.)reST";
1818
1819	static const char AttrDoc_CUDAGridConstant[] = R"reST(The `__grid_constant__` attribute can be applied to a `const`-qualified kernel
1820	function argument and allows compiler to take the address of that argument without
1821	making a copy. The argument applies to sm_70 or newer GPUs, during compilation
1822	with CUDA-11.7(PTX 7.7) or newer, and is ignored otherwise.)reST";
1823
1824	static const char AttrDoc_CUDAHost[] = R"reST(No documentation.)reST";
1825
1826	static const char AttrDoc_CUDAInvalidTarget[] = R"reST()reST";
1827
1828	static const char AttrDoc_CUDALaunchBounds[] = R"reST(The ``__launch_bounds__`` attribute (also spelled ``launch_bounds``) originates
1829	in CUDA. It informs the compiler of the launch configuration a kernel will be
1830	dispatched with, allowing it to optimize the kernel accordingly. It takes the
1831	form ``__launch_bounds__(<max-threads-per-block>[,
1832	<min-blocks-per-multiprocessor>[, <max-blocks-per-cluster>]])``. All arguments
1833	are constant expressions.
1834
1835	The attribute only takes effect on ``__global__`` (kernel) functions; like
1836	NVCC, Clang ignores it on any other function.
1837
1838	``<max-threads-per-block>`` specifies the maximum number of threads per block
1839	the kernel will be launched with. ``<min-blocks-per-multiprocessor>`` specifies
1840	the desired minimum number of blocks resident per multiprocessor, and
1841	``<max-blocks-per-cluster>`` the maximum number of blocks per cluster.
1842
1843	For the NVPTX target, ``<max-threads-per-block>`` and
1844	``<min-blocks-per-multiprocessor>`` map to the ``.maxntid`` and ``.minnctapersm``
1845	PTX directives, respectively, and ``<max-blocks-per-cluster>`` (which requires
1846	``sm_90`` or newer) maps to ``.maxclusterrank``.
1847
1848	For the AMDGPU target, the attribute is translated into the equivalent AMDGPU
1849	kernel attributes:
1850
1851	- ``<max-threads-per-block>`` sets the maximum
1852	``amdgpu_flat_work_group_size`` (as ``1, <max-threads-per-block>``).
1853	- ``<min-blocks-per-multiprocessor>`` sets the minimum
1854	``amdgpu_waves_per_eu``. Note that HIP reinterprets this CUDA argument as a
1855	minimum number of waves per execution unit, so its meaning differs from the
1856	NVPTX interpretation.
1857	- ``<max-blocks-per-cluster>`` is currently ignored.
1858
1859	An explicit ``amdgpu_flat_work_group_size`` or ``amdgpu_waves_per_eu`` attribute
1860	takes precedence over the value derived from ``__launch_bounds__``.
1861
1862	When the same kernel is declared multiple times, the launch bounds from the most
1863	recent declaration that specifies them are used; a definition without
1864	``__launch_bounds__`` inherits the bounds from an earlier declaration.)reST";
1865
1866	static const char AttrDoc_CUDANoCluster[] = R"reST(In CUDA/HIP programming, a kernel function can still be launched with the cluster feature enabled
1867	at runtime, even without being annotated with `__cluster_dims__`. The LLVM/Clang-exclusive
1868	`no_cluster` attribute, conventionally exposed as the `__no_cluster__` macro, can be applied to
1869	a kernel function to explicitly indicate that the cluster feature will not be enabled either at
1870	compile time or at kernel launch time. This allows the compiler to apply certain optimizations
1871	without assuming that clustering could be enabled at runtime. It is undefined behavior to launch a
1872	kernel annotated with `__no_cluster__` if the cluster feature is enabled at runtime.
1873	The `cluster_dims` and `no_cluster` attributes are mutually exclusive.
1874
1875	```
1876	__global__ __no_cluster__ void kernel(...) {
1877	...
1878	}
1879	```)reST";
1880
1881	static const char AttrDoc_CUDAShared[] = R"reST(No documentation.)reST";
1882
1883	static const char AttrDoc_CXX11NoReturn[] = R"reST(A function declared as `[[noreturn]]` shall not return to its caller. The
1884	compiler will generate a diagnostic for a function declared as `[[noreturn]]`
1885	that appears to be capable of returning to its caller.
1886
1887	The `[[_Noreturn]]` spelling is deprecated and only exists to ease code
1888	migration for code using `[[noreturn]]` after including `<stdnoreturn.h>`.)reST";
1889
1890	static const char AttrDoc_CXXAssume[] = R"reST(The `assume` attribute is used to indicate to the optimizer that a
1891	certain condition is assumed to be true at a certain point in the
1892	program. If this condition is violated at runtime, the behavior is
1893	undefined. `assume` can only be applied to a null statement.
1894
1895	Different optimisers are likely to react differently to the presence of
1896	this attribute; in some cases, adding `assume` may affect performance
1897	negatively. It should be used with parsimony and care.
1898
1899	Example:
1900
1901	```c++
1902	int f(int x, int y) {
1903	[[assume(x == 27)]];
1904	[[assume(x == y)]];
1905	return y + 1; // May be optimised to `return 28`.
1906	}
1907	```)reST";
1908
1909	static const char AttrDoc_CallableWhen[] = R"reST(Use `__attribute__((callable_when(...)))` to indicate what states a method
1910	may be called in. Valid states are unconsumed, consumed, or unknown. Each
1911	argument to this attribute must be a quoted string. E.g.:
1912
1913	`__attribute__((callable_when("unconsumed", "unknown")))`)reST";
1914
1915	static const char AttrDoc_Callback[] = R"reST(The `callback` attribute specifies that the annotated function may invoke the
1916	specified callback zero or more times. The callback, as well as the passed
1917	arguments, are identified by their parameter name or position (starting with
1918	1!) in the annotated function. The first position in the attribute identifies
1919	the callback callee, the following positions declare describe its arguments.
1920	The callback callee is required to be callable with the number, and order, of
1921	the specified arguments. The index `0`, or the identifier `this`, is used to
1922	represent an implicit "this" pointer in class methods. If there is no implicit
1923	"this" pointer it shall not be referenced. The index '-1', or the name "\_\_",
1924	represents an unknown callback callee argument. This can be a value which is
1925	not present in the declared parameter list, or one that is, but is potentially
1926	inspected, captured, or modified. Parameter names and indices can be mixed in
1927	the callback attribute.
1928
1929	The `callback` attribute, which is directly translated to `callback`
1930	metadata \<<http://llvm.org/docs/LangRef.html#callback-metadata>>, make the
1931	connection between the call to the annotated function and the callback callee.
1932	This can enable interprocedural optimizations which were otherwise impossible.
1933	If a function parameter is mentioned in the `callback` attribute, through its
1934	position, it is undefined if that parameter is used for anything other than the
1935	actual callback. Inspected, captured, or modified parameters shall not be
1936	listed in the `callback` metadata.
1937
1938	Example encodings for the callback performed by `pthread_create` are shown
1939	below. The explicit attribute annotation indicates that the third parameter
1940	(`start_routine`) is called zero or more times by the `pthread_create` function,
1941	and that the fourth parameter (`arg`) is passed along. Note that the callback
1942	behavior of `pthread_create` is automatically recognized by Clang. In addition,
1943	the declarations of `__kmpc_fork_teams` and `__kmpc_fork_call`, generated for
1944	`#pragma omp target teams` and `#pragma omp parallel`, respectively, are also
1945	automatically recognized as broker functions. Further functions might be added
1946	in the future.
1947
1948	```c
1949	__attribute__((callback (start_routine, arg)))
1950	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1951	void (start_routine) (void ), void arg);
1952
1953	__attribute__((callback (3, 4)))
1954	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1955	void (start_routine) (void ), void arg);
1956	```)reST";
1957
1958	static const char AttrDoc_CalledOnce[] = R"reST(The `called_once` attribute specifies that the annotated function or method
1959	parameter is invoked exactly once on all execution paths. It only applies
1960	to parameters with function-like types, i.e. function pointers or blocks. This
1961	concept is particularly useful for asynchronous programs.
1962
1963	Clang implements a check for `called_once` parameters,
1964	`-Wcalled-once-parameter`. It is on by default and finds the following
1965	violations:
1966
1967	- Parameter is not called at all.
1968	- Parameter is called more than once.
1969	- Parameter is not called on one of the execution paths.
1970
1971	In the latter case, Clang pinpoints the path where parameter is not invoked
1972	by showing the control-flow statement where the path diverges.
1973
1974	```objc
1975	void fooWithCallback(void (^callback)(void) __attribute__((called_once))) {
1976	if (somePredicate()) {
1977	...
1978	callback();
1979	} else {
1980	callback(); // OK: callback is called on every path
1981	}
1982	}
1983
1984	void barWithCallback(void (^callback)(void) __attribute__((called_once))) {
1985	if (somePredicate()) {
1986	...
1987	callback(); // note: previous call is here
1988	}
1989	callback(); // warning: callback is called twice
1990	}
1991
1992	void foobarWithCallback(void (^callback)(void) __attribute__((called_once))) {
1993	if (somePredicate()) { // warning: callback is not called when condition is false
1994	...
1995	callback();
1996	}
1997	}
1998	```
1999
2000	This attribute is useful for API developers who want to double-check if they
2001	implemented their method correctly.)reST";
2002
2003	static const char AttrDoc_Capability[] = R"reST(No documentation.)reST";
2004
2005	static const char AttrDoc_CapturedRecord[] = R"reST()reST";
2006
2007	static const char AttrDoc_Cleanup[] = R"reST(This attribute allows a function to be run when a local variable goes out of
2008	scope. The attribute takes the identifier of a function with a parameter type
2009	that is a pointer to the type with the attribute.
2010
2011	```c
2012	static void foo (int *) { ... }
2013	static void bar (int *) { ... }
2014	void baz (void) {
2015	int x __attribute__((cleanup(foo)));
2016	{
2017	int y __attribute__((cleanup(bar)));
2018	}
2019	}
2020	```
2021
2022	The above example will result in a call to `bar` being passed the address of
2023	`y` when `y` goes out of scope, then a call to `foo` being passed the
2024	address of `x` when `x` goes out of scope. If two or more variables share
2025	the same scope, their `cleanup` callbacks are invoked in the reverse order
2026	the variables were declared in. It is not possible to check the return value
2027	(if any) of these `cleanup` callback functions.)reST";
2028
2029	static const char AttrDoc_ClspvLibclcBuiltin[] = R"reST(Attribute used by [clspv][clspv] (OpenCL-C to Vulkan SPIR-V compiler) to identify functions coming from [libclc][libclc] (OpenCL-C builtin library).
2030
2031	```c
2032	void __attribute__((clspv_libclc_builtin)) libclc_builtin() {}
2033	```
2034
2035	[clspv]: https://github.com/google/clspv
2036	[libclc]: https://libclc.llvm.org)reST";
2037
2038	static const char AttrDoc_CmseNSCall[] = R"reST(This attribute declares a non-secure function type. When compiling for secure
2039	state, a call to such a function would switch from secure to non-secure state.
2040	All non-secure function calls must happen only through a function pointer, and
2041	a non-secure function type should only be used as a base type of a pointer.
2042	See [ARMv8-M Security Extensions: Requirements on Development
2043	Tools - Engineering Specification Documentation](https://developer.arm.com/docs/ecm0359818/latest/) for more information.)reST";
2044
2045	static const char AttrDoc_CmseNSEntry[] = R"reST(This attribute declares a function that can be called from non-secure state, or
2046	from secure state. Entering from and returning to non-secure state would switch
2047	to and from secure state, respectively, and prevent flow of information
2048	to non-secure state, except via return values. See [ARMv8-M Security Extensions:
2049	Requirements on Development Tools - Engineering Specification Documentation](https://developer.arm.com/docs/ecm0359818/latest/) for more information.)reST";
2050
2051	static const char AttrDoc_CodeAlign[] = R"reST(The `clang::code_align(N)` attribute applies to a loop and specifies the byte
2052	alignment for a loop. The attribute accepts a positive integer constant
2053	initialization expression indicating the number of bytes for the minimum
2054	alignment boundary. Its value must be a power of 2, between 1 and 4096
2055	(inclusive).
2056
2057	```c++
2058	void foo() {
2059	int var = 0;
2060	[[clang::code_align(16)]] for (int i = 0; i < 10; ++i) var++;
2061	}
2062
2063	void Array(int *array, size_t n) {
2064	[[clang::code_align(64)]] for (int i = 0; i < n; ++i) array[i] = 0;
2065	}
2066
2067	void count () {
2068	int a1[10], int i = 0;
2069	[[clang::code_align(32)]] while (i < 10) { a1[i] += 3; }
2070	}
2071
2072	void check() {
2073	int a = 10;
2074	[[clang::code_align(8)]] do {
2075	a = a + 1;
2076	} while (a < 20);
2077	}
2078
2079	template<int A>
2080	void func() {
2081	[[clang::code_align(A)]] for(;;) { }
2082	}
2083	```)reST";
2084
2085	static const char AttrDoc_CodeModel[] = R"reST(The `model` attribute allows overriding the translation unit's
2086	code model (specified by `-mcmodel`) for a specific global variable.
2087
2088	On LoongArch, allowed values are "normal", "medium", "extreme".
2089
2090	On x86-64, allowed values are `"small"` and `"large"`. `"small"` is
2091	roughly equivalent to `-mcmodel=small`, meaning the global is considered
2092	"small" placed closer to the `.text` section relative to "large" globals, and
2093	to prefer using 32-bit relocations to access the global. `"large"` is roughly
2094	equivalent to `-mcmodel=large`, meaning the global is considered "large" and
2095	placed further from the `.text` section relative to "small" globals, and
2096	64-bit relocations must be used to access the global.)reST";
2097
2098	static const char AttrDoc_CodeSeg[] = R"reST(The `__declspec(code_seg)` attribute enables the placement of code into separate
2099	named segments that can be paged or locked in memory individually. This attribute
2100	is used to control the placement of instantiated templates and compiler-generated
2101	code. See the documentation for [\_\_declspec(code_seg)][__declspec(code_seg)] on MSDN.
2102
2103	[__declspec(code_seg)]: http://msdn.microsoft.com/en-us/library/dn636922.aspx)reST";
2104
2105	static const char AttrDoc_Cold[] = R"reST(`__attribute__((cold))` marks a function as cold, as a manual alternative to PGO hotness data.
2106	If PGO data is available, the profile count based hotness overrides the `__attribute__((cold))` annotation (unlike `__attribute__((hot))`).)reST";
2107
2108	static const char AttrDoc_Common[] = R"reST(No documentation.)reST";
2109
2110	static const char AttrDoc_Const[] = R"reST(No documentation.)reST";
2111
2112	static const char AttrDoc_ConstInit[] = R"reST(This attribute specifies that the variable to which it is attached is intended
2113	to have a [constant initializer](http://en.cppreference.com/w/cpp/language/constant_initialization)
2114	according to the rules of [basic.start.static]. The variable is required to
2115	have static or thread storage duration. If the initialization of the variable
2116	is not a constant initializer an error will be produced. This attribute may
2117	only be used in C++; the `constinit` spelling is only accepted in C++20
2118	onwards.
2119
2120	Note that in C++03 strict constant expression checking is not done. Instead
2121	the attribute reports if Clang can emit the variable as a constant, even if it's
2122	not technically a 'constant initializer'. This behavior is non-portable.
2123
2124	Static storage duration variables with constant initializers avoid hard-to-find
2125	bugs caused by the indeterminate order of dynamic initialization. They can also
2126	be safely used during dynamic initialization across translation units.
2127
2128	This attribute acts as a compile time assertion that the requirements
2129	for constant initialization have been met. Since these requirements change
2130	between dialects and have subtle pitfalls it's important to fail fast instead
2131	of silently falling back on dynamic initialization.
2132
2133	The first use of the attribute on a variable must be part of, or precede, the
2134	initializing declaration of the variable. C++20 requires the `constinit`
2135	spelling of the attribute to be present on the initializing declaration if it
2136	is used anywhere. The other spellings can be specified on a forward declaration
2137	and omitted on a later initializing declaration.
2138
2139	```c++
2140	// -std=c++14
2141	#define SAFE_STATIC [[clang::require_constant_initialization]]
2142	struct T {
2143	constexpr T(int) {}
2144	~T(); // non-trivial
2145	};
2146	SAFE_STATIC T x = {42}; // Initialization OK. Doesn't check destructor.
2147	SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
2148	// copy initialization is not a constant expression on a non-literal type.
2149	```)reST";
2150
2151	static const char AttrDoc_Constructor[] = R"reST(The `constructor` attribute causes the function to be called before entering
2152	`main()`, and the `destructor` attribute causes the function to be called
2153	after returning from `main()` or when the `exit()` function has been
2154	called. Note, `quick_exit()`, `_Exit()`, and `abort()` prevent a function
2155	marked `destructor` from being called.
2156
2157	The constructor or destructor function should not accept any arguments and its
2158	return type should be `void`.
2159
2160	The attributes accept an optional argument used to specify the priority order
2161	in which to execute constructor and destructor functions. The priority is
2162	given as an integer constant expression between 101 and 65535 (inclusive).
2163	Priorities outside of that range are reserved for use by the implementation. A
2164	lower value indicates a higher priority of initialization. Note that only the
2165	relative ordering of values is important. For example:
2166
2167	```c++
2168	__attribute__((constructor(200))) void foo(void);
2169	__attribute__((constructor(101))) void bar(void);
2170	```
2171
2172	`bar()` will be called before `foo()`, and both will be called before
2173	`main()`. If no argument is given to the `constructor` or `destructor`
2174	attribute, they default to the value `65535`.)reST";
2175
2176	static const char AttrDoc_Consumable[] = R"reST(Each `class` that uses any of the typestate annotations must first be marked
2177	using the `consumable` attribute. Failure to do so will result in a warning.
2178
2179	This attribute accepts a single parameter that must be one of the following:
2180	`unknown`, `consumed`, or `unconsumed`.)reST";
2181
2182	static const char AttrDoc_ConsumableAutoCast[] = R"reST(No documentation.)reST";
2183
2184	static const char AttrDoc_ConsumableSetOnRead[] = R"reST(No documentation.)reST";
2185
2186	static const char AttrDoc_Convergent[] = R"reST(The `convergent` attribute can be placed on a function declaration. It is
2187	translated into the LLVM `convergent` attribute, which indicates that the call
2188	instructions of a function with this attribute cannot be made control-dependent
2189	on any additional values.
2190
2191	This attribute is different from `noduplicate` because it allows duplicating
2192	function calls if it can be proved that the duplicated function calls are
2193	not made control-dependent on any additional values, e.g., unrolling a loop
2194	executed by all work items.
2195
2196	Sample usage:
2197
2198	```c
2199	void convfunc(void) __attribute__((convergent));
2200	// Setting it as a C++11 attribute is also valid in a C++ program.
2201	// void convfunc(void) [[clang::convergent]];
2202	```)reST";
2203
2204	static const char AttrDoc_CoroAwaitElidable[] = R"reST(The `[[clang::coro_await_elidable]]` is a class attribute which can be
2205	applied to a coroutine return type. It provides a hint to the compiler to apply
2206	Heap Allocation Elision more aggressively.
2207
2208	When a coroutine function returns such a type, a direct call expression therein
2209	that returns a prvalue of a type attributed `[[clang::coro_await_elidable]]`
2210	is said to be under a safe elide context if one of the following is true:
2211
2212	- it is the immediate right-hand side operand to a co_await expression.
2213	- it is an argument to a `[[clang::coro_await_elidable_argument]]` parameter
2214	or parameter pack of another direct call expression under a safe elide context.
2215
2216	Do note that the safe elide context applies only to the call expression itself,
2217	and the context does not transitively include any of its subexpressions unless
2218	exceptional rules of `[[clang::coro_await_elidable_argument]]` apply.
2219
2220	The compiler performs heap allocation elision on call expressions under a safe
2221	elide context, if the callee is a coroutine.
2222
2223	Example:
2224
2225	```c++
2226	class [[clang::coro_await_elidable]] Task { ... };
2227
2228	Task foo();
2229	Task bar() {
2230	co_await foo(); // foo()'s coroutine frame on this line is elidable
2231	auto t = foo(); // foo()'s coroutine frame on this line is NOT elidable
2232	co_await t;
2233	}
2234	```
2235
2236	Such elision replaces the heap allocated activation frame of the callee coroutine
2237	with a local variable within the enclosing braces in the caller's stack frame.
2238	The local variable, like other variables in coroutines, may be collected into the
2239	coroutine frame, which may be allocated on the heap. The behavior is undefined
2240	if the caller coroutine is destroyed earlier than the callee coroutine.)reST";
2241
2242	static const char AttrDoc_CoroAwaitElidableArgument[] = R"reST(The `[[clang::coro_await_elidable_argument]]` is a function parameter attribute.
2243	It works in conjunction with `[[clang::coro_await_elidable]]` to propagate a
2244	safe elide context to a parameter or parameter pack if the function is called
2245	under a safe elide context.
2246
2247	This is sometimes necessary on utility functions used to compose or modify the
2248	behavior of a callee coroutine.
2249
2250	Example:
2251
2252	```c++
2253	template <typename T>
2254	class [[clang::coro_await_elidable]] Task { ... };
2255
2256	template <typename... T>
2257	class [[clang::coro_await_elidable]] WhenAll { ... };
2258
2259	// `when_all` is a utility function that composes coroutines. It does not
2260	// need to be a coroutine to propagate.
2261	template <typename... T>
2262	WhenAll<T...> when_all([[clang::coro_await_elidable_argument]] Task<T> tasks...);
2263
2264	Task<int> foo();
2265	Task<int> bar();
2266	Task<void> example1() {
2267	// `when_all`, `foo`, and `bar` are all elide safe because `when_all` is
2268	// under a safe elide context and, thanks to the [[clang::coro_await_elidable_argument]]
2269	// attribute, such context is propagated to foo and bar.
2270	co_await when_all(foo(), bar());
2271	}
2272
2273	Task<void> example2() {
2274	// `when_all` and `bar` are elide safe. `foo` is not elide safe.
2275	auto f = foo();
2276	co_await when_all(f, bar());
2277	}
2278
2279
2280	Task<void> example3() {
2281	// None of the calls are elide safe.
2282	auto t = when_all(foo(), bar());
2283	co_await t;
2284	}
2285	```)reST";
2286
2287	static const char AttrDoc_CoroDisableLifetimeBound[] = R"reST(The `[[clang::coro_lifetimebound]]` is a class attribute which can be applied
2288	to a coroutine return type ([coro_return_type, coro_wrapper]) (i.e.
2289	it should also be annotated with `[[clang::coro_return_type]]`).
2290
2291	All parameters of a function are considered to be lifetime bound if the function returns a
2292	coroutine return type (CRT) annotated with `[[clang::coro_lifetimebound]]`.
2293	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
2294	with `[[clang::coro_disable_lifetimebound]]` function attribute .
2295	See documentation of [lifetimebound] for details about lifetime bound analysis.
2296
2297	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
2298
2299	For example,
2300
2301	```c++
2302	task<int> coro(const int& a) { co_return a + 1; }
2303	task<int> dangling_refs(int a) {
2304	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
2305	auto foo = coro(1);
2306	// `coro` captures reference to local variable `a` which is destroyed after the return.
2307	return coro(a);
2308	}
2309	```
2310
2311	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
2312	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
2313	`[[clang::coro_lifetimebound]]`, then lifetime bound analysis would detect capturing reference to
2314	temporaries or return address of a local variable.
2315
2316	Both coroutines and coroutine wrappers are part of this analysis.
2317
2318	```c++
2319	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
2320	using promise_type = some_promise_type;
2321	};
2322
2323	Task<int> coro(const int& a) { co_return a + 1; }
2324	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
2325	return a > b ? coro(a) : coro(b);
2326	}
2327	Task<int> temporary_reference() {
2328	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
2329
2330	int a = 1;
2331	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
2332
2333	co_return co_await coro(1); // fine.
2334	}
2335	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
2336	return coro(a); // warning: returning address of stack variable `a`.
2337	}
2338	```
2339
2340	This analysis can be disabled for all calls to a particular function by annotating the function
2341	with function attribute `[[clang::coro_disable_lifetimebound]]`.
2342	For example, this could be useful for coroutine wrappers which accept reference parameters
2343	but do not pass them to the underlying coroutine or pass them by value.
2344
2345	```c++
2346	Task<int> coro(int a) { co_return a + 1; }
2347	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
2348	return coro(a + 1);
2349	}
2350	void use() {
2351	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
2352	}
2353	```)reST";
2354
2355	static const char AttrDoc_CoroLifetimeBound[] = R"reST(The `[[clang::coro_lifetimebound]]` is a class attribute which can be applied
2356	to a coroutine return type ([coro_return_type, coro_wrapper]) (i.e.
2357	it should also be annotated with `[[clang::coro_return_type]]`).
2358
2359	All parameters of a function are considered to be lifetime bound if the function returns a
2360	coroutine return type (CRT) annotated with `[[clang::coro_lifetimebound]]`.
2361	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
2362	with `[[clang::coro_disable_lifetimebound]]` function attribute .
2363	See documentation of [lifetimebound] for details about lifetime bound analysis.
2364
2365	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
2366
2367	For example,
2368
2369	```c++
2370	task<int> coro(const int& a) { co_return a + 1; }
2371	task<int> dangling_refs(int a) {
2372	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
2373	auto foo = coro(1);
2374	// `coro` captures reference to local variable `a` which is destroyed after the return.
2375	return coro(a);
2376	}
2377	```
2378
2379	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
2380	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
2381	`[[clang::coro_lifetimebound]]`, then lifetime bound analysis would detect capturing reference to
2382	temporaries or return address of a local variable.
2383
2384	Both coroutines and coroutine wrappers are part of this analysis.
2385
2386	```c++
2387	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
2388	using promise_type = some_promise_type;
2389	};
2390
2391	Task<int> coro(const int& a) { co_return a + 1; }
2392	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
2393	return a > b ? coro(a) : coro(b);
2394	}
2395	Task<int> temporary_reference() {
2396	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
2397
2398	int a = 1;
2399	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
2400
2401	co_return co_await coro(1); // fine.
2402	}
2403	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
2404	return coro(a); // warning: returning address of stack variable `a`.
2405	}
2406	```
2407
2408	This analysis can be disabled for all calls to a particular function by annotating the function
2409	with function attribute `[[clang::coro_disable_lifetimebound]]`.
2410	For example, this could be useful for coroutine wrappers which accept reference parameters
2411	but do not pass them to the underlying coroutine or pass them by value.
2412
2413	```c++
2414	Task<int> coro(int a) { co_return a + 1; }
2415	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
2416	return coro(a + 1);
2417	}
2418	void use() {
2419	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
2420	}
2421	```)reST";
2422
2423	static const char AttrDoc_CoroOnlyDestroyWhenComplete[] = R"reST(The `coro_only_destroy_when_complete` attribute should be marked on a C++ class. The coroutines
2424	whose return type is marked with the attribute are assumed to be destroyed only after the coroutine has
2425	reached the final suspend point.
2426
2427	This is helpful for the optimizers to reduce the size of the destroy function for the coroutines.
2428
2429	For example,
2430
2431	```c++
2432	A foo() {
2433	dtor d;
2434	co_await something();
2435	dtor d1;
2436	co_await something();
2437	dtor d2;
2438	co_return 43;
2439	}
2440	```
2441
2442	The compiler may generate the following pseudocode:
2443
2444	```c++
2445	void foo.destroy(foo.Frame *frame) {
2446	switch(frame->suspend_index()) {
2447	case 1:
2448	frame->d.~dtor();
2449	break;
2450	case 2:
2451	frame->d.~dtor();
2452	frame->d1.~dtor();
2453	break;
2454	case 3:
2455	frame->d.~dtor();
2456	frame->d1.~dtor();
2457	frame->d2.~dtor();
2458	break;
2459	default: // coroutine completed or haven't started
2460	break;
2461	}
2462
2463	frame->promise.~promise_type();
2464	delete frame;
2465	}
2466	```
2467
2468	The `foo.destroy()` function's purpose is to release all of the resources
2469	initialized for the coroutine when it is destroyed in a suspended state.
2470	However, if the coroutine is only ever destroyed at the final suspend state,
2471	the rest of the conditions are superfluous.
2472
2473	The user can use the `coro_only_destroy_when_complete` attributo suppress
2474	generation of the other destruction cases, optimizing the above `foo.destroy` to:
2475
2476	```c++
2477	void foo.destroy(foo.Frame *frame) {
2478	frame->promise.~promise_type();
2479	delete frame;
2480	}
2481	```)reST";
2482
2483	static const char AttrDoc_CoroReturnType[] = R"reST(The `[[clang::coro_return_type]]` attribute is used to help static analyzers to recognize
2484	coroutines from the function signatures.
2485
2486	The `coro_return_type` attribute should be marked on a C++ class to mark it as
2487	a coroutine return type (CRT).
2488
2489	A function `R func(P1, .., PN)` has a coroutine return type (CRT) `R` if `R`
2490	is marked by `[[clang::coro_return_type]]` and `R` has a promise type associated to it
2491	(i.e., std::coroutine_traits\<R, P1, .., PN>::promise_type is a valid promise type).
2492
2493	If the return type of a function is a `CRT` then the function must be a coroutine.
2494	Otherwise the program is invalid. It is allowed for a non-coroutine to return a `CRT`
2495	if the function is marked with `[[clang::coro_wrapper]]`.
2496
2497	The `[[clang::coro_wrapper]]` attribute should be marked on a C++ function to mark it as
2498	a coroutine wrapper. A coroutine wrapper is a function which returns a `CRT`,
2499	is not a coroutine itself and is marked with `[[clang::coro_wrapper]]`.
2500
2501	Clang will enforce that all functions that return a `CRT` are either coroutines or marked
2502	with `[[clang::coro_wrapper]]`. Clang will enforce this with an error.
2503
2504	From a language perspective, it is not possible to differentiate between a coroutine and a
2505	function returning a CRT by merely looking at the function signature.
2506
2507	Coroutine wrappers, in particular, are susceptible to capturing
2508	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2509	issues with coroutine wrappers.
2510
2511	For example,
2512
2513	```c++
2514	// This is a CRT.
2515	template <typename T> struct [[clang::coro_return_type]] Task {
2516	using promise_type = some_promise_type;
2517	};
2518
2519	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2520	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2521
2522	// Fine for a coroutine wrapper to return a CRT.
2523	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2524
2525	void bar() {
2526	// Invalid. This intantiates a function which returns a CRT but is not marked as
2527	// a coroutine wrapper.
2528	std::function<Task<int>(int)> f = increment;
2529	}
2530	```
2531
2532	Note: `a_promise_type::get_return_object` is exempted from this analysis as it is a necessary
2533	implementation detail of any coroutine library.)reST";
2534
2535	static const char AttrDoc_CoroWrapper[] = R"reST(The `[[clang::coro_return_type]]` attribute is used to help static analyzers to recognize
2536	coroutines from the function signatures.
2537
2538	The `coro_return_type` attribute should be marked on a C++ class to mark it as
2539	a coroutine return type (CRT).
2540
2541	A function `R func(P1, .., PN)` has a coroutine return type (CRT) `R` if `R`
2542	is marked by `[[clang::coro_return_type]]` and `R` has a promise type associated to it
2543	(i.e., std::coroutine_traits\<R, P1, .., PN>::promise_type is a valid promise type).
2544
2545	If the return type of a function is a `CRT` then the function must be a coroutine.
2546	Otherwise the program is invalid. It is allowed for a non-coroutine to return a `CRT`
2547	if the function is marked with `[[clang::coro_wrapper]]`.
2548
2549	The `[[clang::coro_wrapper]]` attribute should be marked on a C++ function to mark it as
2550	a coroutine wrapper. A coroutine wrapper is a function which returns a `CRT`,
2551	is not a coroutine itself and is marked with `[[clang::coro_wrapper]]`.
2552
2553	Clang will enforce that all functions that return a `CRT` are either coroutines or marked
2554	with `[[clang::coro_wrapper]]`. Clang will enforce this with an error.
2555
2556	From a language perspective, it is not possible to differentiate between a coroutine and a
2557	function returning a CRT by merely looking at the function signature.
2558
2559	Coroutine wrappers, in particular, are susceptible to capturing
2560	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2561	issues with coroutine wrappers.
2562
2563	For example,
2564
2565	```c++
2566	// This is a CRT.
2567	template <typename T> struct [[clang::coro_return_type]] Task {
2568	using promise_type = some_promise_type;
2569	};
2570
2571	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2572	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2573
2574	// Fine for a coroutine wrapper to return a CRT.
2575	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2576
2577	void bar() {
2578	// Invalid. This intantiates a function which returns a CRT but is not marked as
2579	// a coroutine wrapper.
2580	std::function<Task<int>(int)> f = increment;
2581	}
2582	```
2583
2584	Note: `a_promise_type::get_return_object` is exempted from this analysis as it is a necessary
2585	implementation detail of any coroutine library.)reST";
2586
2587	static const char AttrDoc_CountedBy[] = R"reST(The `counted_by` attribute is applied to a pointer or flexible array member to
2588	indicate that the pointer points to (or the flexible array member contains) at
2589	least the number of elements given by the attribute's argument.
2590
2591	This attribute is used by {doc}`-fbounds-safety <BoundsSafety>` to propagate
2592	bounds information on API surfaces without any ABI changes. This attribute is
2593	also used to improve the results of the array bound sanitizer and the
2594	`__builtin_dynamic_object_size` builtin.
2595
2596	Because the size of the pointee type must be known to compute the pointer's
2597	bounds, such a pointer must not be used while its pointee type is incomplete; a
2598	pointer to a forward-declared type is accepted on fields annotated with
2599	`counted_by`, but the type must be completed before the pointer is used. If
2600	the pointee type can never be completed, `counted_by` is rejected and
2601	`sized_by` should be used instead. `void *` is a special case: as a GNU
2602	extension (diagnosed by `-Wgnu-pointer-arith`), `counted_by` is accepted on
2603	it, where it behaves like `sized_by` (the argument is treated as a byte count,
2604	`void` having an assumed size of one byte).
2605
2606	A pointer annotated with `counted_by` must have a count of zero when it is
2607	null. This requirement is currently only enforced when compiling with
2608	{doc}`-fbounds-safety <BoundsSafety>` (see {ref}`Current status of
2609	-fbounds-safety support in upstream Clang <bounds-safety-current-upstream-status>`). Use
2610	`counted_by_or_null` for a pointer that may be null while carrying a nonzero
2611	count.
2612
2613	#### Keeping pointer and count in sync
2614
2615	The `counted_by` attribute establishes a relationship between the annotated
2616	pointer and its count: the pointer must point to at least `count` elements.
2617	Assigning to only one of them can break this relationship.
2618	Without {doc}`-fbounds-safety <BoundsSafety>`, it is the programmer's
2619	responsibility to ensure the pointer and count remain in sync. With
2620	`-fbounds-safety` it is automatically enforced. For example:
2621
2622	```c
2623	struct buffer {
2624	int *buf __attribute__((counted_by(count)));
2625	size_t count;
2626	};
2627
2628	void grow(struct buffer *b, size_t new_count) {
2629	// b->buf isn't updated. The underlying memory pointed to by b->buf might be
2630	// smaller than new_count which would contradict the counted_by attribute.
2631	// Compile error with -fbounds-safety but allowed without -fbounds-safety.
2632	b->count = new_count;
2633	}
2634	```
2635
2636	Updating both together - so that `buf` points to `count` elements - keeps
2637	the attribute true. For example:
2638
2639	```c
2640	void grow(struct buffer *b, size_t new_count) {
2641	// Allowed by -fbounds-safety
2642	int new_buf = malloc(new_count sizeof(int));
2643	// -fbounds-safety enforces that the `new_buf` points to at least `new_count`
2644	// integers at runtime. Without -fbounds-safety nothing enforces this.
2645	b->buf = new_buf;
2646	b->count = new_count;
2647	}
2648	```
2649
2650	#### Flexible array members
2651
2652	The `counted_by` attribute may also be applied to the flexible array member of
2653	a structure in C. In this case the argument names the field member holding the
2654	count of elements in the flexible array; that field must be within the same
2655	non-anonymous, enclosing struct as the flexible array member.
2656
2657	This example specifies that the flexible array member `array` has the number
2658	of elements allocated for it in `count`:
2659
2660	```c
2661	struct bar;
2662
2663	struct foo {
2664	size_t count;
2665	char other;
2666	struct bar *array[] __attribute__((counted_by(count)));
2667	};
2668	```
2669
2670	This establishes a relationship between `array` and `count`. Specifically,
2671	`array` must have at least `count` number of elements available. It's the
2672	user's responsibility to ensure that this relationship is maintained through
2673	changes to the structure.
2674
2675	In the following example, the allocated array erroneously has fewer elements
2676	than what's specified by `p->count`. This would result in an out-of-bounds
2677	access not being detected.
2678
2679	```c
2680	#define SIZE_INCR 42
2681
2682	struct foo *p;
2683
2684	void foo_alloc(size_t count) {
2685	p = malloc(MAX(sizeof(struct foo),
2686	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2687	p->count = count + SIZE_INCR;
2688	}
2689	```
2690
2691	The next example updates `p->count`, but breaks the relationship requirement
2692	that `p->array` must have at least `p->count` number of elements available:
2693
2694	```c
2695	#define SIZE_INCR 42
2696
2697	struct foo *p;
2698
2699	void foo_alloc(size_t count) {
2700	p = malloc(MAX(sizeof(struct foo),
2701	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2702	p->count = count;
2703	}
2704
2705	void use_foo(int index, int val) {
2706	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
2707	p->array[index] = val; /* The sanitizer can't properly check this access. */
2708	}
2709	```
2710
2711	In this example, an update to `p->count` maintains the relationship
2712	requirement:
2713
2714	```c
2715	void use_foo(int index, int val) {
2716	if (p->count == 0)
2717	return;
2718	--p->count;
2719	p->array[index] = val;
2720	}
2721	```)reST";
2722
2723	static const char AttrDoc_CountedByOrNull[] = R"reST(The `counted_by_or_null` attribute is applied to a pointer to indicate that,
2724	if the pointer is non-null, it points to memory containing at least the number
2725	of elements given by the attribute's argument. If the pointer is null, the
2726	value of the argument is ignored and the pointer points to zero elements.
2727
2728	The `counted_by_or_null` attribute is identical to `counted_by` except that
2729	it treats null pointers differently and cannot be applied to a flexible array
2730	member. Whereas `counted_by` requires a null pointer to have a count of zero,
2731	`counted_by_or_null` allows the pointer to be null regardless of the value of
2732	the count. This supports the common idiom where a pointer is either null or
2733	points to memory containing at least the given number of elements.
2734
2735	Currently only {doc}`-fbounds-safety <BoundsSafety>` makes use of the
2736	distinction between `counted_by_or_null` and `counted_by` (see
2737	{ref}`Current status of -fbounds-safety support in upstream Clang
2738	<bounds-safety-current-upstream-status>`).)reST";
2739
2740	static const char AttrDoc_DLLExport[] = R"reST(The `__declspec(dllexport)` attribute declares a variable, function, or
2741	Objective-C interface to be exported from the module. It is available under the
2742	`-fdeclspec` flag for compatibility with various compilers. The primary use
2743	is for COFF object files which explicitly specify what interfaces are available
2744	for external use. See the [dllexport][dllexport] documentation on MSDN for more
2745	information.
2746
2747	[dllexport]: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2748
2749	static const char AttrDoc_DLLExportOnDecl[] = R"reST()reST";
2750
2751	static const char AttrDoc_DLLExportStaticLocal[] = R"reST()reST";
2752
2753	static const char AttrDoc_DLLImport[] = R"reST(The `__declspec(dllimport)` attribute declares a variable, function, or
2754	Objective-C interface to be imported from an external module. It is available
2755	under the `-fdeclspec` flag for compatibility with various compilers. The
2756	primary use is for COFF object files which explicitly specify what interfaces
2757	are imported from external modules. See the [dllimport][dllimport] documentation on MSDN
2758	for more information.
2759
2760	Note that a dllimport function may still be inlined, if its definition is
2761	available and it doesn't reference any non-dllimport functions or global
2762	variables.
2763
2764	[dllimport]: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2765
2766	static const char AttrDoc_DLLImportStaticLocal[] = R"reST()reST";
2767
2768	static const char AttrDoc_Deprecated[] = R"reST(The `deprecated` attribute can be applied to a function, a variable, or a
2769	type. This is useful when identifying functions, variables, or types that are
2770	expected to be removed in a future version of a program.
2771
2772	Consider the function declaration for a hypothetical function `f`:
2773
2774	```c++
2775	void f(void) __attribute__((deprecated("message", "replacement")));
2776	```
2777
2778	When spelled as `__attribute__((deprecated))`, the deprecated attribute can have
2779	two optional string arguments. The first one is the message to display when
2780	emitting the warning; the second one enables the compiler to provide a Fix-It
2781	to replace the deprecated name with a new name. Otherwise, when spelled as
2782	`[[gnu::deprecated]]` or `[[deprecated]]`, the attribute can have one optional
2783	string argument which is the message to display when emitting the warning.)reST";
2784
2785	static const char AttrDoc_Destructor[] = R"reST(The `constructor` attribute causes the function to be called before entering
2786	`main()`, and the `destructor` attribute causes the function to be called
2787	after returning from `main()` or when the `exit()` function has been
2788	called. Note, `quick_exit()`, `_Exit()`, and `abort()` prevent a function
2789	marked `destructor` from being called.
2790
2791	The constructor or destructor function should not accept any arguments and its
2792	return type should be `void`.
2793
2794	The attributes accept an optional argument used to specify the priority order
2795	in which to execute constructor and destructor functions. The priority is
2796	given as an integer constant expression between 101 and 65535 (inclusive).
2797	Priorities outside of that range are reserved for use by the implementation. A
2798	lower value indicates a higher priority of initialization. Note that only the
2799	relative ordering of values is important. For example:
2800
2801	```c++
2802	__attribute__((constructor(200))) void foo(void);
2803	__attribute__((constructor(101))) void bar(void);
2804	```
2805
2806	`bar()` will be called before `foo()`, and both will be called before
2807	`main()`. If no argument is given to the `constructor` or `destructor`
2808	attribute, they default to the value `65535`.)reST";
2809
2810	static const char AttrDoc_DeviceKernel[] = R"reST(These attributes specify that the function represents a kernel for device offloading.
2811	The specific semantics depend on the offloading language, target, and attribute spelling.
2812	Here is a code example using the attribute to mark a function as a kernel:
2813
2814	```c++
2815	[[clang::device_kernel]] int foo(int x) { return ++x; }
2816	```)reST";
2817
2818	static const char AttrDoc_DiagnoseAsBuiltin[] = R"reST(The `diagnose_as_builtin` attribute indicates that Fortify diagnostics are to
2819	be applied to the declared function as if it were the function specified by the
2820	attribute. The builtin function whose diagnostics are to be mimicked should be
2821	given. In addition, the order in which arguments should be applied must also
2822	be given.
2823
2824	For example, the attribute can be used as follows.
2825
2826	```c
2827	__attribute__((diagnose_as_builtin(__builtin_memset, 3, 2, 1)))
2828	void mymemset(int n, int c, void s) {
2829	// ...
2830	}
2831	```
2832
2833	This indicates that calls to `mymemset` should be diagnosed as if they were
2834	calls to `__builtin_memset`. The arguments `3, 2, 1` indicate by index the
2835	order in which arguments of `mymemset` should be applied to
2836	`__builtin_memset`. The third argument should be applied first, then the
2837	second, and then the first. Thus (when Fortify warnings are enabled) the call
2838	`mymemset(n, c, s)` will diagnose overflows as if it were the call
2839	`__builtin_memset(s, c, n)`.
2840
2841	For variadic functions, the variadic arguments must come in the same order as
2842	they would to the builtin function, after all normal arguments. For instance,
2843	to diagnose a new function as if it were `sscanf`, we can use the attribute as
2844	follows.
2845
2846	```c
2847	__attribute__((diagnose_as_builtin(sscanf, 1, 2)))
2848	int mysscanf(const char str, const char format, ...) {
2849	// ...
2850	}
2851	```
2852
2853	Then the call `mysscanf("abc def", "%4s %4s", buf1, buf2)` will be diagnosed as
2854	if it were the call `sscanf("abc def", "%4s %4s", buf1, buf2)`.
2855
2856	This attribute cannot be applied to non-static member functions.)reST";
2857
2858	static const char AttrDoc_DiagnoseIf[] = R"reST(The `diagnose_if` attribute can be placed on function declarations to emit
2859	warnings or errors at compile-time if calls to the attributed function meet
2860	certain user-defined criteria. For example:
2861
2862	```c
2863	int abs(int a)
2864	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "warning")));
2865	int must_abs(int a)
2866	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "error")));
2867
2868	int val = abs(1); // warning: Redundant abs call
2869	int val2 = must_abs(1); // error: Redundant abs call
2870	int val3 = abs(val);
2871	int val4 = must_abs(val); // Because run-time checks are not emitted for
2872	// diagnose_if attributes, this executes without
2873	// issue.
2874	```
2875
2876	`diagnose_if` is closely related to `enable_if`, with a few key differences:
2877
2878	- Overload resolution is not aware of `diagnose_if` attributes: they're
2879	considered only after we select the best candidate from a given candidate set.
2880	- Function declarations that differ only in their `diagnose_if` attributes are
2881	considered to be redeclarations of the same function (not overloads).
2882	- If the condition provided to `diagnose_if` cannot be evaluated, no
2883	diagnostic will be emitted.
2884
2885	Otherwise, `diagnose_if` is essentially the logical negation of `enable_if`.
2886
2887	As a result of bullet number two, `diagnose_if` attributes will stack on the
2888	same function. For example:
2889
2890	```c
2891	int foo() __attribute__((diagnose_if(1, "diag1", "warning")));
2892	int foo() __attribute__((diagnose_if(1, "diag2", "warning")));
2893
2894	int bar = foo(); // warning: diag1
2895	// warning: diag2
2896	int (*fooptr)(void) = foo; // warning: diag1
2897	// warning: diag2
2898
2899	constexpr int supportsAPILevel(int N) { return N < 5; }
2900	int baz(int a)
2901	__attribute__((diagnose_if(!supportsAPILevel(10),
2902	"Upgrade to API level 10 to use baz", "error")));
2903	int baz(int a)
2904	__attribute__((diagnose_if(!a, "0 is not recommended.", "warning")));
2905
2906	int (*bazptr)(int) = baz; // error: Upgrade to API level 10 to use baz
2907	int v = baz(0); // error: Upgrade to API level 10 to use baz
2908	```
2909
2910	Query for this feature with `__has_attribute(diagnose_if)`.)reST";
2911
2912	static const char AttrDoc_DisableSanitizerInstrumentation[] = R"reST(Use the `disable_sanitizer_instrumentation` attribute on a function,
2913	Objective-C method, or global variable, to specify that no sanitizer
2914	instrumentation should be applied.
2915
2916	This is not the same as `__attribute__((no_sanitize(...)))`, which depending
2917	on the tool may still insert instrumentation to prevent false positive reports.)reST";
2918
2919	static const char AttrDoc_DisableTailCalls[] = R"reST(The `disable_tail_calls` attribute instructs the backend to not perform tail
2920	call optimization inside the marked function.
2921
2922	For example:
2923
2924	```c
2925	int callee(int);
2926
2927	int foo(int a) __attribute__((disable_tail_calls)) {
2928	return callee(a); // This call is not tail-call optimized.
2929	}
2930	```
2931
2932	Marking virtual functions as `disable_tail_calls` is legal.
2933
2934	```c++
2935	int callee(int);
2936
2937	class Base {
2938	public:
2939	[[clang::disable_tail_calls]] virtual int foo1() {
2940	return callee(); // This call is not tail-call optimized.
2941	}
2942	};
2943
2944	class Derived1 : public Base {
2945	public:
2946	int foo1() override {
2947	return callee(); // This call is tail-call optimized.
2948	}
2949	};
2950	```)reST";
2951
2952	static const char AttrDoc_EmptyBases[] = R"reST(The empty_bases attribute permits the compiler to utilize the
2953	empty-base-optimization more frequently.
2954	This attribute only applies to struct, class, and union types.
2955	It is only supported when using the Microsoft C++ ABI.)reST";
2956
2957	static const char AttrDoc_EnableIf[] = R"reST(:::{Note}
2958	Some features of this attribute are experimental. The meaning of
2959	multiple enable_if attributes on a single declaration is subject to change in
2960	a future version of clang. Also, the ABI is not standardized and the name
2961	mangling may change in future versions. To avoid that, use asm labels.
2962	:::
2963
2964	The `enable_if` attribute can be placed on function declarations to control
2965	which overload is selected based on the values of the function's arguments.
2966	When combined with the `overloadable` attribute, this feature is also
2967	available in C.
2968
2969	```c++
2970	int isdigit(int c);
2971	int isdigit(int c) __attribute__((enable_if(c <= -1 \|\| c > 255, "chosen when 'c' is out of range"))) __attribute__((unavailable("'c' must have the value of an unsigned char or EOF")));
2972
2973	void foo(char c) {
2974	isdigit(c);
2975	isdigit(10);
2976	isdigit(-10); // results in a compile-time error.
2977	}
2978	```
2979
2980	The enable_if attribute takes two arguments, the first is an expression written
2981	in terms of the function parameters, the second is a string explaining why this
2982	overload candidate could not be selected to be displayed in diagnostics. The
2983	expression is part of the function signature for the purposes of determining
2984	whether it is a redeclaration (following the rules used when determining
2985	whether a C++ template specialization is ODR-equivalent), but is not part of
2986	the type.
2987
2988	The enable_if expression is evaluated as if it were the body of a
2989	bool-returning constexpr function declared with the arguments of the function
2990	it is being applied to, then called with the parameters at the call site. If the
2991	result is false or could not be determined through constant expression
2992	evaluation, then this overload will not be chosen and the provided string may
2993	be used in a diagnostic if the compile fails as a result.
2994
2995	Because the enable_if expression is an unevaluated context, there are no global
2996	state changes, nor the ability to pass information from the enable_if
2997	expression to the function body. For example, suppose we want calls to
2998	strnlen(strbuf, maxlen) to resolve to strnlen_chk(strbuf, maxlen, size of
2999	strbuf) only if the size of strbuf can be determined:
3000
3001	```c++
3002	__attribute__((always_inline))
3003	static inline size_t strnlen(const char *s, size_t maxlen)
3004	__attribute__((overloadable))
3005	__attribute__((enable_if(__builtin_object_size(s, 0) != -1))),
3006	"chosen when the buffer size is known but 'maxlen' is not")))
3007	{
3008	return strnlen_chk(s, maxlen, __builtin_object_size(s, 0));
3009	}
3010	```
3011
3012	Multiple enable_if attributes may be applied to a single declaration. In this
3013	case, the enable_if expressions are evaluated from left to right in the
3014	following manner. First, the candidates whose enable_if expressions evaluate to
3015	false or cannot be evaluated are discarded. If the remaining candidates do not
3016	share ODR-equivalent enable_if expressions, the overload resolution is
3017	ambiguous. Otherwise, enable_if overload resolution continues with the next
3018	enable_if attribute on the candidates that have not been discarded and have
3019	remaining enable_if attributes. In this way, we pick the most specific
3020	overload out of a number of viable overloads using enable_if.
3021
3022	```c++
3023	void f() __attribute__((enable_if(true, ""))); // #1
3024	void f() __attribute__((enable_if(true, ""))) __attribute__((enable_if(true, ""))); // #2
3025
3026	void g(int i, int j) __attribute__((enable_if(i, ""))); // #1
3027	void g(int i, int j) __attribute__((enable_if(j, ""))) __attribute__((enable_if(true))); // #2
3028	```
3029
3030	In this example, a call to f() is always resolved to #2, as the first enable_if
3031	expression is ODR-equivalent for both declarations, but #1 does not have another
3032	enable_if expression to continue evaluating, so the next round of evaluation has
3033	only a single candidate. In a call to g(1, 1), the call is ambiguous even though
3034	#2 has more enable_if attributes, because the first enable_if expressions are
3035	not ODR-equivalent.
3036
3037	Query for this feature with `__has_attribute(enable_if)`.
3038
3039	Note that functions with one or more `enable_if` attributes may not have
3040	their address taken, unless all of the conditions specified by said
3041	`enable_if` are constants that evaluate to `true`. For example:
3042
3043	```c
3044	const int TrueConstant = 1;
3045	const int FalseConstant = 0;
3046	int f(int a) __attribute__((enable_if(a > 0, "")));
3047	int g(int a) __attribute__((enable_if(a == 0 \|\| a != 0, "")));
3048	int h(int a) __attribute__((enable_if(1, "")));
3049	int i(int a) __attribute__((enable_if(TrueConstant, "")));
3050	int j(int a) __attribute__((enable_if(FalseConstant, "")));
3051
3052	void fn() {
3053	int (*ptr)(int);
3054	ptr = &f; // error: 'a > 0' is not always true
3055	ptr = &g; // error: 'a == 0 \|\| a != 0' is not a truthy constant
3056	ptr = &h; // OK: 1 is a truthy constant
3057	ptr = &i; // OK: 'TrueConstant' is a truthy constant
3058	ptr = &j; // error: 'FalseConstant' is a constant, but not truthy
3059	}
3060	```
3061
3062	Because `enable_if` evaluation happens during overload resolution,
3063	`enable_if` may give unintuitive results when used with templates, depending
3064	on when overloads are resolved. In the example below, clang will emit a
3065	diagnostic about no viable overloads for `foo` in `bar`, but not in `baz`:
3066
3067	```c++
3068	double foo(int i) __attribute__((enable_if(i > 0, "")));
3069	void *foo(int i) __attribute__((enable_if(i <= 0, "")));
3070	template <int I>
3071	auto bar() { return foo(I); }
3072
3073	template <typename T>
3074	auto baz() { return foo(T::number); }
3075
3076	struct WithNumber { constexpr static int number = 1; };
3077	void callThem() {
3078	bar<sizeof(WithNumber)>();
3079	baz<WithNumber>();
3080	}
3081	```
3082
3083	This is because, in `bar`, `foo` is resolved prior to template
3084	instantiation, so the value for `I` isn't known (thus, both `enable_if`
3085	conditions for `foo` fail). However, in `baz`, `foo` is resolved during
3086	template instantiation, so the value for `T::number` is known.)reST";
3087
3088	static const char AttrDoc_EnforceTCB[] = R"reST(The `enforce_tcb` attribute can be placed on functions to enforce that a
3089	trusted compute base (TCB) does not call out of the TCB. This generates a
3090	warning every time a function not marked with an `enforce_tcb` attribute is
3091	called from a function with the `enforce_tcb` attribute. A function may be a
3092	part of multiple TCBs. Invocations through function pointers are currently
3093	not checked. Builtins are considered to a part of every TCB.
3094
3095	- `enforce_tcb(Name)` indicates that this function is a part of the TCB named `Name`)reST";
3096
3097	static const char AttrDoc_EnforceTCBLeaf[] = R"reST(The `enforce_tcb_leaf` attribute satisfies the requirement enforced by
3098	`enforce_tcb` for the marked function to be in the named TCB but does not
3099	continue to check the functions called from within the leaf function.
3100
3101	- `enforce_tcb_leaf(Name)` indicates that this function is a part of the TCB named `Name`)reST";
3102
3103	static const char AttrDoc_EnumExtensibility[] = R"reST(Attribute `enum_extensibility` is used to distinguish between enum definitions
3104	that are extensible and those that are not. The attribute can take either
3105	`closed` or `open` as an argument. `closed` indicates a variable of the
3106	enum type takes a value that corresponds to one of the enumerators listed in the
3107	enum definition or, when the enum is annotated with `flag_enum`, a value that
3108	can be constructed using values corresponding to the enumerators. `open`
3109	indicates a variable of the enum type can take any values allowed by the
3110	standard and instructs clang to be more lenient when issuing warnings.
3111
3112	```c
3113	enum __attribute__((enum_extensibility(closed))) ClosedEnum {
3114	A0, A1
3115	};
3116
3117	enum __attribute__((enum_extensibility(open))) OpenEnum {
3118	B0, B1
3119	};
3120
3121	enum __attribute__((enum_extensibility(closed),flag_enum)) ClosedFlagEnum {
3122	C0 = 1 << 0, C1 = 1 << 1
3123	};
3124
3125	enum __attribute__((enum_extensibility(open),flag_enum)) OpenFlagEnum {
3126	D0 = 1 << 0, D1 = 1 << 1
3127	};
3128
3129	void foo1() {
3130	enum ClosedEnum ce;
3131	enum OpenEnum oe;
3132	enum ClosedFlagEnum cfe;
3133	enum OpenFlagEnum ofe;
3134
3135	ce = A1; // no warnings
3136	ce = 100; // warning issued
3137	oe = B1; // no warnings
3138	oe = 100; // no warnings
3139	cfe = C0 \| C1; // no warnings
3140	cfe = C0 \| C1 \| 4; // warning issued
3141	ofe = D0 \| D1; // no warnings
3142	ofe = D0 \| D1 \| 4; // no warnings
3143	}
3144	```)reST";
3145
3146	static const char AttrDoc_Error[] = R"reST(The `error` and `warning` function attributes can be used to specify a
3147	custom diagnostic to be emitted when a call to such a function is not
3148	eliminated via optimizations. This can be used to create compile time
3149	assertions that depend on optimizations, while providing diagnostics
3150	pointing to precise locations of the call site in the source.
3151
3152	```c++
3153	__attribute__((warning("oh no"))) void dontcall();
3154	void foo() {
3155	if (someCompileTimeAssertionThatsTrue)
3156	dontcall(); // Warning
3157
3158	dontcall(); // Warning
3159
3160	if (someCompileTimeAssertionThatsFalse)
3161	dontcall(); // No Warning
3162	sizeof(dontcall()); // No Warning
3163	}
3164	```
3165
3166	When the call occurs through inlined functions, the
3167	`-fdiagnostics-show-inlining-chain` option can be used to show the
3168	inlining chain that led to the call. This helps identify which call site
3169	triggered the diagnostic when the attributed function is called from
3170	multiple locations through inline functions.
3171
3172	When enabled, this option automatically uses debug info for accurate source
3173	locations if available (`-gline-directives-only` (implicitly enabled at
3174	`-g1`) or higher), or falls back to a heuristic based on metadata tracking.
3175	When falling back, a note is emitted suggesting `-gline-directives-only` for
3176	more accurate locations.)reST";
3177
3178	static const char AttrDoc_ExcludeFromExplicitInstantiation[] = R"reST(The `exclude_from_explicit_instantiation` attribute opts-out a member of a
3179	class template from being part of explicit template instantiations of that
3180	class template. This means that an explicit instantiation will not instantiate
3181	members of the class template marked with the attribute, but also that code
3182	where an extern template declaration of the enclosing class template is visible
3183	will not take for granted that an external instantiation of the class template
3184	would provide those members (which would otherwise be a link error, since the
3185	explicit instantiation won't provide those members). For example, let's say we
3186	don't want the `data()` method to be part of libc++'s ABI. To make sure it
3187	is not exported from the dylib, we give it hidden visibility:
3188
3189	```c++
3190	// in <string>
3191	template <class CharT>
3192	class basic_string {
3193	public:
3194	__attribute__((__visibility__("hidden")))
3195	const value_type* data() const noexcept { ... }
3196	};
3197
3198	template class basic_string<char>;
3199	```
3200
3201	Since an explicit template instantiation declaration for `basic_string<char>`
3202	is provided, the compiler is free to assume that `basic_string<char>::data()`
3203	will be provided by another translation unit, and it is free to produce an
3204	external call to this function. However, since `data()` has hidden visibility
3205	and the explicit template instantiation is provided in a shared library (as
3206	opposed to simply another translation unit), `basic_string<char>::data()`
3207	won't be found and a link error will ensue. This happens because the compiler
3208	assumes that `basic_string<char>::data()` is part of the explicit template
3209	instantiation declaration, when it really isn't. To tell the compiler that
3210	`data()` is not part of the explicit template instantiation declaration, the
3211	`exclude_from_explicit_instantiation` attribute can be used:
3212
3213	```c++
3214	// in <string>
3215	template <class CharT>
3216	class basic_string {
3217	public:
3218	__attribute__((__visibility__("hidden")))
3219	__attribute__((exclude_from_explicit_instantiation))
3220	const value_type* data() const noexcept { ... }
3221	};
3222
3223	template class basic_string<char>;
3224	```
3225
3226	Now, the compiler won't assume that `basic_string<char>::data()` is provided
3227	externally despite there being an explicit template instantiation declaration:
3228	the compiler will implicitly instantiate `basic_string<char>::data()` in the
3229	TUs where it is used.
3230
3231	This attribute can be used on static and non-static member functions of class
3232	templates, static data members of class templates and member classes of class
3233	templates.
3234
3235	Interaction with \_\_declspec(dllexport/dllimport)
3236
3237	For a DLL platform (i.e., Windows), this attribute also means "this member will
3238	never be exported or imported". Despite its name, this semantics applies to
3239	implicit instantiations and non-template entities as well.
3240
3241	```c++
3242	// in <exception>
3243	class __declspec(dllimport) nested_exception {
3244	...
3245	public:
3246	__attribute__((exclude_from_explicit_instantiation))
3247	exception_ptr nested_ptr() const noexcept { ... }
3248	};
3249	```
3250
3251	In this case, `nested_exception::nested_ptr` will never be attempted to be
3252	imported.)reST";
3253
3254	static const char AttrDoc_ExplicitInit[] = R"reST(The `clang::require_explicit_initialization` attribute indicates that a
3255	field of an aggregate must be initialized explicitly by the user when an object
3256	of the aggregate type is constructed. The attribute supports both C and C++,
3257	but its usage is invalid on non-aggregates.
3258
3259	Note that this attribute is not a memory safety feature, and is not intended
3260	to guard against use of uninitialized memory.
3261
3262	Rather, it is intended for use in "parameter-objects", used to simulate,
3263	for example, the passing of named parameters.
3264	Except inside unevaluated contexts, the attribute generates a warning when
3265	explicit initializers for such variables are not provided (this occurs
3266	regardless of whether any in-class field initializers exist):
3267
3268	```c++
3269	struct Buffer {
3270	void *address [[clang::require_explicit_initialization]];
3271	size_t length [[clang::require_explicit_initialization]] = 0;
3272	};
3273
3274	struct ArrayIOParams {
3275	size_t count [[clang::require_explicit_initialization]];
3276	size_t element_size [[clang::require_explicit_initialization]];
3277	int flags = 0;
3278	};
3279
3280	size_t ReadArray(FILE *file, struct Buffer buffer,
3281	struct ArrayIOParams params);
3282
3283	int main() {
3284	unsigned int buf[512];
3285	ReadArray(stdin, {
3286	buf
3287	// warning: field 'length' is not explicitly initialized
3288	}, {
3289	.count = sizeof(buf) / sizeof(*buf),
3290	// warning: field 'element_size' is not explicitly initialized
3291	// (Note that a missing initializer for 'flags' is not diagnosed, because
3292	// the field is not marked as requiring explicit initialization.)
3293	});
3294	}
3295	```)reST";
3296
3297	static const char AttrDoc_ExtVectorType[] = R"reST(The `ext_vector_type(N)` attribute specifies that a type is a vector with N
3298	elements, directly mapping to an LLVM vector type. Originally from OpenCL, it
3299	allows element access the array subscript operator `[]`, `sN` where N is
3300	a hexadecimal value, or `x, y, z, w` for graphics-style indexing.
3301	This attribute enables efficient SIMD operations and is usable in
3302	general-purpose code.
3303
3304	```c++
3305	template <typename T, uint32_t N>
3306	constexpr T simd_reduce(T [[clang::ext_vector_type(N)]] v) {
3307	static_assert((N & (N - 1)) == 0, "N must be a power of two");
3308	if constexpr (N == 1)
3309	return v[0];
3310	else
3311	return simd_reduce<T, N / 2>(v.hi + v.lo);
3312	}
3313	```
3314
3315	The vector type also supports swizzling up to sixteen elements. This can be done
3316	using the object accessors. The OpenCL documentation lists all of the accepted
3317	values.
3318
3319	```c++
3320	using f16_x16 = _Float16 __attribute__((ext_vector_type(16)));
3321
3322	f16_x16 reverse(f16_x16 v) { return v.sfedcba9876543210; }
3323	```
3324
3325	See the OpenCL documentation for some more complete examples.)reST";
3326
3327	static const char AttrDoc_ExternalSourceSymbol[] = R"reST(The `external_source_symbol` attribute specifies that a declaration originates
3328	from an external source and describes the nature of that source.
3329
3330	The fact that Clang is capable of recognizing declarations that were defined
3331	externally can be used to provide better tooling support for mixed-language
3332	projects or projects that rely on auto-generated code. For instance, an IDE that
3333	uses Clang and that supports mixed-language projects can use this attribute to
3334	provide a correct 'jump-to-definition' feature. For a concrete example,
3335	consider a protocol that's defined in a Swift file:
3336
3337	```swift
3338	@objc public protocol SwiftProtocol {
3339	func method()
3340	}
3341	```
3342
3343	This protocol can be used from Objective-C code by including a header file that
3344	was generated by the Swift compiler. The declarations in that header can use
3345	the `external_source_symbol` attribute to make Clang aware of the fact
3346	that `SwiftProtocol` actually originates from a Swift module:
3347
3348	```objc
3349	__attribute__((external_source_symbol(language="Swift",defined_in="module")))
3350	@protocol SwiftProtocol
3351	@required
3352	- (void) method;
3353	@end
3354	```
3355
3356	Consequently, when 'jump-to-definition' is performed at a location that
3357	references `SwiftProtocol`, the IDE can jump to the original definition in
3358	the Swift source file rather than jumping to the Objective-C declaration in the
3359	auto-generated header file.
3360
3361	The `external_source_symbol` attribute is a comma-separated list that includes
3362	clauses that describe the origin and the nature of the particular declaration.
3363	Those clauses can be:
3364
3365	language=string-literal
3366
3367	: The name of the source language in which this declaration was defined.
3368
3369	defined_in=string-literal
3370
3371	: The name of the source container in which the declaration was defined. The
3372	exact definition of source container is language-specific, e.g. Swift's
3373	source containers are modules, so `defined_in` should specify the Swift
3374	module name.
3375
3376	USR=string-literal
3377
3378	: String that specifies a unified symbol resolution (USR) value for this
3379	declaration. USR string uniquely identifies this particular declaration, and
3380	is typically used when constructing an index of a codebase.
3381	The USR value in this attribute is expected to be generated by an external
3382	compiler that compiled the native declaration using its original source
3383	language. The exact format of the USR string and its other attributes
3384	are determined by the specification of this declaration's source language.
3385	When not specified, Clang's indexer will use the Clang USR for this symbol.
3386	User can query to see if Clang supports the use of the `USR` clause in
3387	the `external_source_symbol` attribute with
3388	`__has_attribute(external_source_symbol) >= 20230206`.
3389
3390	generated_declaration
3391
3392	: This declaration was automatically generated by some tool.
3393
3394	The clauses can be specified in any order. The clauses that are listed above are
3395	all optional, but the attribute has to have at least one clause.)reST";
3396
3397	static const char AttrDoc_FallThrough[] = R"reST(The `fallthrough` (or `clang::fallthrough`) attribute is used
3398	to annotate intentional fall-through
3399	between switch labels. It can only be applied to a null statement placed at a
3400	point of execution between any statement and the next switch label. It is
3401	common to mark these places with a specific comment, but this attribute is
3402	meant to replace comments with a more strict annotation, which can be checked
3403	by the compiler. This attribute doesn't change semantics of the code and can
3404	be used wherever an intended fall-through occurs. It is designed to mimic
3405	control-flow statements like `break;`, so it can be placed in most places
3406	where `break;` can, but only if there are no statements on the execution path
3407	between it and the next switch label.
3408
3409	By default, Clang does not warn on unannotated fallthrough from one `switch`
3410	case to another. Diagnostics on fallthrough without a corresponding annotation
3411	can be enabled with the `-Wimplicit-fallthrough` argument.
3412
3413	Here is an example:
3414
3415	```c++
3416	// compile with -Wimplicit-fallthrough
3417	switch (n) {
3418	case 22:
3419	case 33: // no warning: no statements between case labels
3420	f();
3421	case 44: // warning: unannotated fall-through
3422	g();
3423	[[clang::fallthrough]];
3424	case 55: // no warning
3425	if (x) {
3426	h();
3427	break;
3428	}
3429	else {
3430	i();
3431	[[clang::fallthrough]];
3432	}
3433	case 66: // no warning
3434	p();
3435	[[clang::fallthrough]]; // warning: fallthrough annotation does not
3436	// directly precede case label
3437	q();
3438	case 77: // warning: unannotated fall-through
3439	r();
3440	}
3441	```)reST";
3442
3443	static const char AttrDoc_FastCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
3444	function to use ECX and EDX as register parameters and clear parameters off of
3445	the stack on return. This convention does not support variadic calls or
3446	unprototyped functions in C, and has no effect on x86_64 targets. This calling
3447	convention is supported primarily for compatibility with existing code. Users
3448	seeking register parameters should use the `regparm` attribute, which does
3449	not require callee-cleanup. See the documentation for [\_\_fastcall][__fastcall] on MSDN.
3450
3451	[__fastcall]: http://msdn.microsoft.com/en-us/library/6xa169sk.aspx)reST";
3452
3453	static const char AttrDoc_Final[] = R"reST()reST";
3454
3455	static const char AttrDoc_FlagEnum[] = R"reST(This attribute can be added to an enumerator to signal to the compiler that it
3456	is intended to be used as a flag type. This will cause the compiler to assume
3457	that the range of the type includes all of the values that you can get by
3458	manipulating bits of the enumerator when issuing warnings.)reST";
3459
3460	static const char AttrDoc_Flatten[] = R"reST(The `flatten` attribute causes calls within the attributed function to
3461	be inlined unless it is impossible to do so, for example if the body of the
3462	callee is unavailable or if the callee has the `noinline` attribute.)reST";
3463
3464	static const char AttrDoc_Format[] = R"reST(Clang supports the `format` attribute, which indicates that the function
3465	accepts (among other possibilities) a `printf` or `scanf`-like format string
3466	and corresponding arguments or a `va_list` that contains these arguments.
3467
3468	Please see [GCC documentation about format attribute](http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html) to find details
3469	about attribute syntax.
3470
3471	Clang implements two kinds of checks with this attribute.
3472
3473	1. Clang checks that the function with the `format` attribute is called with
3474	a format string that uses format specifiers that are allowed, and that
3475	arguments match the format string. This is the `-Wformat` warning, it is
3476	on by default.
3477
3478	2. Clang checks that the format string argument is a literal string. This is
3479	the `-Wformat-nonliteral` warning, it is off by default.
3480
3481	Clang implements this mostly the same way as GCC, but there is a difference
3482	for functions that accept a `va_list` argument (for example, `vprintf`).
3483	GCC does not emit `-Wformat-nonliteral` warning for calls to such
3484	functions. Clang does not warn if the format string comes from a function
3485	parameter, where the function is annotated with a compatible attribute,
3486	otherwise it warns. For example:
3487
3488	```c
3489	__attribute__((__format__ (__scanf__, 1, 3)))
3490	void foo(const char* s, char *buf, ...) {
3491	va_list ap;
3492	va_start(ap, buf);
3493
3494	vprintf(s, ap); // warning: format string is not a string literal
3495	}
3496	```
3497
3498	In this case we warn because `s` contains a format string for a
3499	`scanf`-like function, but it is passed to a `printf`-like function.
3500
3501	If the attribute is removed, clang still warns, because the format string is
3502	not a string literal.
3503
3504	Another example:
3505
3506	```c
3507	__attribute__((__format__ (__printf__, 1, 3)))
3508	void foo(const char* s, char *buf, ...) {
3509	va_list ap;
3510	va_start(ap, buf);
3511
3512	vprintf(s, ap); // warning
3513	}
3514	```
3515
3516	In this case Clang does not warn because the format string `s` and
3517	the corresponding arguments are annotated. If the arguments are
3518	incorrect, the caller of `foo` will receive a warning.
3519
3520	As an extension to GCC's behavior, Clang accepts the `format` attribute on
3521	non-variadic functions. Clang checks non-variadic format functions for the same
3522	classes of issues that can be found on variadic functions, as controlled by the
3523	same warning flags, except that the types of formatted arguments is forced by
3524	the function signature. For example:
3525
3526	```c
3527	__attribute__((__format__(__printf__, 1, 2)))
3528	void fmt(const char s, const char a, int b);
3529
3530	void bar(void) {
3531	fmt("%s %i", "hello", 123); // OK
3532	fmt("%i %g", "hello", 123); // warning: arguments don't match format
3533	extern const char *fmt;
3534	fmt(fmt, "hello", 123); // warning: format string is not a string literal
3535	}
3536	```
3537
3538	When using the format attribute on a variadic function, the first data parameter
3539	\_must\_ be the index of the ellipsis in the parameter list. Clang will generate
3540	a diagnostic otherwise, as it wouldn't be possible to forward that argument list
3541	to `printf`-family functions. For instance, this is an error:
3542
3543	```c
3544	__attribute__((__format__(__printf__, 1, 2)))
3545	void fmt(const char *s, int b, ...);
3546	// ^ error: format attribute parameter 3 is out of bounds
3547	// (must be __printf__, 1, 3)
3548	```
3549
3550	Using the `format` attribute on a non-variadic function emits a GCC
3551	compatibility diagnostic.)reST";
3552
3553	static const char AttrDoc_FormatArg[] = R"reST(No documentation.)reST";
3554
3555	static const char AttrDoc_FormatMatches[] = R"reST(The `format` attribute is the basis for the enforcement of diagnostics in the
3556	`-Wformat` family, but it only handles the case where the format string is
3557	passed along with the arguments it is going to format. It cannot handle the case
3558	where the format string and the format arguments are passed separately from each
3559	other. For instance:
3560
3561	```c
3562	static const char *first_name;
3563	static double todays_temperature;
3564	static int wind_speed;
3565
3566	void say_hi(const char *fmt) {
3567	printf(fmt, first_name, todays_temperature);
3568	// ^ warning: format string is not a string literal
3569	printf(fmt, first_name, wind_speed);
3570	// ^ warning: format string is not a string literal
3571	}
3572
3573	int main() {
3574	say_hi("hello %s, it is %g degrees outside");
3575	say_hi("hello %s, it is %d degrees outside!");
3576	// ^ no diagnostic, but %d cannot format doubles
3577	}
3578	```
3579
3580	In this example, `fmt` is expected to format a `const char *` and a
3581	`double`, but these values are not passed to `say_hi`. Without the
3582	`format` attribute (which cannot apply in this case), the -Wformat-nonliteral
3583	diagnostic unnecessarily triggers in the body of `say_hi`, and incorrect
3584	`say_hi` call sites do not trigger a diagnostic.
3585
3586	To complement the `format` attribute, Clang also defines the
3587	`format_matches` attribute. Its syntax is similar to the `format`
3588	attribute's, but instead of taking the index of the first formatted value
3589	argument, it takes a C string literal with the expected specifiers:
3590
3591	```c
3592	static const char *first_name;
3593	static double todays_temperature;
3594	static int wind_speed;
3595
3596	__attribute__((__format_matches__(printf, 1, "%s %g")))
3597	void say_hi(const char *fmt) {
3598	printf(fmt, first_name, todays_temperature); // no dignostic
3599	printf(fmt, first_name, wind_speed); // warning: format specifies type 'int' but the argument has type 'double'
3600	}
3601
3602	int main() {
3603	say_hi("hello %s, it is %g degrees outside");
3604	say_hi("it is %g degrees outside, have a good day %s!");
3605	// warning: format specifies 'double' where 'const char *' is required
3606	// warning: format specifies 'const char *' where 'double' is required
3607	}
3608	```
3609
3610	The third argument to `format_matches` is expected to evaluate to a **C string
3611	literal** even when the format string would normally be a different type for the
3612	given flavor, like a `CFStringRef` or a `NSString *`.
3613
3614	The only requirement on the format string literal is that it has specifiers
3615	that are compatible with the arguments that will be used. It can contain
3616	arbitrary non-format characters. For instance, for the purposes of compile-time
3617	validation, `"%s scored %g%% on her test"` and `"%s%g"` are interchangeable
3618	as the format string argument. As a means of self-documentation, users may
3619	prefer the former when it provides a useful example of an expected format
3620	string.
3621
3622	In the implementation of a function with the `format_matches` attribute,
3623	format verification works as if the format string was identical to the one
3624	specified in the attribute.
3625
3626	```c
3627	__attribute__((__format_matches__(printf, 1, "%s %g")))
3628	void say_hi(const char *fmt) {
3629	printf(fmt, "person", 546);
3630	// ^ warning: format specifies type 'double' but the
3631	// argument has type 'int'
3632	// note: format string is defined here:
3633	// __attribute__((__format_matches__(printf, 1, "%s %g")))
3634	// ^~
3635	}
3636	```
3637
3638	At the call sites of functions with the `format_matches` attribute, format
3639	verification instead compares the two format strings to evaluate their
3640	equivalence. Each format flavor defines equivalence between format specifiers.
3641	Generally speaking, two specifiers are equivalent if they format the same type.
3642	For instance, in the `printf` flavor, `%2i` and `%-0.5d` are compatible.
3643	When `-Wformat-signedness` is disabled, `%d` and `%u` are compatible. For
3644	a negative example, `%ld` is incompatible with `%d`.
3645
3646	Do note the following un-obvious cases:
3647
3648	- Passing `NULL` as the format string does not trigger format diagnostics.
3649	- When the format string is not NULL, it cannot \_miss\_ specifiers, even in
3650	trailing positions. For instance, `%d` is not accepted when the required
3651	format is `%d %d %d`.
3652	- While checks for the `format` attribute tolerate sone size mismatches
3653	that standard argument promotion renders immaterial (such as formatting an
3654	`int` with `%hhd`, which specifies a `char`-sized integer), checks for
3655	`format_matches` require specified argument sizes to match exactly.
3656	- Format strings expecting a variable modifier (such as `%*s`) are
3657	incompatible with format strings that would itemize the variable modifiers
3658	(such as `%i %s`), even if the two specify ABI-compatible argument lists.
3659	- All pointer specifiers, modifiers aside, are mutually incompatible. For
3660	instance, `%s` is not compatible with `%p`, and `%p` is not compatible
3661	with `%n`, and `%hhn` is incompatible with `%s`, even if the pointers
3662	are ABI-compatible or identical on the selected platform. However, `%0.5s`
3663	is compatible with `%s`, since the difference only exists in modifier flags.
3664	This is not overridable with `-Wformat-pedantic` or its inverse, which
3665	control similar behavior in `-Wformat`.
3666
3667	At this time, clang implements `format_matches` only for format types in the
3668	`printf` family. This includes variants such as Apple's NSString format and
3669	the FreeBSD `kprintf`, but excludes `scanf`. Using a known but unsupported
3670	format silently fails in order to be compatible with other implementations that
3671	would support these formats.)reST";
3672
3673	static const char AttrDoc_FunctionReturnThunks[] = R"reST(The attribute `function_return` can replace return instructions with jumps to
3674	target-specific symbols. This attribute supports 2 possible values,
3675	corresponding to the values supported by the `-mfunction-return=` command
3676	line flag:
3677
3678	- `__attribute__((function_return("keep")))` to disable related transforms.
3679	This is useful for undoing global setting from `-mfunction-return=` locally
3680	for individual functions.
3681	- `__attribute__((function_return("thunk-extern")))` to replace returns with
3682	jumps, while NOT emitting the thunk.
3683
3684	The values `thunk` and `thunk-inline` from GCC are not supported.
3685
3686	The symbol used for `thunk-extern` is target specific:
3687	\* X86: `__x86_return_thunk`
3688
3689	As such, this function attribute is currently only supported on X86 targets.)reST";
3690
3691	static const char AttrDoc_GCCStruct[] = R"reST(The `ms_struct` and `gcc_struct` attributes request the compiler to enter a
3692	special record layout compatibility mode which mimics the layout of Microsoft or
3693	Itanium C++ ABI respectively. Obviously, if the current C++ ABI matches the
3694	requested ABI, the attribute does nothing. However, if it does not, annotated
3695	structure or class is laid out in a special compatibility mode, which slightly
3696	changes offsets for fields and bit-fields. The intention is to match the layout
3697	of the requested ABI for structures which only use C features.
3698
3699	Note that the default behavior can be controlled by `-mms-bitfields` and
3700	`-mno-ms-bitfields` switches and via `#pragma ms_struct`.
3701
3702	The primary difference is for bitfields, where the MS variant only packs
3703	adjacent fields into the same allocation unit if they have integral types
3704	of the same size, while the GCC/Itanium variant packs all fields in a bitfield
3705	tightly.)reST";
3706
3707	static const char AttrDoc_GNUInline[] = R"reST(The `gnu_inline` changes the meaning of `extern inline` to use GNU inline
3708	semantics, meaning:
3709
3710	- If any declaration that is declared `inline` is not declared `extern`,
3711	then the `inline` keyword is just a hint. In particular, an out-of-line
3712	definition is still emitted for a function with external linkage, even if all
3713	call sites are inlined, unlike in C99 and C++ inline semantics.
3714	- If all declarations that are declared `inline` are also declared
3715	`extern`, then the function body is present only for inlining and no
3716	out-of-line version is emitted.
3717
3718	Some important consequences: `static inline` emits an out-of-line
3719	version if needed, a plain `inline` definition emits an out-of-line version
3720	always, and an `extern inline` definition (in a header) followed by a
3721	(non-`extern`) `inline` declaration in a source file emits an out-of-line
3722	version of the function in that source file but provides the function body for
3723	inlining to all includers of the header.
3724
3725	Either `__GNUC_GNU_INLINE__` (GNU inline semantics) or
3726	`__GNUC_STDC_INLINE__` (C99 semantics) will be defined (they are mutually
3727	exclusive). If `__GNUC_STDC_INLINE__` is defined, then the `gnu_inline`
3728	function attribute can be used to get GNU inline semantics on a per function
3729	basis. If `__GNUC_GNU_INLINE__` is defined, then the translation unit is
3730	already being compiled with GNU inline semantics as the implied default. It is
3731	unspecified which macro is defined in a C++ compilation.
3732
3733	GNU inline semantics are the default behavior with `-std=gnu89`,
3734	`-std=c89`, `-fgnu89-inline`, or `-std=iso9899:199409`.)reST";
3735
3736	static const char AttrDoc_GuardedBy[] = R"reST(No documentation.)reST";
3737
3738	static const char AttrDoc_GuardedVar[] = R"reST(No documentation.)reST";
3739
3740	static const char AttrDoc_HIPManaged[] = R"reST(The `__managed__` attribute can be applied to a global variable declaration in HIP.
3741	A managed variable is emitted as an undefined global symbol in the device binary and is
3742	registered by `__hipRegisterManagedVar` in init functions. The HIP runtime allocates
3743	managed memory and uses it to define the symbol when loading the device binary.
3744	A managed variable can be accessed in both device and host code.)reST";
3745
3746	static const char AttrDoc_HLSLAppliedSemantic[] = R"reST()reST";
3747
3748	static const char AttrDoc_HLSLAssociatedResourceDecl[] = R"reST()reST";
3749
3750	static const char AttrDoc_HLSLColumnMajor[] = R"reST(The `row_major` and `column_major` keywords specify the memory layout
3751	of an HLSL matrix type.
3752
3753	- `row_major`: Matrices are stored in memory row-by-row.
3754	- `column_major`: Matrices are stored in memory column-by-column (default).
3755
3756	Example:
3757
3758	```hlsl
3759	row_major float2x2 myMatrix;
3760	```)reST";
3761
3762	static const char AttrDoc_HLSLContainedType[] = R"reST(The ``hlsl::contained_type`` attribute specifies the type of the HLSL resource
3763	represented by a member variable of type ``__hlsl_resource_t``.
3764
3765	This attribute is only valid for resource handles, and is an implementation
3766	detail of clang's HLSL implementation. For more information see `HLSL Resource
3767	Types`_
3768
3769	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3770
3771	static const char AttrDoc_HLSLControlFlowHint[] = R"reST(The ``branch`` and ``flatten`` attributes can be applied to if and switch
3772	statements in the HLSL language mode to provide hints for how the backend
3773	should execute them.
3774
3775	- ``branch`` means that control flow is preferred. The condition should be
3776	evaluated first and we should only execute the block guarded by it.
3777
3778	- ``flatten`` means that control flow should be avoided. All blocks should be
3779	executed and variables that are modified should be conditionally assigned.
3780
3781	These control flow hints are preserved through the compilation and emitted in a
3782	backend-specific way.
3783
3784	For details, see the Direct3D documentation for `if Statement`_ and `switch Statement`_.
3785
3786	.. _`if Statement`: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-if
3787	.. _`switch Statement`: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-switchhttps://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-switch)reST";
3788
3789	static const char AttrDoc_HLSLGroupSharedAddressSpace[] = R"reST(HLSL enables threads of a compute shader to exchange values via shared memory.
3790	HLSL provides barrier primitives such as GroupMemoryBarrierWithGroupSync,
3791	and so on to ensure the correct ordering of reads and writes to shared memory
3792	in the shader and to avoid data races.
3793	Here's an example to declare a groupshared variable.
3794
3795	```c++
3796	groupshared GSData data[551];
3797	```
3798
3799	The full documentation is available here: <https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-syntax#group-shared>)reST";
3800
3801	static const char AttrDoc_HLSLIsArray[] = R"reST(The ``hlsl::is_array`` attribute specifies that the HLSL resource represented
3802	by a member variable of type ``__hlsl_resource_t`` has array dimensions.
3803
3804	This attribute is only valid for resource handles, and is an implementation
3805	detail of clang's HLSL implementation. For more information see `HLSL Resource
3806	Types`_
3807
3808	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3809
3810	static const char AttrDoc_HLSLIsCounter[] = R"reST(The ``hlsl::is_counter`` attribute specifies that the HLSL resource represented
3811	by a member variable of type ``__hlsl_resource_t`` is a counter buffer.
3812
3813	This attribute is only valid for resource handles, and is an implementation
3814	detail of clang's HLSL implementation. For more information see `HLSL Resource
3815	Types`_
3816
3817	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3818
3819	static const char AttrDoc_HLSLIsMultiSampled[] = R"reST(The ``hlsl::is_array`` attribute specifies that the HLSL resource represented
3820	by a member variable of type ``__hlsl_resource_t`` is multisampled.
3821
3822	This attribute is only valid for resource handles, and is an implementation
3823	detail of clang's HLSL implementation. For more information see `HLSL Resource
3824	Types`_
3825
3826	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3827
3828	static const char AttrDoc_HLSLIsROV[] = R"reST(The ``hlsl::is_rov`` attribute specifies that the HLSL resource represented by
3829	a member variable of type ``__hlsl_resource_t`` is a rasterizer ordered view.
3830
3831	This attribute is only valid for resource handles, and is an implementation
3832	detail of clang's HLSL implementation. For more information see `HLSL Resource
3833	Types`_
3834
3835	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3836
3837	static const char AttrDoc_HLSLLoopHint[] = R"reST(The `[loop]` directive allows loop optimization hints to be
3838	specified for the subsequent loop. The directive allows unrolling to
3839	be disabled and is not compatible with [unroll(x)].
3840
3841	Specifying the parameter, `[loop]`, directs the
3842	unroller to not unroll the loop.
3843
3844	```hlsl
3845	[loop]
3846	for (...) {
3847	...
3848	}
3849	```
3850
3851	```hlsl
3852	[loop]
3853	while (...) {
3854	...
3855	}
3856	```
3857
3858	```hlsl
3859	[loop]
3860	do {
3861	...
3862	} while (...)
3863	```
3864
3865	See [hlsl loop extensions](https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-for)
3866	for details.)reST";
3867
3868	static const char AttrDoc_HLSLNumThreads[] = R"reST(The `numthreads` attribute applies to HLSL shaders where explcit thread counts
3869	are required. The `X`, `Y`, and `Z` values provided to the attribute
3870	dictate the thread id. Total number of threads executed is `X * Y * Z`.
3871
3872	The full documentation is available here: <https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sm5-attributes-numthreads>)reST";
3873
3874	static const char AttrDoc_HLSLPackOffset[] = R"reST(The packoffset attribute is used to change the layout of a cbuffer.
3875	Attribute spelling in HLSL is: `packoffset( c[Subcomponent][.component] )`.
3876	A subcomponent is a register number, which is an integer. A component is in the form of [.xyzw].
3877
3878	Examples:
3879
3880	```hlsl
3881	cbuffer A {
3882	float3 a : packoffset(c0.y);
3883	float4 b : packoffset(c4);
3884	}
3885	```
3886
3887	The full documentation is available here: <https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-packoffset>)reST";
3888
3889	static const char AttrDoc_HLSLParamModifier[] = R"reST(HLSL function parameters are passed by value. Parameter declarations support
3890	three qualifiers to denote parameter passing behavior. The three qualifiers are
3891	`in`, `out` and `inout`.
3892
3893	Parameters annotated with `in` or with no annotation are passed by value from
3894	the caller to the callee.
3895
3896	Parameters annotated with `out` are written to the argument after the callee
3897	returns (Note: arguments values passed into `out` parameters are not copied
3898	into the callee).
3899
3900	Parameters annotated with `inout` are copied into the callee via a temporary,
3901	and copied back to the argument after the callee returns.)reST";
3902
3903	static const char AttrDoc_HLSLParsedSemantic[] = R"reST()reST";
3904
3905	static const char AttrDoc_HLSLRawBuffer[] = R"reST(The ``hlsl::raw_buffer`` attribute specifies that the HLSL resource represented
3906	by a member variable of type ``__hlsl_resource_t`` has raw buffer semantics.
3907
3908	This attribute is only valid for resource handles, and is an implementation
3909	detail of clang's HLSL implementation. For more information see `HLSL Resource
3910	Types`_
3911
3912	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3913
3914	static const char AttrDoc_HLSLResourceBinding[] = R"reST(The resource binding attribute sets the virtual register and logical register space for a resource.
3915	Attribute spelling in HLSL is: `register(slot [, space])`.
3916	`slot` takes the format `[type][number]`,
3917	where `type` is a single character specifying the resource type and `number` is the virtual register number.
3918
3919	Register types are:
3920	t for shader resource views (SRV),
3921	s for samplers,
3922	u for unordered access views (UAV),
3923	b for constant buffer views (CBV).
3924
3925	Register space is specified in the format `space[number]` and defaults to `space0` if omitted.
3926	Here're resource binding examples with and without space:
3927
3928	```hlsl
3929	RWBuffer<float> Uav : register(u3, space1);
3930	Buffer<float> Buf : register(t1);
3931	```
3932
3933	The full documentation is available here: <https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl>)reST";
3934
3935	static const char AttrDoc_HLSLResourceClass[] = R"reST(The ``hlsl::resource_class`` attribute specifies the resource class of the HLSL
3936	resource represented by a member variable of type ``__hlsl_resource_t``,
3937	declaring it to be an SRV, UAV, CBuffer, or Sampler resource.
3938
3939	This attribute is only valid for resource handles, and is an implementation
3940	detail of clang's HLSL implementation. For more information see `HLSL Resource
3941	Types`_
3942
3943	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3944
3945	static const char AttrDoc_HLSLResourceDimension[] = R"reST(The ``hlsl::dimension`` attribute specifies the dimensions of the HLSL resource
3946	represented by a member variable of type ``__hlsl_resource_t``, declaring the
3947	resource to have Unknown, 1D, 2D, 3D, or Cube dimension.
3948
3949	This attribute is only valid for resource handles, and is an implementation
3950	detail of clang's HLSL implementation. For more information see `HLSL Resource
3951	Types`_
3952
3953	.. _`HLSL Resource Types`: https://clang.llvm.org/docs/HLSL/ResourceTypes.html>)reST";
3954
3955	static const char AttrDoc_HLSLRowMajor[] = R"reST(The `row_major` and `column_major` keywords specify the memory layout
3956	of an HLSL matrix type.
3957
3958	- `row_major`: Matrices are stored in memory row-by-row.
3959	- `column_major`: Matrices are stored in memory column-by-column (default).
3960
3961	Example:
3962
3963	```hlsl
3964	row_major float2x2 myMatrix;
3965	```)reST";
3966
3967	static const char AttrDoc_HLSLShader[] = R"reST(The `shader` type attribute applies to HLSL shader entry functions to
3968	identify the shader type for the entry function.
3969	The syntax is:
3970
3971	```text
3972	``[shader(string-literal)]``
3973	```
3974
3975	where the string literal is one of: "pixel", "vertex", "geometry", "hull",
3976	"domain", "compute", "raygeneration", "intersection", "anyhit", "closesthit",
3977	"miss", "callable", "mesh", "amplification". Normally the shader type is set
3978	by shader target with the `-T` option like `-Tps_6_1`. When compiling to a
3979	library target like `lib_6_3`, the shader type attribute can help the
3980	compiler to identify the shader type. It is mostly used by Raytracing shaders
3981	where shaders must be compiled into a library and linked at runtime.)reST";
3982
3983	static const char AttrDoc_HLSLUnparsedSemantic[] = R"reST()reST";
3984
3985	static const char AttrDoc_HLSLVkBinding[] = R"reST(The `[[vk::binding]]` attribute allows you to explicitly specify the descriptor
3986	set and binding for a resource when targeting SPIR-V. This is particularly
3987	useful when you need different bindings for SPIR-V and DXIL, as the `register`
3988	attribute can be used for DXIL-specific bindings.
3989
3990	The attribute takes two integer arguments: the binding and the descriptor set.
3991	The descriptor set is optional and defaults to 0 if not provided.
3992
3993	```c++
3994	// A structured buffer with binding 23 in descriptor set 102.
3995	[[vk::binding(23, 102)]] StructuredBuffer<float> Buf;
3996
3997	// A structured buffer with binding 14 in descriptor set 0.
3998	[[vk::binding(14)]] StructuredBuffer<float> Buf2;
3999
4000	// A cbuffer with binding 1 in descriptor set 2.
4001	[[vk::binding(1, 2)]] cbuffer MyCBuffer {
4002	float4x4 worldViewProj;
4003	};
4004	```)reST";
4005
4006	static const char AttrDoc_HLSLVkConstantId[] = R"reST(The `vk::constant_id` attribute specifies the id for a SPIR-V specialization
4007	constant. The attribute applies to const global scalar variables. The variable must be initialized with a C++11 constexpr.
4008	In SPIR-V, the
4009	variable will be replaced with an `OpSpecConstant` with the given id.
4010	The syntax is:
4011
4012	```text
4013	``[[vk::constant_id(<Id>)]] const T Name = <Init>``
4014	```)reST";
4015
4016	static const char AttrDoc_HLSLVkExtBuiltinInput[] = R"reST(Vulkan shaders have `Input` builtins. Those variables are externally
4017	initialized by the driver/pipeline, but each copy is private to the current
4018	lane.
4019
4020	Those builtins can be declared using the `[[vk::ext_builtin_input]]` attribute
4021	like follows:
4022
4023	```c++
4024	[[vk::ext_builtin_input(/* WorkgroupId */ 26)]]
4025	static const uint3 groupid;
4026	```
4027
4028	This variable will be lowered into a module-level variable, with the `Input`
4029	storage class, and the `BuiltIn 26` decoration.
4030
4031	The full documentation for this inline SPIR-V attribute can be found here:
4032	<https://github.com/microsoft/hlsl-specs/blob/main/proposals/0011-inline-spirv.md>)reST";
4033
4034	static const char AttrDoc_HLSLVkExtBuiltinOutput[] = R"reST(Vulkan shaders have `Output` builtins. Those variables are externally
4035	visible to the driver/pipeline, but each copy is private to the current
4036	lane.
4037
4038	Those builtins can be declared using the `[[vk::ext_builtin_output]]`
4039	attribute like follows:
4040
4041	```c++
4042	[[vk::ext_builtin_output(/* Position */ 0)]]
4043	static float4 position;
4044	```
4045
4046	This variable will be lowered into a module-level variable, with the `Output`
4047	storage class, and the `BuiltIn 0` decoration.
4048
4049	The full documentation for this inline SPIR-V attribute can be found here:
4050	<https://github.com/microsoft/hlsl-specs/blob/main/proposals/0011-inline-spirv.md>)reST";
4051
4052	static const char AttrDoc_HLSLVkLocation[] = R"reST(Attribute used for specifying the location number for the stage input/output
4053	variables. Allowed on function parameters, function returns, and struct
4054	fields. This parameter has no effect when used outside of an entrypoint
4055	parameter/parameter field/return value.
4056
4057	This attribute maps to the 'Location' SPIR-V decoration.)reST";
4058
4059	static const char AttrDoc_HLSLVkPushConstant[] = R"reST(Vulkan shaders have `PushConstants`
4060
4061	The `[[vk::push_constant]]` attribute allows you to declare this
4062	global variable as a push constant when targeting Vulkan.
4063	This attribute is ignored otherwise.
4064
4065	This attribute must be applied to the variable, not underlying type.
4066	The variable type must be a struct, per the requirements of Vulkan, "there
4067	must be no more than one push constant block statically used per shader entry
4068	point.")reST";
4069
4070	static const char AttrDoc_HLSLWaveSize[] = R"reST(The `WaveSize` attribute specify a wave size on a shader entry point in order
4071	to indicate either that a shader depends on or strongly prefers a specific wave
4072	size.
4073	There're 2 versions of the attribute: `WaveSize` and `RangedWaveSize`.
4074	The syntax for `WaveSize` is:
4075
4076	```text
4077	``[WaveSize(<numLanes>)]``
4078	```
4079
4080	The allowed wave sizes that an HLSL shader may specify are the powers of 2
4081	between 4 and 128, inclusive.
4082	In other words, the set: [4, 8, 16, 32, 64, 128].
4083
4084	The syntax for `RangedWaveSize` is:
4085
4086	```text
4087	``[WaveSize(<minWaveSize>, <maxWaveSize>, [prefWaveSize])]``
4088	```
4089
4090	Where minWaveSize is the minimum wave size supported by the shader representing
4091	the beginning of the allowed range, maxWaveSize is the maximum wave size
4092	supported by the shader representing the end of the allowed range, and
4093	prefWaveSize is the optional preferred wave size representing the size expected
4094	to be the most optimal for this shader.
4095
4096	`WaveSize` is available for HLSL shader model 6.6 and later.
4097	`RangedWaveSize` available for HLSL shader model 6.8 and later.
4098
4099	The full documentation is available here: <https://microsoft.github.io/DirectX-Specs/d3d/HLSL_SM_6_6_WaveSize.html>
4100	and <https://microsoft.github.io/hlsl-specs/proposals/0013-wave-size-range.html>)reST";
4101
4102	static const char AttrDoc_Hot[] = R"reST(`__attribute__((hot))` marks a function as hot, as a manual alternative to PGO hotness data.
4103	If PGO data is available, the annotation `__attribute__((hot))` overrides the profile count based hotness (unlike `__attribute__((cold))`).)reST";
4104
4105	static const char AttrDoc_HybridPatchable[] = R"reST(The `hybrid_patchable` attribute declares an ARM64EC function with an additional
4106	x86-64 thunk, which may be patched at runtime.
4107
4108	For more information see
4109	[ARM64EC ABI documentation](https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi).)reST";
4110
4111	static const char AttrDoc_IBAction[] = R"reST(No documentation.)reST";
4112
4113	static const char AttrDoc_IBOutlet[] = R"reST(No documentation.)reST";
4114
4115	static const char AttrDoc_IBOutletCollection[] = R"reST(No documentation.)reST";
4116
4117	static const char AttrDoc_IFunc[] = R"reST(`__attribute__((ifunc("resolver")))` is used to mark that the address of a
4118	declaration should be resolved at runtime by calling a resolver function.
4119
4120	The symbol name of the resolver function is given in quotes. A function with
4121	this name (after mangling) must be defined in the current translation unit; it
4122	may be `static`. The resolver function should return a pointer.
4123
4124	The `ifunc` attribute may only be used on a function declaration. A function
4125	declaration with an `ifunc` attribute is considered to be a definition of the
4126	declared entity. The entity must not have weak linkage; for example, in C++,
4127	it cannot be applied to a declaration if a definition at that location would be
4128	considered inline.
4129
4130	Not all targets support this attribute:
4131
4132	- ELF target support depends on both the linker and runtime linker, and is
4133	available in at least lld 4.0 and later, binutils 2.20.1 and later, glibc
4134	v2.11.1 and later, and FreeBSD 9.1 and later.
4135	- Mach-O targets support it, but with slightly different semantics: the resolver
4136	is run at first call, instead of at load time by the runtime linker.
4137	- Windows target supports it on AArch64, but with different semantics: the
4138	`ifunc` is replaced with a global function pointer, and the call is replaced
4139	with an indirect call. The function pointer is initialized by a constructor
4140	that calls the resolver.
4141	- Baremetal target supports it on AVR.
4142	- AIX/XCOFF supports it via a compiler-only solution. An ifunc appears as a
4143	regular function (has an entry point `.foo[PR]` and a function descriptor
4144	`foo[DS]`). The entry point is a stub that branches to the function address
4145	in the descriptor, and the descriptor is initialized via a constructor
4146	function (`__init_ifuncs`) that is linked into every shared object and
4147	executable. `__init_ifuncs` calls the resolver of each ifunc and stores the
4148	result in the corresponding descriptor.
4149	- Other targets currently do not support this attribute.)reST";
4150
4151	static const char AttrDoc_InferredNoReturn[] = R"reST()reST";
4152
4153	static const char AttrDoc_InitPriority[] = R"reST(In C++, the order in which global variables are initialized across translation
4154	units is unspecified, unlike the ordering within a single translation unit. The
4155	`init_priority` attribute allows you to specify a relative ordering for the
4156	initialization of objects declared at namespace scope in C++ within a single
4157	linked image on supported platforms. The priority is given as an integer constant
4158	expression between 101 and 65535 (inclusive). Priorities outside of that range are
4159	reserved for use by the implementation. A lower value indicates a higher priority
4160	of initialization. Note that only the relative ordering of values is important.
4161	For example:
4162
4163	```c++
4164	struct SomeType { SomeType(); };
4165	__attribute__((init_priority(200))) SomeType Obj1;
4166	__attribute__((init_priority(101))) SomeType Obj2;
4167	```
4168
4169	`Obj2` will be initialized before `Obj1` despite the usual order of
4170	initialization being the opposite.
4171
4172	Note that this attribute does not control the initialization order of objects
4173	across final linked image boundaries like shared objects and executables.
4174
4175	On Windows, `init_seg(compiler)` is represented with a priority of 200 and
4176	`init_seg(library)` is represented with a priority of 400. `init_seg(user)`
4177	uses the default 65535 priority.
4178
4179	On MachO platforms, this attribute also does not control the order of initialization
4180	across translation units, where it only affects the order within a single TU.
4181
4182	This attribute is only supported for C++ and Objective-C++ and is ignored in
4183	other language modes.)reST";
4184
4185	static const char AttrDoc_InitSeg[] = R"reST(The attribute applied by `pragma init_seg()` controls the section into
4186	which global initialization function pointers are emitted. It is only
4187	available with `-fms-extensions`. Typically, this function pointer is
4188	emitted into `.CRT$XCU` on Windows. The user can change the order of
4189	initialization by using a different section name with the same
4190	`.CRT$XC` prefix and a suffix that sorts lexicographically before or
4191	after the standard `.CRT$XCU` sections. See the [init_seg][init_seg]
4192	documentation on MSDN for more information.
4193
4194	[init_seg]: http://msdn.microsoft.com/en-us/library/7977wcck(v=vs.110).aspx)reST";
4195
4196	static const char AttrDoc_IntelOclBicc[] = R"reST(No documentation.)reST";
4197
4198	static const char AttrDoc_InternalLinkage[] = R"reST(The `internal_linkage` attribute changes the linkage type of the declaration
4199	to internal. This is similar to C-style `static`, but can be used on classes
4200	and class methods. When applied to a class definition, this attribute affects
4201	all methods and static data members of that class. This can be used to contain
4202	the ABI of a C++ library by excluding unwanted class methods from the export
4203	tables.)reST";
4204
4205	static const char AttrDoc_LTOVisibilityPublic[] = R"reST(See {doc}`LTOVisibility`.)reST";
4206
4207	static const char AttrDoc_LayoutVersion[] = R"reST(The layout_version attribute requests that the compiler utilize the class
4208	layout rules of a particular compiler version.
4209	This attribute only applies to struct, class, and union types.
4210	It is only supported when using the Microsoft C++ ABI.)reST";
4211
4212	static const char AttrDoc_Leaf[] = R"reST(The `leaf` attribute is used as a compiler hint to improve dataflow analysis
4213	in library functions. Functions marked with the `leaf` attribute are not allowed
4214	to jump back into the caller's translation unit, whether through invoking a
4215	callback function, an external function call, use of `longjmp`, or other means.
4216	Therefore, they cannot use or modify any data that does not escape the caller function's
4217	compilation unit.
4218
4219	For more information see
4220	`gcc documentation <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html>`)reST";
4221
4222	static const char AttrDoc_LifetimeBound[] = R"reST(The `lifetimebound` attribute on a function parameter or implicit object
4223	parameter indicates that objects that are referred to by that parameter may
4224	also be referred to by the return value of the annotated function (or, for a
4225	parameter of a constructor, by the value of the constructed object).
4226
4227	By default, a reference is considered to refer to its referenced object, a
4228	pointer is considered to refer to its pointee, a `std::initializer_list<T>`
4229	is considered to refer to its underlying array, and aggregates (arrays and
4230	simple `struct`s) are considered to refer to all objects that their
4231	transitive subobjects refer to.
4232
4233	Clang warns if it is able to detect that an object or reference refers to
4234	another object with a shorter lifetime. For example, Clang will warn if a
4235	function returns a reference to a local variable, or if a reference is bound to
4236	a temporary object whose lifetime is not extended. By using the
4237	`lifetimebound` attribute, this determination can be extended to look through
4238	user-declared functions. For example:
4239
4240	```c++
4241	#include <map>
4242	#include <string>
4243
4244	using namespace std::literals;
4245
4246	// Returns m[key] if key is present, or default_value if not.
4247	template<typename T, typename U>
4248	const U &get_or_default(const std::map<T, U> &m [[clang::lifetimebound]],
4249	const T &key, /* note, not lifetimebound */
4250	const U &default_value [[clang::lifetimebound]]) {
4251	if (auto iter = m.find(key); iter != m.end()) return iter->second;
4252	else return default_value;
4253	}
4254
4255	int main() {
4256	std::map<std::string, std::string> m;
4257	// warning: temporary bound to local reference 'val1' will be destroyed
4258	// at the end of the full-expression
4259	const std::string &val1 = get_or_default(m, "foo"s, "bar"s);
4260
4261	// No warning in this case.
4262	std::string def_val = "bar"s;
4263	const std::string &val2 = get_or_default(m, "foo"s, def_val);
4264
4265	return 0;
4266	}
4267	```
4268
4269	The attribute can be applied to the implicit `this` parameter of a member
4270	function by writing the attribute after the function type:
4271
4272	```c++
4273	struct string {
4274	// The returned pointer should not outlive ``*this``.
4275	const char *data() const [[clang::lifetimebound]];
4276	};
4277	```
4278
4279	This attribute is inspired by the C++ committee paper [P0936R0](http://wg21.link/p0936r0), but does not affect whether temporary objects
4280	have their lifetimes extended.)reST";
4281
4282	static const char AttrDoc_LifetimeCaptureBy[] = R"reST(Similar to [lifetimebound], the `lifetime_capture_by` attribute family on a
4283	function parameter or implicit object parameter indicates that a capturing
4284	entity may refer to the object referred to by that parameter. The capturing
4285	entity can be named in `lifetime_capture_by(X)` or selected by one of the
4286	standalone special forms listed below.
4287
4288	Below is a list of types of the parameters and what they're considered to refer to:
4289
4290	- A reference param (of non-view type) is considered to refer to its referenced object.
4291	- A pointer param (of non-view type) is considered to refer to its pointee.
4292	- View type param (type annotated with `[[gsl::Pointer()]]`) is considered to refer
4293	to its pointee (gsl owner). This holds true even if the view type appears as a reference
4294	in the parameter. For example, both `std::string_view` and
4295	`const std::string_view &` are considered to refer to a `std::string`.
4296	- A `std::initializer_list<T>` is considered to refer to its underlying array.
4297	- Aggregates (arrays and simple `struct`s) are considered to refer to all
4298	objects that their transitive subobjects refer to.
4299
4300	Clang would diagnose when a temporary object is used as an argument to such an
4301	annotated parameter.
4302	In this case, the capturing entity `X` could capture a dangling reference to this
4303	temporary object.
4304
4305	```c++
4306	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s) {
4307	s.insert(a);
4308	}
4309	void use() {
4310	std::set<std::string_view> s;
4311	addToSet(std::string(), s); // Warning: object whose reference is captured by 's' will be destroyed at the end of the full-expression.
4312	// ^^^^^^^^^^^^^
4313	std::string local;
4314	addToSet(local, s); // Ok.
4315	}
4316	```
4317
4318	The capturing entity can be one of the following:
4319
4320	- Another (named) function parameter.
4321
4322	```c++
4323	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s) {
4324	s.insert(a);
4325	}
4326	```
4327
4328	- `this` (in case of member functions), written as
4329	`lifetime_capture_by_this`.
4330
4331	```c++
4332	class S {
4333	void addToSet(std::string_view a [[clang::lifetime_capture_by_this]]) {
4334	s.insert(a);
4335	}
4336	std::set<std::string_view> s;
4337	};
4338	```
4339
4340	Note: When applied to a constructor parameter, `[[clang::lifetime_capture_by_this]]` is just an alias of `[[clang::lifetimebound]]`.
4341
4342	- `global` and `unknown`, written as `lifetime_capture_by_global` and
4343	`lifetime_capture_by_unknown` respectively.
4344
4345	```c++
4346	std::set<std::string_view> s;
4347	void addToSet(std::string_view a [[clang::lifetime_capture_by_global]]) {
4348	s.insert(a);
4349	}
4350	void addSomewhere(std::string_view a [[clang::lifetime_capture_by_unknown]]);
4351	```
4352
4353	The attribute can be applied to the implicit `this` parameter of a member
4354	function by writing the attribute after the function type:
4355
4356	```c++
4357	struct S {
4358	const char data(std::set<S>& s) [[clang::lifetime_capture_by(s)]] {
4359	s.insert(this);
4360	}
4361	};
4362	```
4363
4364	The parameter-list form supports specifying more than one capturing entity:
4365
4366	```c++
4367	void addToSets(std::string_view a [[clang::lifetime_capture_by(s1, s2)]],
4368	std::set<std::string_view>& s1,
4369	std::set<std::string_view>& s2) {
4370	s1.insert(a);
4371	s2.insert(a);
4372	}
4373	```
4374
4375	Distinct `lifetime_capture_by` forms can also be combined on the same
4376	declaration, but each form can appear at most once. For example,
4377	`[[clang::lifetime_capture_by(s), clang::lifetime_capture_by_this]]` is
4378	allowed, but two `[[clang::lifetime_capture_by(...)]]` attributes or two
4379	`[[clang::lifetime_capture_by_this]]` attributes on the same declaration are
4380	rejected.
4381
4382	Limitation: The capturing entity `X` is not used by the analysis and is
4383	used for documentation purposes only. This is because the analysis is
4384	statement-local and only detects use of a temporary as an argument to the
4385	annotated parameter.
4386
4387	```c++
4388	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s);
4389	void use() {
4390	std::set<std::string_view> s;
4391	if (foo()) {
4392	std::string str;
4393	addToSet(str, s); // Not detected.
4394	}
4395	}
4396	```)reST";
4397
4398	static const char AttrDoc_Likely[] = R"reST(The `likely` and `unlikely` attributes are used as compiler hints.
4399	The attributes are used to aid the compiler to determine which branch is
4400	likely or unlikely to be taken. This is done by marking the branch substatement
4401	with one of the two attributes.
4402
4403	It isn't allowed to annotate a single statement with both `likely` and
4404	`unlikely`. Annotating the `true` and `false` branch of an `if`
4405	statement with the same likelihood attribute will result in a diagnostic and
4406	the attributes are ignored on both branches.
4407
4408	In a `switch` statement it's allowed to annotate multiple `case` labels
4409	or the `default` label with the same likelihood attribute. This makes
4410	\* all labels without an attribute have a neutral likelihood,
4411	\* all labels marked `[[likely]]` have an equally positive likelihood, and
4412	\* all labels marked `[[unlikely]]` have an equally negative likelihood.
4413	The neutral likelihood is the more likely of path execution than the negative
4414	likelihood. The positive likelihood is the more likely of path of execution
4415	than the neutral likelihood.
4416
4417	These attributes have no effect on the generated code when using
4418	PGO (Profile-Guided Optimization) or at optimization level 0.
4419
4420	In Clang, the attributes will be ignored if they're not placed on
4421	\* the `case` or `default` label of a `switch` statement,
4422	\* or on the substatement of an `if` or `else` statement,
4423	\* or on the substatement of an `for` or `while` statement.
4424	The C++ Standard recommends to honor them on every statement in the
4425	path of execution, but that can be confusing:
4426
4427	```c++
4428	if (b) {
4429	[[unlikely]] --b; // Per the standard this is in the path of
4430	// execution, so this branch should be considered
4431	// unlikely. However, Clang ignores the attribute
4432	// here since it is not on the substatement.
4433	}
4434
4435	if (b) {
4436	--b;
4437	if(b)
4438	return;
4439	[[unlikely]] --b; // Not in the path of execution,
4440	} // the branch has no likelihood information.
4441
4442	if (b) {
4443	--b;
4444	foo(b);
4445	// Whether or not the next statement is in the path of execution depends
4446	// on the declaration of foo():
4447	// In the path of execution: void foo(int);
4448	// Not in the path of execution: [[noreturn]] void foo(int);
4449	// This means the likelihood of the branch depends on the declaration
4450	// of foo().
4451	[[unlikely]] --b;
4452	}
4453	```
4454
4455	Below are some example usages of the likelihood attributes and their effects:
4456
4457	```c++
4458	if (b) [[likely]] { // Placement on the first statement in the branch.
4459	// The compiler will optimize to execute the code here.
4460	} else {
4461	}
4462
4463	if (b)
4464	[[unlikely]] b++; // Placement on the first statement in the branch.
4465	else {
4466	// The compiler will optimize to execute the code here.
4467	}
4468
4469	if (b) {
4470	[[unlikely]] b++; // Placement on the second statement in the branch.
4471	} // The attribute will be ignored.
4472
4473	if (b) [[likely]] {
4474	[[unlikely]] b++; // No contradiction since the second attribute
4475	} // is ignored.
4476
4477	if (b)
4478	;
4479	else [[likely]] {
4480	// The compiler will optimize to execute the code here.
4481	}
4482
4483	if (b)
4484	;
4485	else
4486	// The compiler will optimize to execute the next statement.
4487	[[likely]] b = f();
4488
4489	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
4490	else [[likely]]; // and the attributes are ignored.
4491
4492	if (b)
4493	[[likely]] int i = 5; // Issues a diagnostic since the attribute
4494	// isn't allowed on a declaration.
4495
4496	switch (i) {
4497	[[likely]] case 1: // This value is likely
4498	...
4499	break;
4500
4501	[[unlikely]] case 2: // This value is unlikely
4502	...
4503	[[fallthrough]];
4504
4505	case 3: // No likelihood attribute
4506	...
4507	[[likely]] break; // No effect
4508
4509	case 4: [[likely]] { // attribute on substatement has no effect
4510	...
4511	break;
4512	}
4513
4514	[[unlikely]] default: // All other values are unlikely
4515	...
4516	break;
4517	}
4518
4519	switch (i) {
4520	[[likely]] case 0: // This value and code path is likely
4521	...
4522	[[fallthrough]];
4523
4524	case 1: // No likelihood attribute, code path is neutral
4525	break; // falling through has no effect on the likelihood
4526
4527	case 2: // No likelihood attribute, code path is neutral
4528	[[fallthrough]];
4529
4530	[[unlikely]] default: // This value and code path are both unlikely
4531	break;
4532	}
4533
4534	for(int i = 0; i != size; ++i) [[likely]] {
4535	... // The loop is the likely path of execution
4536	}
4537
4538	for(const auto &E : Elements) [[likely]] {
4539	... // The loop is the likely path of execution
4540	}
4541
4542	while(i != size) [[unlikely]] {
4543	... // The loop is the unlikely path of execution
4544	} // The generated code will optimize to skip the loop body
4545
4546	while(true) [[unlikely]] {
4547	... // The attribute has no effect
4548	} // Clang elides the comparison and generates an infinite
4549	// loop
4550	```)reST";
4551
4552	static const char AttrDoc_LoaderUninitialized[] = R"reST(The `loader_uninitialized` attribute can be placed on global variables to
4553	indicate that the variable does not need to be zero initialized by the loader.
4554	On most targets, zero-initialization does not incur any additional cost.
4555	For example, most general purpose operating systems deliberately ensure
4556	that all memory is properly initialized in order to avoid leaking privileged
4557	information from the kernel or other programs. However, some targets
4558	do not make this guarantee, and on these targets, avoiding an unnecessary
4559	zero-initialization can have a significant impact on load times and/or code
4560	size.
4561
4562	A declaration with this attribute is a non-tentative definition just as if it
4563	provided an initializer. Variables with this attribute are considered to be
4564	uninitialized in the same sense as a local variable, and the programs must
4565	write to them before reading from them. If the variable's type is a C++ class
4566	type with a non-trivial default constructor, or an array thereof, this attribute
4567	only suppresses the static zero-initialization of the variable, not the dynamic
4568	initialization provided by executing the default constructor.)reST";
4569
4570	static const char AttrDoc_LockReturned[] = R"reST(No documentation.)reST";
4571
4572	static const char AttrDoc_LocksExcluded[] = R"reST(No documentation.)reST";
4573
4574	static const char AttrDoc_LoopHint[] = R"reST(The `#pragma clang loop` directive allows loop optimization hints to be
4575	specified for the subsequent loop. The directive allows pipelining to be
4576	disabled, or vectorization, vector predication, interleaving, and unrolling to
4577	be enabled or disabled. Vector width, vector predication, interleave count,
4578	unrolling count, and the initiation interval for pipelining can be explicitly
4579	specified. See
4580	{ref}`loop hint optimizations <langext-loop-hint-optimizations>` for details.)reST";
4581
4582	static const char AttrDoc_M68kInterrupt[] = R"reST(No documentation.)reST";
4583
4584	static const char AttrDoc_M68kRTD[] = R"reST(On M68k targets, this attribute changes the calling convention of a function
4585	to clear parameters off the stack on return. In other words, callee is
4586	responsible for cleaning out the stack space allocated for incoming paramters.
4587	This convention does not support variadic calls or unprototyped functions in C.
4588	When targeting M68010 or newer CPUs, this calling convention is implemented
4589	using the `rtd` instruction.)reST";
4590
4591	static const char AttrDoc_MIGServerRoutine[] = R"reST(The Mach Interface Generator release-on-success convention dictates
4592
4593	functions that follow it to only release arguments passed to them when they
4594	return "success" (a `kern_return_t` error code that indicates that
4595	no errors have occurred). Otherwise the release is performed by the MIG client
4596	that called the function. The annotation `__attribute__((mig_server_routine))`
4597	is applied in order to specify which functions are expected to follow the
4598	convention. This allows the Static Analyzer to find bugs caused by violations of
4599	that convention. The attribute would normally appear on the forward declaration
4600	of the actual server routine in the MIG server header, but it may also be
4601	added to arbitrary functions that need to follow the same convention - for
4602	example, a user can add them to auxiliary functions called by the server routine
4603	that have their return value of type `kern_return_t` unconditionally returned
4604	from the routine. The attribute can be applied to C++ methods, and in this case
4605	it will be automatically applied to overrides if the method is virtual. The
4606	attribute can also be written using C++11 syntax: `[[mig::server_routine]]`.)reST";
4607
4608	static const char AttrDoc_MSABI[] = R"reST(On non-Windows x86_64 and aarch64 targets, this attribute changes the calling convention of
4609	a function to match the default convention used on Windows. This
4610	attribute has no effect on Windows targets or non-x86_64, non-aarch64 targets.)reST";
4611
4612	static const char AttrDoc_MSAllocator[] = R"reST(The `__declspec(allocator)` attribute is applied to functions that allocate
4613	memory, such as operator new in C++. When CodeView debug information is emitted
4614	(enabled by `clang -gcodeview` or `clang-cl /Z7`), Clang will attempt to
4615	record the code offset of heap allocation call sites in the debug info. It will
4616	also record the type being allocated using some local heuristics. The Visual
4617	Studio debugger uses this information to [profile memory usage][profile memory usage].
4618
4619	This attribute does not affect optimizations in any way, unlike GCC's
4620	`__attribute__((malloc))`.
4621
4622	[profile memory usage]: https://docs.microsoft.com/en-us/visualstudio/profiling/memory-usage)reST";
4623
4624	static const char AttrDoc_MSConstexpr[] = R"reST(The `[[msvc::constexpr]]` attribute can be applied only to a function
4625	definition or a `return` statement. It does not impact function declarations.
4626	A `[[msvc::constexpr]]` function cannot be `constexpr` or `consteval`.
4627	A `[[msvc::constexpr]]` function is treated as if it were a `constexpr` function
4628	when it is evaluated in a constant context of `[[msvc::constexpr]] return` statement.
4629	Otherwise, it is treated as a regular function.
4630
4631	Semantics of this attribute are enabled only under MSVC compatibility
4632	(`-fms-compatibility-version`) 19.33 and later.)reST";
4633
4634	static const char AttrDoc_MSInheritance[] = R"reST(This collection of keywords is enabled under `-fms-extensions` and controls
4635	the pointer-to-member representation used on `--win32` targets.
4636
4637	The `--win32` targets utilize a pointer-to-member representation which
4638	varies in size and alignment depending on the definition of the underlying
4639	class.
4640
4641	However, this is problematic when a forward declaration is only available and
4642	no definition has been made yet. In such cases, Clang is forced to utilize the
4643	most general representation that is available to it.
4644
4645	These keywords make it possible to use a pointer-to-member representation other
4646	than the most general one regardless of whether or not the definition will ever
4647	be present in the current translation unit.
4648
4649	This family of keywords belong between the `class-key` and `class-name`:
4650
4651	```c++
4652	struct __single_inheritance S;
4653	int S::*i;
4654	struct S {};
4655	```
4656
4657	This keyword can be applied to class templates but only has an effect when used
4658	on full specializations:
4659
4660	```c++
4661	template <typename T, typename U> struct __single_inheritance A; // warning: inheritance model ignored on primary template
4662	template <typename T> struct __multiple_inheritance A<T, T>; // warning: inheritance model ignored on partial specialization
4663	template <> struct __single_inheritance A<int, float>;
4664	```
4665
4666	Note that choosing an inheritance model less general than strictly necessary is
4667	an error:
4668
4669	```c++
4670	struct __multiple_inheritance S; // error: inheritance model does not match definition
4671	int S::*i;
4672	struct S {};
4673	```)reST";
4674
4675	static const char AttrDoc_MSNoVTable[] = R"reST(This attribute can be added to a class declaration or definition to signal to
4676	the compiler that constructors and destructors will not reference the virtual
4677	function table. It is only supported when using the Microsoft C++ ABI.)reST";
4678
4679	static const char AttrDoc_MSP430Interrupt[] = R"reST(No documentation.)reST";
4680
4681	static const char AttrDoc_MSStruct[] = R"reST(The `ms_struct` and `gcc_struct` attributes request the compiler to enter a
4682	special record layout compatibility mode which mimics the layout of Microsoft or
4683	Itanium C++ ABI respectively. Obviously, if the current C++ ABI matches the
4684	requested ABI, the attribute does nothing. However, if it does not, annotated
4685	structure or class is laid out in a special compatibility mode, which slightly
4686	changes offsets for fields and bit-fields. The intention is to match the layout
4687	of the requested ABI for structures which only use C features.
4688
4689	Note that the default behavior can be controlled by `-mms-bitfields` and
4690	`-mno-ms-bitfields` switches and via `#pragma ms_struct`.
4691
4692	The primary difference is for bitfields, where the MS variant only packs
4693	adjacent fields into the same allocation unit if they have integral types
4694	of the same size, while the GCC/Itanium variant packs all fields in a bitfield
4695	tightly.)reST";
4696
4697	static const char AttrDoc_MSVtorDisp[] = R"reST()reST";
4698
4699	static const char AttrDoc_MallocSpan[] = R"reST(The `malloc_span` attribute can be used to mark that a function which acts
4700	like a system memory allocation function and returns a span-like structure,
4701	where the returned memory range does not alias storage from any other object
4702	accessible to the caller.
4703
4704	In this context, a span-like structure is assumed to have two non-static data
4705	members, one of which is a pointer to the start of the allocated memory and
4706	the other one is either an integer type containing the size of the actually
4707	allocated memory or a pointer to the end of the allocated region. Note, static
4708	data members do not impact whether a type is span-like or not.
4709
4710	In combination with the `alloc_size` attribute, if the begin pointer is
4711	non-null, the size of the returned span-like object has to be greater or equal
4712	to the number of bytes guaranteed to be dereferenceable by `alloc_size`. It also
4713	guarantees that the number of dereferenceable bytes is at least size.)reST";
4714
4715	static const char AttrDoc_MaxFieldAlignment[] = R"reST()reST";
4716
4717	static const char AttrDoc_MayAlias[] = R"reST(No documentation.)reST";
4718
4719	static const char AttrDoc_MaybeUndef[] = R"reST(The `maybe_undef` attribute can be placed on a function parameter. It indicates
4720	that the parameter is allowed to use undef values. It informs the compiler
4721	to insert a freeze LLVM IR instruction on the function parameter.
4722	Please note that this is an attribute that is used as an internal
4723	implementation detail and not intended to be used by external users.
4724
4725	In languages HIP, CUDA etc., some functions have multi-threaded semantics and
4726	it is enough for only one or some threads to provide defined arguments.
4727	Depending on semantics, undef arguments in some threads don't produce
4728	undefined results in the function call. Since, these functions accept undefined
4729	arguments, `maybe_undef` attribute can be placed.
4730
4731	Sample usage:
4732
4733	```c
4734	void maybeundeffunc(int __attribute__((maybe_undef))param);
4735	```)reST";
4736
4737	static const char AttrDoc_MicroMips[] = R"reST(Clang supports the GNU style `__attribute__((micromips))` and
4738	`__attribute__((nomicromips))` attributes on MIPS targets. These attributes
4739	may be attached to a function definition and instructs the backend to generate
4740	or not to generate microMIPS code for that function.
4741
4742	These attributes override the `-mmicromips` and `-mno-micromips` options
4743	on the command line.)reST";
4744
4745	static const char AttrDoc_MinSize[] = R"reST(This function attribute indicates that optimization passes and code generator passes
4746	make choices that keep the function code size as small as possible. Optimizations may
4747	also sacrifice runtime performance in order to minimize the size of the generated code.)reST";
4748
4749	static const char AttrDoc_MinVectorWidth[] = R"reST(Clang supports the `__attribute__((min_vector_width(width)))` attribute. This
4750	attribute may be attached to a function and informs the backend that this
4751	function desires vectors of at least this width to be generated. Target-specific
4752	maximum vector widths still apply. This means even if you ask for something
4753	larger than the target supports, you will only get what the target supports.
4754	This attribute is meant to be a hint to control target heuristics that may
4755	generate narrower vectors than what the target hardware supports.
4756
4757	This is currently used by the X86 target to allow some CPUs that support 512-bit
4758	vectors to be limited to using 256-bit vectors to avoid frequency penalties.
4759	This is currently enabled with the `-prefer-vector-width=256` command line
4760	option. The `min_vector_width` attribute can be used to prevent the backend
4761	from trying to split vector operations to match the `prefer-vector-width`. All
4762	X86 vector intrinsics from x86intrin.h already set this attribute. Additionally,
4763	use of any of the X86-specific vector builtins will implicitly set this
4764	attribute on the calling function. The intent is that explicitly writing vector
4765	code using the X86 intrinsics will prevent `prefer-vector-width` from
4766	affecting the code.)reST";
4767
4768	static const char AttrDoc_Mips16[] = R"reST(No documentation.)reST";
4769
4770	static const char AttrDoc_MipsInterrupt[] = R"reST(Clang supports the GNU style `__attribute__((interrupt("ARGUMENT")))` attribute on
4771	MIPS targets. This attribute may be attached to a function definition and instructs
4772	the backend to generate appropriate function entry/exit code so that it can be used
4773	directly as an interrupt service routine.
4774
4775	By default, the compiler will produce a function prologue and epilogue suitable for
4776	an interrupt service routine that handles an External Interrupt Controller (eic)
4777	generated interrupt. This behavior can be explicitly requested with the "eic"
4778	argument.
4779
4780	Otherwise, for use with vectored interrupt mode, the argument passed should be
4781	of the form "vector=LEVEL" where LEVEL is one of the following values:
4782	"sw0", "sw1", "hw0", "hw1", "hw2", "hw3", "hw4", "hw5". The compiler will
4783	then set the interrupt mask to the corresponding level which will mask all
4784	interrupts up to and including the argument.
4785
4786	The semantics are as follows:
4787
4788	- The prologue is modified so that the Exception Program Counter (EPC) and
4789	Status coprocessor registers are saved to the stack. The interrupt mask is
4790	set so that the function can only be interrupted by a higher priority
4791	interrupt. The epilogue will restore the previous values of EPC and Status.
4792	- The prologue and epilogue are modified to save and restore all non-kernel
4793	registers as necessary.
4794	- The FPU is disabled in the prologue, as the floating pointer registers are not
4795	spilled to the stack.
4796	- The function return sequence is changed to use an exception return instruction.
4797	- The parameter sets the interrupt mask for the function corresponding to the
4798	interrupt level specified. If no mask is specified the interrupt mask
4799	defaults to "eic".)reST";
4800
4801	static const char AttrDoc_MipsLongCall[] = R"reST(Clang supports the `__attribute__((long_call))`, `__attribute__((far))`,
4802	and `__attribute__((near))` attributes on MIPS targets. These attributes may
4803	only be added to function declarations and change the code generated
4804	by the compiler when directly calling the function. The `near` attribute
4805	allows calls to the function to be made using the `jal` instruction, which
4806	requires the function to be located in the same naturally aligned 256MB
4807	segment as the caller. The `long_call` and `far` attributes are synonyms
4808	and require the use of a different call sequence that works regardless
4809	of the distance between the functions.
4810
4811	These attributes have no effect for position-independent code.
4812
4813	These attributes take priority over command line switches such
4814	as `-mlong-calls` and `-mno-long-calls`.)reST";
4815
4816	static const char AttrDoc_MipsShortCall[] = R"reST(Clang supports the `__attribute__((long_call))`, `__attribute__((far))`,
4817	`__attribute__((short__call))`, and `__attribute__((near))` attributes
4818	on MIPS targets. These attributes may only be added to function declarations
4819	and change the code generated by the compiler when directly calling
4820	the function. The `short_call` and `near` attributes are synonyms and
4821	allow calls to the function to be made using the `jal` instruction, which
4822	requires the function to be located in the same naturally aligned 256MB segment
4823	as the caller. The `long_call` and `far` attributes are synonyms and
4824	require the use of a different call sequence that works regardless
4825	of the distance between the functions.
4826
4827	These attributes have no effect for position-independent code.
4828
4829	These attributes take priority over command line switches such
4830	as `-mlong-calls` and `-mno-long-calls`.)reST";
4831
4832	static const char AttrDoc_Mode[] = R"reST(No documentation.)reST";
4833
4834	static const char AttrDoc_ModularFormat[] = R"reST(The `modular_format` attribute can be applied to a function that bears the
4835	`format` attribute (or standard library functions) to indicate that the
4836	implementation is "modular", that is, that the implementation is logically
4837	divided into a number of named aspects. When the compiler can determine that
4838	not all aspects of the implementation are needed for a given call, the compiler
4839	may redirect the call to the identifier given as the first argument to the
4840	attribute (the modular implementation function).
4841
4842	The second argument is an implementation name, and the remaining arguments are
4843	aspects of the format string for the compiler to report. The implementation
4844	name is an unevaluated identifier in the C namespace.
4845
4846	The compiler reports that a call requires an aspect by issuing a relocation for
4847	the symbol `<impl_name>_<aspect>` at the point of the call. This arranges for
4848	code and data needed to support the aspect of the implementation to be brought
4849	into the link to satisfy weak references in the modular implemenation function.
4850	If the compiler does not understand an aspect, it must summarily consider any
4851	call to require that aspect.
4852
4853	For example, say `printf` is annotated with
4854	`modular_format(__modular_printf, "__printf", "float")`. Then, a call to
4855	`printf(var, 42)` would be untouched. A call to `printf("%d", 42)` would
4856	become a call to `__modular_printf` with the same arguments, as would
4857	`printf("%f", 42.0)`. The latter would be accompanied with a strong
4858	relocation against the symbol `__printf_float`, which would bring floating
4859	point support for `printf` into the link.
4860
4861	If the attribute appears more than once on a declaration, or across a chain of
4862	redeclarations, it is an error for the attributes to have different arguments,
4863	excepting that the aspects may be in any order.
4864
4865	The following aspects are currently supported:
4866
4867	- `fixed`: The call has a C ISO 18037 fixed-point argument.
4868	- `float`: The call has a floating-point argument.)reST";
4869
4870	static const char AttrDoc_MustTail[] = R"reST(If a `return` statement is marked `musttail`, this indicates that the
4871	compiler must generate a tail call for the program to be correct, even when
4872	optimizations are disabled. This guarantees that the call will not cause
4873	unbounded stack growth if it is part of a recursive cycle in the call graph.
4874
4875	If the callee is a virtual function that is implemented by a thunk, there is
4876	no guarantee in general that the thunk tail-calls the implementation of the
4877	virtual function, so such a call in a recursive cycle can still result in
4878	unbounded stack growth.
4879
4880	`clang::musttail` can only be applied to a `return` statement whose value
4881	is the result of a function call (even functions returning void must use
4882	`return`, although no value is returned). The target function must have the
4883	same number of arguments as the caller. The types of the return value and all
4884	arguments must be similar according to C++ rules (differing only in cv
4885	qualifiers or array size), including the implicit "this" argument, if any.
4886	Any variables in scope, including all arguments to the function and the
4887	return value must be trivially destructible. The calling convention of the
4888	caller and callee must match, and they must not be variadic functions or have
4889	old style K&R C function declarations.
4890
4891	The lifetimes of all local variables and function parameters end immediately
4892	before the call to the function. This means that it is undefined behaviour to
4893	pass a pointer or reference to a local variable to the called function, which
4894	is not the case without the attribute. Clang will emit a warning in common
4895	cases where this happens.
4896
4897	`clang::musttail` provides assurances that the tail call can be optimized on
4898	all targets, not just one.)reST";
4899
4900	static const char AttrDoc_NSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4901	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4902	convention (e.g. functions starting with "get" are assumed to return at
4903	`+0`).
4904
4905	It can be overridden using a family of the following attributes. In
4906	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
4907	a function communicates that the object is returned at `+1`, and the caller
4908	is responsible for freeing it.
4909	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
4910	specifies that the object is returned at `+0` and the ownership remains with
4911	the callee.
4912	The annotation `__attribute__((ns_consumes_self))` specifies that
4913	the Objective-C method call consumes the reference to `self`, e.g. by
4914	attaching it to a supplied parameter.
4915	Additionally, parameters can have an annotation
4916	`__attribute__((ns_consumed))`, which specifies that passing an owned object
4917	as that parameter effectively transfers the ownership, and the caller is no
4918	longer responsible for it.
4919	These attributes affect code generation when interacting with ARC code, and
4920	they are used by the Clang Static Analyzer.
4921
4922	In C programs using CoreFoundation, a similar set of attributes:
4923	`__attribute__((cf_returns_not_retained))`,
4924	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
4925	have the same respective semantics when applied to CoreFoundation objects.
4926	These attributes affect code generation when interacting with ARC code, and
4927	they are used by the Clang Static Analyzer.
4928
4929	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4930	the same attribute family is present:
4931	`__attribute__((os_returns_not_retained))`,
4932	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
4933	with the same respective semantics.
4934	Similar to `__attribute__((ns_consumes_self))`,
4935	`__attribute__((os_consumes_this))` specifies that the method call consumes
4936	the reference to "this" (e.g., when attaching it to a different object supplied
4937	as a parameter).
4938	Out parameters (parameters the function is meant to write into,
4939	either via pointers-to-pointers or references-to-pointers)
4940	may be annotated with `__attribute__((os_returns_retained))`
4941	or `__attribute__((os_returns_not_retained))` which specifies that the object
4942	written into the out parameter should (or respectively should not) be released
4943	after use.
4944	Since often out parameters may or may not be written depending on the exit
4945	code of the function,
4946	annotations `__attribute__((os_returns_retained_on_zero))`
4947	and `__attribute__((os_returns_retained_on_non_zero))` specify that
4948	an out parameter at `+1` is written if and only if the function returns a zero
4949	(respectively non-zero) error code.
4950	Observe that return-code-dependent out parameter annotations are only
4951	available for retained out parameters, as non-retained object do not have to be
4952	released by the callee.
4953	These attributes are only used by the Clang Static Analyzer.
4954
4955	The family of attributes `X_returns_X_retained` can be added to functions,
4956	C++ methods, and Objective-C methods and properties.
4957	Attributes `X_consumed` can be added to parameters of methods, functions,
4958	and Objective-C methods.)reST";
4959
4960	static const char AttrDoc_NSConsumesSelf[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4961	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4962	convention (e.g. functions starting with "get" are assumed to return at
4963	`+0`).
4964
4965	It can be overridden using a family of the following attributes. In
4966	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
4967	a function communicates that the object is returned at `+1`, and the caller
4968	is responsible for freeing it.
4969	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
4970	specifies that the object is returned at `+0` and the ownership remains with
4971	the callee.
4972	The annotation `__attribute__((ns_consumes_self))` specifies that
4973	the Objective-C method call consumes the reference to `self`, e.g. by
4974	attaching it to a supplied parameter.
4975	Additionally, parameters can have an annotation
4976	`__attribute__((ns_consumed))`, which specifies that passing an owned object
4977	as that parameter effectively transfers the ownership, and the caller is no
4978	longer responsible for it.
4979	These attributes affect code generation when interacting with ARC code, and
4980	they are used by the Clang Static Analyzer.
4981
4982	In C programs using CoreFoundation, a similar set of attributes:
4983	`__attribute__((cf_returns_not_retained))`,
4984	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
4985	have the same respective semantics when applied to CoreFoundation objects.
4986	These attributes affect code generation when interacting with ARC code, and
4987	they are used by the Clang Static Analyzer.
4988
4989	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4990	the same attribute family is present:
4991	`__attribute__((os_returns_not_retained))`,
4992	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
4993	with the same respective semantics.
4994	Similar to `__attribute__((ns_consumes_self))`,
4995	`__attribute__((os_consumes_this))` specifies that the method call consumes
4996	the reference to "this" (e.g., when attaching it to a different object supplied
4997	as a parameter).
4998	Out parameters (parameters the function is meant to write into,
4999	either via pointers-to-pointers or references-to-pointers)
5000	may be annotated with `__attribute__((os_returns_retained))`
5001	or `__attribute__((os_returns_not_retained))` which specifies that the object
5002	written into the out parameter should (or respectively should not) be released
5003	after use.
5004	Since often out parameters may or may not be written depending on the exit
5005	code of the function,
5006	annotations `__attribute__((os_returns_retained_on_zero))`
5007	and `__attribute__((os_returns_retained_on_non_zero))` specify that
5008	an out parameter at `+1` is written if and only if the function returns a zero
5009	(respectively non-zero) error code.
5010	Observe that return-code-dependent out parameter annotations are only
5011	available for retained out parameters, as non-retained object do not have to be
5012	released by the callee.
5013	These attributes are only used by the Clang Static Analyzer.
5014
5015	The family of attributes `X_returns_X_retained` can be added to functions,
5016	C++ methods, and Objective-C methods and properties.
5017	Attributes `X_consumed` can be added to parameters of methods, functions,
5018	and Objective-C methods.)reST";
5019
5020	static const char AttrDoc_NSErrorDomain[] = R"reST(In Cocoa frameworks in Objective-C, one can group related error codes in enums
5021	and categorize these enums with error domains.
5022
5023	The `ns_error_domain` attribute indicates a global `NSString` or
5024	`CFString` constant representing the error domain that an error code belongs
5025	to. For pointer uniqueness and code size this is a constant symbol, not a
5026	literal.
5027
5028	The domain and error code need to be used together. The `ns_error_domain`
5029	attribute links error codes to their domain at the source level.
5030
5031	This metadata is useful for documentation purposes, for static analysis, and for
5032	improving interoperability between Objective-C and Swift. It is not used for
5033	code generation in Objective-C.
5034
5035	For example:
5036
5037	```objc
5038	#define NS_ERROR_ENUM(_type, _name, _domain) \
5039	enum _name : _type _name; enum __attribute__((ns_error_domain(_domain))) _name : _type
5040
5041	extern NSString *const MyErrorDomain;
5042	typedef NS_ERROR_ENUM(unsigned char, MyErrorEnum, MyErrorDomain) {
5043	MyErrFirst,
5044	MyErrSecond,
5045	};
5046	```)reST";
5047
5048	static const char AttrDoc_NSReturnsAutoreleased[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5049	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5050	convention (e.g. functions starting with "get" are assumed to return at
5051	`+0`).
5052
5053	It can be overridden using a family of the following attributes. In
5054	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
5055	a function communicates that the object is returned at `+1`, and the caller
5056	is responsible for freeing it.
5057	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
5058	specifies that the object is returned at `+0` and the ownership remains with
5059	the callee.
5060	The annotation `__attribute__((ns_consumes_self))` specifies that
5061	the Objective-C method call consumes the reference to `self`, e.g. by
5062	attaching it to a supplied parameter.
5063	Additionally, parameters can have an annotation
5064	`__attribute__((ns_consumed))`, which specifies that passing an owned object
5065	as that parameter effectively transfers the ownership, and the caller is no
5066	longer responsible for it.
5067	These attributes affect code generation when interacting with ARC code, and
5068	they are used by the Clang Static Analyzer.
5069
5070	In C programs using CoreFoundation, a similar set of attributes:
5071	`__attribute__((cf_returns_not_retained))`,
5072	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
5073	have the same respective semantics when applied to CoreFoundation objects.
5074	These attributes affect code generation when interacting with ARC code, and
5075	they are used by the Clang Static Analyzer.
5076
5077	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5078	the same attribute family is present:
5079	`__attribute__((os_returns_not_retained))`,
5080	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
5081	with the same respective semantics.
5082	Similar to `__attribute__((ns_consumes_self))`,
5083	`__attribute__((os_consumes_this))` specifies that the method call consumes
5084	the reference to "this" (e.g., when attaching it to a different object supplied
5085	as a parameter).
5086	Out parameters (parameters the function is meant to write into,
5087	either via pointers-to-pointers or references-to-pointers)
5088	may be annotated with `__attribute__((os_returns_retained))`
5089	or `__attribute__((os_returns_not_retained))` which specifies that the object
5090	written into the out parameter should (or respectively should not) be released
5091	after use.
5092	Since often out parameters may or may not be written depending on the exit
5093	code of the function,
5094	annotations `__attribute__((os_returns_retained_on_zero))`
5095	and `__attribute__((os_returns_retained_on_non_zero))` specify that
5096	an out parameter at `+1` is written if and only if the function returns a zero
5097	(respectively non-zero) error code.
5098	Observe that return-code-dependent out parameter annotations are only
5099	available for retained out parameters, as non-retained object do not have to be
5100	released by the callee.
5101	These attributes are only used by the Clang Static Analyzer.
5102
5103	The family of attributes `X_returns_X_retained` can be added to functions,
5104	C++ methods, and Objective-C methods and properties.
5105	Attributes `X_consumed` can be added to parameters of methods, functions,
5106	and Objective-C methods.)reST";
5107
5108	static const char AttrDoc_NSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5109	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5110	convention (e.g. functions starting with "get" are assumed to return at
5111	`+0`).
5112
5113	It can be overridden using a family of the following attributes. In
5114	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
5115	a function communicates that the object is returned at `+1`, and the caller
5116	is responsible for freeing it.
5117	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
5118	specifies that the object is returned at `+0` and the ownership remains with
5119	the callee.
5120	The annotation `__attribute__((ns_consumes_self))` specifies that
5121	the Objective-C method call consumes the reference to `self`, e.g. by
5122	attaching it to a supplied parameter.
5123	Additionally, parameters can have an annotation
5124	`__attribute__((ns_consumed))`, which specifies that passing an owned object
5125	as that parameter effectively transfers the ownership, and the caller is no
5126	longer responsible for it.
5127	These attributes affect code generation when interacting with ARC code, and
5128	they are used by the Clang Static Analyzer.
5129
5130	In C programs using CoreFoundation, a similar set of attributes:
5131	`__attribute__((cf_returns_not_retained))`,
5132	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
5133	have the same respective semantics when applied to CoreFoundation objects.
5134	These attributes affect code generation when interacting with ARC code, and
5135	they are used by the Clang Static Analyzer.
5136
5137	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5138	the same attribute family is present:
5139	`__attribute__((os_returns_not_retained))`,
5140	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
5141	with the same respective semantics.
5142	Similar to `__attribute__((ns_consumes_self))`,
5143	`__attribute__((os_consumes_this))` specifies that the method call consumes
5144	the reference to "this" (e.g., when attaching it to a different object supplied
5145	as a parameter).
5146	Out parameters (parameters the function is meant to write into,
5147	either via pointers-to-pointers or references-to-pointers)
5148	may be annotated with `__attribute__((os_returns_retained))`
5149	or `__attribute__((os_returns_not_retained))` which specifies that the object
5150	written into the out parameter should (or respectively should not) be released
5151	after use.
5152	Since often out parameters may or may not be written depending on the exit
5153	code of the function,
5154	annotations `__attribute__((os_returns_retained_on_zero))`
5155	and `__attribute__((os_returns_retained_on_non_zero))` specify that
5156	an out parameter at `+1` is written if and only if the function returns a zero
5157	(respectively non-zero) error code.
5158	Observe that return-code-dependent out parameter annotations are only
5159	available for retained out parameters, as non-retained object do not have to be
5160	released by the callee.
5161	These attributes are only used by the Clang Static Analyzer.
5162
5163	The family of attributes `X_returns_X_retained` can be added to functions,
5164	C++ methods, and Objective-C methods and properties.
5165	Attributes `X_consumed` can be added to parameters of methods, functions,
5166	and Objective-C methods.)reST";
5167
5168	static const char AttrDoc_NSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5169	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5170	convention (e.g. functions starting with "get" are assumed to return at
5171	`+0`).
5172
5173	It can be overridden using a family of the following attributes. In
5174	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
5175	a function communicates that the object is returned at `+1`, and the caller
5176	is responsible for freeing it.
5177	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
5178	specifies that the object is returned at `+0` and the ownership remains with
5179	the callee.
5180	The annotation `__attribute__((ns_consumes_self))` specifies that
5181	the Objective-C method call consumes the reference to `self`, e.g. by
5182	attaching it to a supplied parameter.
5183	Additionally, parameters can have an annotation
5184	`__attribute__((ns_consumed))`, which specifies that passing an owned object
5185	as that parameter effectively transfers the ownership, and the caller is no
5186	longer responsible for it.
5187	These attributes affect code generation when interacting with ARC code, and
5188	they are used by the Clang Static Analyzer.
5189
5190	In C programs using CoreFoundation, a similar set of attributes:
5191	`__attribute__((cf_returns_not_retained))`,
5192	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
5193	have the same respective semantics when applied to CoreFoundation objects.
5194	These attributes affect code generation when interacting with ARC code, and
5195	they are used by the Clang Static Analyzer.
5196
5197	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5198	the same attribute family is present:
5199	`__attribute__((os_returns_not_retained))`,
5200	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
5201	with the same respective semantics.
5202	Similar to `__attribute__((ns_consumes_self))`,
5203	`__attribute__((os_consumes_this))` specifies that the method call consumes
5204	the reference to "this" (e.g., when attaching it to a different object supplied
5205	as a parameter).
5206	Out parameters (parameters the function is meant to write into,
5207	either via pointers-to-pointers or references-to-pointers)
5208	may be annotated with `__attribute__((os_returns_retained))`
5209	or `__attribute__((os_returns_not_retained))` which specifies that the object
5210	written into the out parameter should (or respectively should not) be released
5211	after use.
5212	Since often out parameters may or may not be written depending on the exit
5213	code of the function,
5214	annotations `__attribute__((os_returns_retained_on_zero))`
5215	and `__attribute__((os_returns_retained_on_non_zero))` specify that
5216	an out parameter at `+1` is written if and only if the function returns a zero
5217	(respectively non-zero) error code.
5218	Observe that return-code-dependent out parameter annotations are only
5219	available for retained out parameters, as non-retained object do not have to be
5220	released by the callee.
5221	These attributes are only used by the Clang Static Analyzer.
5222
5223	The family of attributes `X_returns_X_retained` can be added to functions,
5224	C++ methods, and Objective-C methods and properties.
5225	Attributes `X_consumed` can be added to parameters of methods, functions,
5226	and Objective-C methods.)reST";
5227
5228	static const char AttrDoc_Naked[] = R"reST(No documentation.)reST";
5229
5230	static const char AttrDoc_NoAlias[] = R"reST(The `noalias` attribute indicates that the only memory accesses inside
5231	function are loads and stores from objects pointed to by its pointer-typed
5232	arguments, with arbitrary offsets.)reST";
5233
5234	static const char AttrDoc_NoBuiltin[] = R"reST(The `__attribute__((no_builtin))` is similar to the `-fno-builtin` flag
5235	except it is specific to the body of a function. The attribute may also be
5236	applied to a virtual function but has no effect on the behavior of overriding
5237	functions in a derived class.
5238
5239	It accepts one or more strings corresponding to the specific names of the
5240	builtins to disable (e.g. "memcpy", "memset").
5241	If the attribute is used without parameters it will disable all buitins at
5242	once.
5243
5244	```c++
5245	// The compiler is not allowed to add any builtin to foo's body.
5246	void foo(char* data, size_t count) __attribute__((no_builtin)) {
5247	// The compiler is not allowed to convert the loop into
5248	// `__builtin_memset(data, 0xFE, count);`.
5249	for (size_t i = 0; i < count; ++i)
5250	data[i] = 0xFE;
5251	}
5252
5253	// The compiler is not allowed to add the `memcpy` builtin to bar's body.
5254	void bar(char* data, size_t count) __attribute__((no_builtin("memcpy"))) {
5255	// The compiler is allowed to convert the loop into
5256	// `__builtin_memset(data, 0xFE, count);` but cannot generate any
5257	// `__builtin_memcpy`
5258	for (size_t i = 0; i < count; ++i)
5259	data[i] = 0xFE;
5260	}
5261	```)reST";
5262
5263	static const char AttrDoc_NoCommon[] = R"reST(No documentation.)reST";
5264
5265	static const char AttrDoc_NoConvergent[] = R"reST(This attribute prevents a function from being treated as convergent; when a
5266	function is marked `noconvergent`, calls to that function are not
5267	automatically assumed to be convergent, unless such calls are explicitly marked
5268	as `convergent`. If a statement is marked as `noconvergent`, any calls to
5269	inline `asm` in that statement are no longer treated as convergent.
5270
5271	In languages following SPMD/SIMT programming model, e.g., CUDA/HIP, function
5272	declarations and inline asm calls are treated as convergent by default for
5273	correctness. This `noconvergent` attribute is helpful for developers to
5274	prevent them from being treated as convergent when it's safe.
5275
5276	```c
5277	__device__ float bar(float);
5278	__device__ float foo(float) __attribute__((noconvergent)) {}
5279
5280	__device__ int example(void) {
5281	float x;
5282	[[clang::noconvergent]] x = bar(x); // no effect on convergence
5283	[[clang::noconvergent]] { asm volatile ("nop"); } // the asm call is non-convergent
5284	}
5285	```)reST";
5286
5287	static const char AttrDoc_NoDebug[] = R"reST(The `nodebug` attribute allows you to suppress debugging information for a
5288	function or method, for a variable that is not a parameter or a non-static
5289	data member, or for a typedef or using declaration.)reST";
5290
5291	static const char AttrDoc_NoDeref[] = R"reST(The `noderef` attribute causes clang to diagnose dereferences of annotated pointer types.
5292	This is ideally used with pointers that point to special memory which cannot be read
5293	from or written to, but allowing for the pointer to be used in pointer arithmetic.
5294	The following are examples of valid expressions where dereferences are diagnosed:
5295
5296	```c
5297	int __attribute__((noderef)) *p;
5298	int x = *p; // warning
5299
5300	int __attribute__((noderef)) **p2;
5301	x = **p2; // warning
5302
5303	int * __attribute__((noderef)) *p3;
5304	p = *p3; // warning
5305
5306	struct S {
5307	int a;
5308	};
5309	struct S __attribute__((noderef)) *s;
5310	x = s->a; // warning
5311	x = (*s).a; // warning
5312	```
5313
5314	Not all dereferences may diagnose a warning if the value directed by the pointer may not be
5315	accessed. The following are examples of valid expressions where may not be diagnosed:
5316
5317	```c
5318	int *q;
5319	int __attribute__((noderef)) *p;
5320	q = &*p;
5321	q = *&p;
5322
5323	struct S {
5324	int a;
5325	};
5326	struct S __attribute__((noderef)) *s;
5327	p = &s->a;
5328	p = &(*s).a;
5329	```
5330
5331	`noderef` is currently only supported for pointers and arrays and not usable
5332	for references or Objective-C object pointers.
5333
5334	```c++
5335	int x = 2;
5336	int __attribute__((noderef)) &y = x; // warning: 'noderef' can only be used on an array or pointer type
5337	```
5338
5339	```objc
5340	id __attribute__((noderef)) obj = [NSObject new]; // warning: 'noderef' can only be used on an array or pointer type
5341	```)reST";
5342
5343	static const char AttrDoc_NoDestroy[] = R"reST(The `no_destroy` attribute specifies that a variable with static or thread
5344	storage duration shouldn't have its exit-time destructor run. Annotating every
5345	static and thread duration variable with this attribute is equivalent to
5346	invoking clang with -fno-c++-static-destructors.
5347
5348	If a variable is declared with this attribute, clang doesn't access check or
5349	generate the type's destructor. If you have a type that you only want to be
5350	annotated with `no_destroy`, you can therefore declare the destructor private:
5351
5352	```c++
5353	struct only_no_destroy {
5354	only_no_destroy();
5355	private:
5356	~only_no_destroy();
5357	};
5358
5359	[[clang::no_destroy]] only_no_destroy global; // fine!
5360	```
5361
5362	Note that destructors are still required for subobjects of aggregates annotated
5363	with this attribute. This is because previously constructed subobjects need to
5364	be destroyed if an exception gets thrown before the initialization of the
5365	complete object is complete. For instance:
5366
5367	```c++
5368	void f() {
5369	try {
5370	[[clang::no_destroy]]
5371	static only_no_destroy array[10]; // error, only_no_destroy has a private destructor.
5372	} catch (...) {
5373	// Handle the error
5374	}
5375	}
5376	```
5377
5378	Here, if the construction of `array[9]` fails with an exception, `array[0..8]`
5379	will be destroyed, so the element's destructor needs to be accessible.)reST";
5380
5381	static const char AttrDoc_NoDuplicate[] = R"reST(The `noduplicate` attribute can be placed on function declarations to control
5382	whether function calls to this function can be duplicated or not as a result of
5383	optimizations. This is required for the implementation of functions with
5384	certain special requirements, like the OpenCL "barrier" function, that might
5385	need to be run concurrently by all the threads that are executing in lockstep
5386	on the hardware. For example this attribute applied on the function
5387	"nodupfunc" in the code below avoids that:
5388
5389	```c
5390	void nodupfunc() __attribute__((noduplicate));
5391	// Setting it as a C++11 attribute is also valid
5392	// void nodupfunc() [[clang::noduplicate]];
5393	void foo();
5394	void bar();
5395
5396	nodupfunc();
5397	if (a > n) {
5398	foo();
5399	} else {
5400	bar();
5401	}
5402	```
5403
5404	gets possibly modified by some optimizations into code similar to this:
5405
5406	```c
5407	if (a > n) {
5408	nodupfunc();
5409	foo();
5410	} else {
5411	nodupfunc();
5412	bar();
5413	}
5414	```
5415
5416	where the call to "nodupfunc" is duplicated and sunk into the two branches
5417	of the condition.)reST";
5418
5419	static const char AttrDoc_NoEscape[] = R"reST(`noescape` placed on a function parameter of a pointer type is used to inform
5420	the compiler that the pointer cannot escape: that is, no reference to the object
5421	the pointer points to that is derived from the parameter value will survive
5422	after the function returns. Users are responsible for making sure parameters
5423	annotated with `noescape` do not actually escape. The optimizer may make
5424	assumptions based on the fact that it knows that a call to the function does
5425	not escape a certain parameter, so incorrectly annotating a parameter with
5426	`noescape` leads to undefined behavior. The callee is also not allowed to
5427	deallocate memory through a `noescape` parameter: the optimizer does not make
5428	assumptions based on this information at the moment, but may do so in the
5429	future. Some cases of invalid uses of `noescape` can be found with
5430	{ref}`-Wlifetime-safety-noescape <Wlifetime-safety-noescape>`.
5431
5432	For example:
5433
5434	```c
5435	int *gp;
5436
5437	void nonescapingFunc(__attribute__((noescape)) int *p) {
5438	*p += 100; // OK.
5439	}
5440
5441	void escapingFunc(__attribute__((noescape)) int *p) {
5442	gp = p; // Not OK.
5443	}
5444
5445	void freeingFunc(__attribute__((noescape)) int *p) {
5446	free(p); // Not OK.
5447	}
5448	```
5449
5450	Since `noescape` is a parameter attribute and not a type attribute, it only
5451	applies to the outermost pointer level, regardless of where in the parameter
5452	declaration you place it:
5453
5454	```c
5455	int **gp;
5456
5457	void nestingEscapes(__attribute__((noescape)) int **p) {
5458	gp = p; // Not OK.
5459	gp = p; // OK, p does not escape.
5460	}
5461	```
5462
5463	Additionally, when the parameter is a
5464	{doc}`block pointer <BlockLanguageSpec>`, the same restriction applies to
5465	copies of the block. For example:
5466
5467	```c
5468	typedef void (^BlockTy)();
5469	BlockTy g0, g1;
5470
5471	void nonescapingFunc(__attribute__((noescape)) BlockTy block) {
5472	block(); // OK.
5473	}
5474
5475	void escapingFunc(__attribute__((noescape)) BlockTy block) {
5476	g0 = block; // Not OK.
5477	g1 = Block_copy(block); // Not OK either.
5478	}
5479	```
5480
5481	The function is allowed to leak information about the memory address of the
5482	pointer, but not any provenance of the allocation:
5483
5484	```c
5485	bool isNull(__attribute__((noescape)) void *p) {
5486	return !p; // OK.
5487	}
5488
5489	uintptr_t gi;
5490
5491	void escapingAddress(__attribute__((noescape)) int *p) {
5492	// OK if and only if gi is never casted back to a pointer.
5493	gi = (uintptr_t)p;
5494	}
5495
5496	bool usingEscapedAddress(int *p) {
5497	return (uintptr_t)p > gi; // OK.
5498	}
5499
5500	bool usingEscapedPointer(int *p) {
5501	return p > (int*)gi; // Not OK.
5502	}
5503
5504	int *gp;
5505
5506	void escapingEndFunc(__attribute__((noescape)) int *p, size_t len) {
5507	gp = p + len; // Not OK.
5508	}
5509	```)reST";
5510
5511	static const char AttrDoc_NoFieldProtection[] = R"reST(No documentation.)reST";
5512
5513	static const char AttrDoc_NoInline[] = R"reST(This function attribute suppresses the inlining of a function at the call sites
5514	of the function.
5515
5516	`[[clang::noinline]]` spelling can be used as a statement attribute; other
5517	spellings of the attribute are not supported on statements. If a statement is
5518	marked `[[clang::noinline]]` and contains calls, those calls inside the
5519	statement will not be inlined by the compiler.
5520
5521	`__noinline__` can be used as a keyword in CUDA/HIP languages. This is to
5522	avoid diagnostics due to usage of `__attribute__((__noinline__))`
5523	with `__noinline__` defined as a macro as `__attribute__((noinline))`.
5524
5525	```c
5526	int example(void) {
5527	int r;
5528	[[clang::noinline]] foo();
5529	[[clang::noinline]] r = bar();
5530	return r;
5531	}
5532	```)reST";
5533
5534	static const char AttrDoc_NoInstrumentFunction[] = R"reST(No documentation.)reST";
5535
5536	static const char AttrDoc_NoMerge[] = R"reST(If a statement is marked `nomerge` and contains call expressions, those call
5537	expressions inside the statement will not be merged during optimization. This
5538	attribute can be used to prevent the optimizer from obscuring the source
5539	location of certain calls. For example, it will prevent tail merging otherwise
5540	identical code sequences that raise an exception or terminate the program. Tail
5541	merging normally reduces the precision of source location information, making
5542	stack traces less useful for debugging. This attribute gives the user control
5543	over the tradeoff between code size and debug information precision.
5544
5545	`nomerge` attribute can also be used as function attribute to prevent all
5546	calls to the specified function from merging. It has no effect on indirect
5547	calls to such functions. For example:
5548
5549	```c++
5550	[[clang::nomerge]] void foo(int) {}
5551
5552	void bar(int x) {
5553	auto *ptr = foo;
5554	if (x) foo(1); else foo(2); // will not be merged
5555	if (x) ptr(1); else ptr(2); // indirect call, can be merged
5556	}
5557	```
5558
5559	`nomerge` attribute can also be used for pointers to functions to
5560	prevent calls through such pointer from merging. In such case the
5561	effect applies only to a specific function pointer. For example:
5562
5563	```c++
5564	[[clang::nomerge]] void (*foo)(int);
5565
5566	void bar(int x) {
5567	auto *ptr = foo;
5568	if (x) foo(1); else foo(2); // will not be merged
5569	if (x) ptr(1); else ptr(2); // 'ptr' has no 'nomerge' attribute, can be merged
5570	}
5571	```)reST";
5572
5573	static const char AttrDoc_NoMicroMips[] = R"reST(Clang supports the GNU style `__attribute__((micromips))` and
5574	`__attribute__((nomicromips))` attributes on MIPS targets. These attributes
5575	may be attached to a function definition and instructs the backend to generate
5576	or not to generate microMIPS code for that function.
5577
5578	These attributes override the `-mmicromips` and `-mno-micromips` options
5579	on the command line.)reST";
5580
5581	static const char AttrDoc_NoMips16[] = R"reST(No documentation.)reST";
5582
5583	static const char AttrDoc_NoOutline[] = R"reST(This function attribute suppresses outlining from the annotated function.
5584
5585	Outlining is the process where common parts of separate functions are extracted
5586	into a separate function (or assembly snippet), and calls to that function or
5587	snippet are inserted in the original functions. In this way, it can be seen as
5588	the opposite of inlining. It can help to reduce code size.)reST";
5589
5590	static const char AttrDoc_NoProfileFunction[] = R"reST(Use the `no_profile_instrument_function` attribute on a function declaration
5591	to denote that the compiler should not instrument the function with
5592	profile-related instrumentation, such as via the
5593	`-fprofile-generate` / `-fprofile-instr-generate` /
5594	`-fcs-profile-generate` / `-fprofile-arcs` flags.)reST";
5595
5596	static const char AttrDoc_NoRandomizeLayout[] = R"reST(The attribute `randomize_layout`, when attached to a C structure, selects it
5597	for structure layout field randomization; a compile-time hardening technique. A
5598	"seed" value, is specified via the `-frandomize-layout-seed=` command line flag.
5599	For example:
5600
5601	```bash
5602	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
5603	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
5604	```
5605
5606	You can also supply the seed in a file with `-frandomize-layout-seed-file=`.
5607	For example:
5608
5609	```bash
5610	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
5611	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
5612	```
5613
5614	The randomization is deterministic based for a given seed, so the entire
5615	program should be compiled with the same seed, but keep the seed safe
5616	otherwise.
5617
5618	The attribute `no_randomize_layout`, when attached to a C structure,
5619	instructs the compiler that this structure should not have its field layout
5620	randomized.)reST";
5621
5622	static const char AttrDoc_NoReturn[] = R"reST(No documentation.)reST";
5623
5624	static const char AttrDoc_NoSanitize[] = R"reST(Use the `no_sanitize` attribute on a function or a global variable
5625	declaration to specify that a particular instrumentation or set of
5626	instrumentations should not be applied.
5627
5628	The attribute takes a list of string literals with the following accepted
5629	values:
5630
5631	- all values accepted by `-fno-sanitize=`;
5632	- `coverage`, to disable SanitizerCoverage instrumentation.
5633
5634	For example, `__attribute__((no_sanitize("address", "thread")))` specifies
5635	that AddressSanitizer and ThreadSanitizer should not be applied to the function
5636	or variable. Using `__attribute__((no_sanitize("coverage")))` specifies that
5637	SanitizerCoverage should not be applied to the function.
5638
5639	See {ref}`Controlling Code Generation <controlling-code-generation>` for a
5640	full list of supported sanitizer flags.)reST";
5641
5642	static const char AttrDoc_NoSpecializations[] = R"reST(``[[clang::no_specializations]]`` can be applied to function, class, or variable
5643	templates for which neither an explicit specialization nor a partial specialization should be declared by users. This is primarily
5644	used to diagnose user specializations of standard library type traits.)reST";
5645
5646	static const char AttrDoc_NoSpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
5647	that [Speculative Load Hardening][slh] is not needed for the function body.
5648	This can also be applied to a method in Objective C. This attribute will take
5649	precedence over the command line flag in the case where
5650	{option}`-mspeculative-load-hardening` is specified.
5651
5652	Warning: This attribute may not prevent Speculative Load Hardening from being
5653	enabled for a function which inlines a function that has the
5654	'speculative_load_hardening' attribute. This is intended to provide a
5655	maximally conservative model where the code that is marked with the
5656	'speculative_load_hardening' attribute will always (even when inlined)
5657	be hardened. A user of this attribute may want to mark functions called by
5658	a function they do not want to be hardened with the 'noinline' attribute.
5659
5660	For example:
5661
5662	```c
5663	__attribute__((speculative_load_hardening))
5664	int foo(int i) {
5665	return i;
5666	}
5667
5668	// Note: bar() may still have speculative load hardening enabled if
5669	// foo() is inlined into bar(). Mark foo() with __attribute__((noinline))
5670	// to avoid this situation.
5671	__attribute__((no_speculative_load_hardening))
5672	int bar(int i) {
5673	return foo(i);
5674	}
5675	```)reST";
5676
5677	static const char AttrDoc_NoSplitStack[] = R"reST(The `no_split_stack` attribute disables the emission of the split stack
5678	preamble for a particular function. It has no effect if `-fsplit-stack`
5679	is not specified.)reST";
5680
5681	static const char AttrDoc_NoStackProtector[] = R"reST(Clang supports the GNU style `__attribute__((no_stack_protector))` and Microsoft
5682	style `__declspec(safebuffers)` attribute which disables
5683	the stack protector on the specified function. This attribute is useful for
5684	selectively disabling the stack protector on some functions when building with
5685	`-fstack-protector` compiler option.
5686
5687	For example, it disables the stack protector for the function `foo` but function
5688	`bar` will still be built with the stack protector with the `-fstack-protector`
5689	option.
5690
5691	```c
5692	int __attribute__((no_stack_protector))
5693	foo (int x); // stack protection will be disabled for foo.
5694
5695	int bar(int y); // bar can be built with the stack protector.
5696	```)reST";
5697
5698	static const char AttrDoc_NoThreadSafetyAnalysis[] = R"reST(No documentation.)reST";
5699
5700	static const char AttrDoc_NoThrow[] = R"reST(Clang supports the GNU style `__attribute__((nothrow))` and Microsoft style
5701	`__declspec(nothrow)` attribute as an equivalent of `noexcept` on function
5702	declarations. This attribute informs the compiler that the annotated function
5703	does not throw an exception. This prevents exception-unwinding. This attribute
5704	is particularly useful on functions in the C Standard Library that are
5705	guaranteed to not throw an exception.)reST";
5706
5707	static const char AttrDoc_NoTrivialAutoVarInit[] = R"reST(The `__declspec(no_init_all)` attribute disables the automatic initialization
5708	that the {option}`-ftrivial-auto-var-init` flag would have applied to locals in
5709	a marked function, or instances of a marked type. Note that this attribute has
5710	no effect for locals that are automatically initialized without the
5711	{option}`-ftrivial-auto-var-init` flag.)reST";
5712
5713	static const char AttrDoc_NoUniqueAddress[] = R"reST(The `no_unique_address` attribute allows tail padding in a non-static data
5714	member to overlap other members of the enclosing class (and in the special
5715	case when the type is empty, permits it to fully overlap other members).
5716	The field is laid out as if a base class were encountered at the corresponding
5717	point within the class (except that it does not share a vptr with the enclosing
5718	object).
5719
5720	Example usage:
5721
5722	```c++
5723	template<typename T, typename Alloc> struct my_vector {
5724	T *p;
5725	[[no_unique_address]] Alloc alloc;
5726	// ...
5727	};
5728	static_assert(sizeof(my_vector<int, std::allocator<int>>) == sizeof(int*));
5729	```
5730
5731	`[[no_unique_address]]` is a standard C++20 attribute. Clang supports its use
5732	in C++11 onwards.
5733
5734	On MSVC targets, `[[no_unique_address]]` is ignored; use
5735	`[[msvc::no_unique_address]]` instead. Currently there is no guarantee of ABI
5736	compatibility or stability with MSVC.)reST";
5737
5738	static const char AttrDoc_NoUwtable[] = R"reST(Clang supports the `nouwtable` attribute which skips emitting
5739	the unwind table entry for the specified function. This attribute is useful for
5740	selectively emitting the unwind table entry on some functions when building with
5741	`-funwind-tables` compiler option.)reST";
5742
5743	static const char AttrDoc_NonAllocating[] = R"reST(Declares that a function or function type either does or does not allocate heap memory, according
5744	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
5745	is false, the attribute is equivalent to `allocating`.)reST";
5746
5747	static const char AttrDoc_NonBlocking[] = R"reST(Declares that a function or function type either does or does not block in any way, according
5748	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
5749	is false, the attribute is equivalent to `blocking`.
5750
5751	For the purposes of diagnostics, `nonblocking` is considered to include the
5752	`nonallocating` guarantee and is therefore a "stronger" constraint or attribute.)reST";
5753
5754	static const char AttrDoc_NonNull[] = R"reST(The `nonnull` attribute indicates that some function parameters must not be
5755	null, and can be used in several different ways. It's original usage
5756	([from GCC](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes))
5757	is as a function (or Objective-C method) attribute that specifies which
5758	parameters of the function are nonnull in a comma-separated list. For example:
5759
5760	```c
5761	extern void * my_memcpy (void dest, const void src, size_t len)
5762	__attribute__((nonnull (1, 2)));
5763	```
5764
5765	Here, the `nonnull` attribute indicates that parameters 1 and 2
5766	cannot have a null value. Omitting the parenthesized list of parameter indices
5767	means that all parameters of pointer type cannot be null:
5768
5769	```c
5770	extern void * my_memcpy (void dest, const void src, size_t len)
5771	__attribute__((nonnull));
5772	```
5773
5774	Clang also allows the `nonnull` attribute to be placed directly on a function
5775	(or Objective-C method) parameter, eliminating the need to specify the
5776	parameter index ahead of type. For example:
5777
5778	```c
5779	extern void * my_memcpy (void *dest __attribute__((nonnull)),
5780	const void *src __attribute__((nonnull)), size_t len);
5781	```
5782
5783	Note that the `nonnull` attribute indicates that passing null to a non-null
5784	parameter is undefined behavior, which the optimizer may take advantage of to,
5785	e.g., remove null checks. The `_Nonnull` type qualifier indicates that a
5786	pointer cannot be null in a more general manner (because it is part of the type
5787	system) and does not imply undefined behavior, making it more widely applicable.)reST";
5788
5789	static const char AttrDoc_NonString[] = R"reST(The `nonstring` attribute can be applied to the declaration of a variable or
5790	a field whose type is a character pointer or character array to specify that
5791	the buffer is not intended to behave like a null-terminated string. This will
5792	silence diagnostics with code like:
5793
5794	```c
5795	char BadStr[3] = "foo"; // No space for the null terminator, diagnosed
5796	__attribute__((nonstring)) char NotAStr[3] = "foo"; // Not diagnosed
5797	```)reST";
5798
5799	static const char AttrDoc_NotTailCalled[] = R"reST(The `not_tail_called` attribute prevents tail-call optimization on statically
5800	bound calls. Objective-c methods, and functions marked as `always_inline`
5801	cannot be marked as `not_tail_called`.
5802
5803	For example, it prevents tail-call optimization in the following case:
5804
5805	```c
5806	int __attribute__((not_tail_called)) foo1(int);
5807
5808	int foo2(int a) {
5809	return foo1(a); // No tail-call optimization on direct calls.
5810	}
5811	```
5812
5813	However, it doesn't prevent tail-call optimization in this case:
5814
5815	```c
5816	int __attribute__((not_tail_called)) foo1(int);
5817
5818	int foo2(int a) {
5819	int (*fn)(int) = &foo1;
5820
5821	// not_tail_called has no effect on an indirect call even if the call can
5822	// be resolved at compile time.
5823	return (*fn)(a);
5824	}
5825	```
5826
5827	Generally, marking an overriding virtual function as `not_tail_called` is
5828	not useful, because this attribute is a property of the static type. Calls
5829	made through a pointer or reference to the base class type will respect
5830	the `not_tail_called` attribute of the base class's member function,
5831	regardless of the runtime destination of the call:
5832
5833	```c++
5834	struct Foo { virtual void f(); };
5835	struct Bar : Foo {
5836	[[clang::not_tail_called]] void f() override;
5837	};
5838	void callera(Bar& bar) {
5839	Foo& foo = bar;
5840	// not_tail_called has no effect on here, even though the
5841	// underlying method is f from Bar.
5842	foo.f();
5843	bar.f(); // No tail-call optimization on here.
5844	}
5845	```)reST";
5846
5847	static const char AttrDoc_OMPAllocateDecl[] = R"reST()reST";
5848
5849	static const char AttrDoc_OMPAssume[] = R"reST(Clang supports the `[[omp::assume("assumption")]]` attribute to
5850	provide additional information to the optimizer. The string-literal, here
5851	"assumption", will be attached to the function declaration such that later
5852	analysis and optimization passes can assume the "assumption" to hold.
5853	This is similar to {ref}`__builtin_assume <langext-__builtin_assume>` but
5854	instead of an expression that can be assumed to be non-zero, the assumption is
5855	expressed as a string and it holds for the entire function.
5856
5857	A function can have multiple assume attributes and they propagate from prior
5858	declarations to later definitions. Multiple assumptions are aggregated into a
5859	single comma separated string. Thus, one can provide multiple assumptions via
5860	a comma separated string, i.a.,
5861	`[[omp::assume("assumption1,assumption2")]]`.
5862
5863	While LLVM plugins might provide more assumption strings, the default LLVM
5864	optimization passes are aware of the following assumptions:
5865
5866	```none
5867	"omp_no_openmp"
5868	"omp_no_openmp_routines"
5869	"omp_no_parallelism"
5870	"omp_no_openmp_constructs"
5871	```
5872
5873	The OpenMP standard defines the meaning of OpenMP assumptions ("omp_XYZ" is
5874	spelled "XYZ" in the [OpenMP 5.1 Standard][openmp 5.1 standard]).
5875
5876	[openmp 5.1 standard]: https://www.openmp.org/spec-html/5.1/openmpsu37.html#x56-560002.5.2)reST";
5877
5878	static const char AttrDoc_OMPCaptureKind[] = R"reST()reST";
5879
5880	static const char AttrDoc_OMPCaptureNoInit[] = R"reST()reST";
5881
5882	static const char AttrDoc_OMPDeclareSimdDecl[] = R"reST(The `declare simd` construct can be applied to a function to enable the creation
5883	of one or more versions that can process multiple arguments using SIMD
5884	instructions from a single invocation in a SIMD loop. The `declare simd`
5885	directive is a declarative directive. There may be multiple `declare simd`
5886	directives for a function. The use of a `declare simd` construct on a function
5887	enables the creation of SIMD versions of the associated function that can be
5888	used to process multiple arguments from a single invocation from a SIMD loop
5889	concurrently.
5890	The syntax of the `declare simd` construct is as follows:
5891
5892	```none
5893	#pragma omp declare simd [clause[[,] clause] ...] new-line
5894	[#pragma omp declare simd [clause[[,] clause] ...] new-line]
5895	[...]
5896	function definition or declaration
5897	```
5898
5899	where clause is one of the following:
5900
5901	```none
5902	simdlen(length)
5903	linear(argument-list[:constant-linear-step])
5904	aligned(argument-list[:alignment])
5905	uniform(argument-list)
5906	inbranch
5907	notinbranch
5908	```)reST";
5909
5910	static const char AttrDoc_OMPDeclareTargetDecl[] = R"reST(The `declare target` directive specifies that variables and functions are mapped
5911	to a device for OpenMP offload mechanism.
5912
5913	The syntax of the declare target directive is as follows:
5914
5915	```c
5916	#pragma omp declare target new-line
5917	declarations-definition-seq
5918	#pragma omp end declare target new-line
5919	```
5920
5921	or
5922
5923	```c
5924	#pragma omp declare target (extended-list) new-line
5925	```
5926
5927	or
5928
5929	```c
5930	#pragma omp declare target clause[ [,] clause ... ] new-line
5931	```
5932
5933	where clause is one of the following:
5934
5935	```c
5936	to(extended-list)
5937	link(list)
5938	device_type(host \| nohost \| any)
5939	```)reST";
5940
5941	static const char AttrDoc_OMPDeclareVariant[] = R"reST(The `declare variant` directive declares a specialized variant of a base
5942	function and specifies the context in which that specialized variant is used.
5943	The declare variant directive is a declarative directive.
5944	The syntax of the `declare variant` construct is as follows:
5945
5946	```none
5947	#pragma omp declare variant(variant-func-id) clause new-line
5948	[#pragma omp declare variant(variant-func-id) clause new-line]
5949	[...]
5950	function definition or declaration
5951	```
5952
5953	where clause is one of the following:
5954
5955	```none
5956	match(context-selector-specification)
5957	```
5958
5959	and where `variant-func-id` is the name of a function variant that is either a
5960	base language identifier or, for C++, a template-id.
5961
5962	Clang provides the following context selector extensions, used via
5963	`implementation={extension(EXTENSION)}`:
5964
5965	```none
5966	match_all
5967	match_any
5968	match_none
5969	disable_implicit_base
5970	allow_templates
5971	bind_to_declaration
5972	```
5973
5974	The match extensions change when the entire context selector is considered a
5975	match for an OpenMP context. The default is `all`, with `none` no trait in the
5976	selector is allowed to be in the OpenMP context, with `any` a single trait in
5977	both the selector and OpenMP context is sufficient. Only a single match
5978	extension trait is allowed per context selector.
5979	The disable extensions remove default effects of the `begin declare variant`
5980	applied to a definition. If `disable_implicit_base` is given, we will not
5981	introduce an implicit base function for a variant if no base function was
5982	found. The variant is still generated but will never be called, due to the
5983	absence of a base function and consequently calls to a base function.
5984	The allow extensions change when the `begin declare variant` effect is
5985	applied to a definition. If `allow_templates` is given, template function
5986	definitions are considered as specializations of existing or assumed template
5987	declarations with the same name. The template parameters for the base functions
5988	are used to instantiate the specialization. If `bind_to_declaration` is given,
5989	apply the same variant rules to function declarations. This allows the user to
5990	override declarations with only a function declaration.)reST";
5991
5992	static const char AttrDoc_OMPGroupPrivateDecl[] = R"reST()reST";
5993
5994	static const char AttrDoc_OMPInvariantPredicateBound[] = R"reST()reST";
5995
5996	static const char AttrDoc_OMPReferencedVar[] = R"reST()reST";
5997
5998	static const char AttrDoc_OMPTargetIndirectCall[] = R"reST()reST";
5999
6000	static const char AttrDoc_OMPThreadPrivateDecl[] = R"reST()reST";
6001
6002	static const char AttrDoc_OSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6003	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6004	convention (e.g. functions starting with "get" are assumed to return at
6005	`+0`).
6006
6007	It can be overridden using a family of the following attributes. In
6008	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6009	a function communicates that the object is returned at `+1`, and the caller
6010	is responsible for freeing it.
6011	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6012	specifies that the object is returned at `+0` and the ownership remains with
6013	the callee.
6014	The annotation `__attribute__((ns_consumes_self))` specifies that
6015	the Objective-C method call consumes the reference to `self`, e.g. by
6016	attaching it to a supplied parameter.
6017	Additionally, parameters can have an annotation
6018	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6019	as that parameter effectively transfers the ownership, and the caller is no
6020	longer responsible for it.
6021	These attributes affect code generation when interacting with ARC code, and
6022	they are used by the Clang Static Analyzer.
6023
6024	In C programs using CoreFoundation, a similar set of attributes:
6025	`__attribute__((cf_returns_not_retained))`,
6026	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6027	have the same respective semantics when applied to CoreFoundation objects.
6028	These attributes affect code generation when interacting with ARC code, and
6029	they are used by the Clang Static Analyzer.
6030
6031	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6032	the same attribute family is present:
6033	`__attribute__((os_returns_not_retained))`,
6034	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6035	with the same respective semantics.
6036	Similar to `__attribute__((ns_consumes_self))`,
6037	`__attribute__((os_consumes_this))` specifies that the method call consumes
6038	the reference to "this" (e.g., when attaching it to a different object supplied
6039	as a parameter).
6040	Out parameters (parameters the function is meant to write into,
6041	either via pointers-to-pointers or references-to-pointers)
6042	may be annotated with `__attribute__((os_returns_retained))`
6043	or `__attribute__((os_returns_not_retained))` which specifies that the object
6044	written into the out parameter should (or respectively should not) be released
6045	after use.
6046	Since often out parameters may or may not be written depending on the exit
6047	code of the function,
6048	annotations `__attribute__((os_returns_retained_on_zero))`
6049	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6050	an out parameter at `+1` is written if and only if the function returns a zero
6051	(respectively non-zero) error code.
6052	Observe that return-code-dependent out parameter annotations are only
6053	available for retained out parameters, as non-retained object do not have to be
6054	released by the callee.
6055	These attributes are only used by the Clang Static Analyzer.
6056
6057	The family of attributes `X_returns_X_retained` can be added to functions,
6058	C++ methods, and Objective-C methods and properties.
6059	Attributes `X_consumed` can be added to parameters of methods, functions,
6060	and Objective-C methods.)reST";
6061
6062	static const char AttrDoc_OSConsumesThis[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6063	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6064	convention (e.g. functions starting with "get" are assumed to return at
6065	`+0`).
6066
6067	It can be overridden using a family of the following attributes. In
6068	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6069	a function communicates that the object is returned at `+1`, and the caller
6070	is responsible for freeing it.
6071	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6072	specifies that the object is returned at `+0` and the ownership remains with
6073	the callee.
6074	The annotation `__attribute__((ns_consumes_self))` specifies that
6075	the Objective-C method call consumes the reference to `self`, e.g. by
6076	attaching it to a supplied parameter.
6077	Additionally, parameters can have an annotation
6078	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6079	as that parameter effectively transfers the ownership, and the caller is no
6080	longer responsible for it.
6081	These attributes affect code generation when interacting with ARC code, and
6082	they are used by the Clang Static Analyzer.
6083
6084	In C programs using CoreFoundation, a similar set of attributes:
6085	`__attribute__((cf_returns_not_retained))`,
6086	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6087	have the same respective semantics when applied to CoreFoundation objects.
6088	These attributes affect code generation when interacting with ARC code, and
6089	they are used by the Clang Static Analyzer.
6090
6091	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6092	the same attribute family is present:
6093	`__attribute__((os_returns_not_retained))`,
6094	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6095	with the same respective semantics.
6096	Similar to `__attribute__((ns_consumes_self))`,
6097	`__attribute__((os_consumes_this))` specifies that the method call consumes
6098	the reference to "this" (e.g., when attaching it to a different object supplied
6099	as a parameter).
6100	Out parameters (parameters the function is meant to write into,
6101	either via pointers-to-pointers or references-to-pointers)
6102	may be annotated with `__attribute__((os_returns_retained))`
6103	or `__attribute__((os_returns_not_retained))` which specifies that the object
6104	written into the out parameter should (or respectively should not) be released
6105	after use.
6106	Since often out parameters may or may not be written depending on the exit
6107	code of the function,
6108	annotations `__attribute__((os_returns_retained_on_zero))`
6109	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6110	an out parameter at `+1` is written if and only if the function returns a zero
6111	(respectively non-zero) error code.
6112	Observe that return-code-dependent out parameter annotations are only
6113	available for retained out parameters, as non-retained object do not have to be
6114	released by the callee.
6115	These attributes are only used by the Clang Static Analyzer.
6116
6117	The family of attributes `X_returns_X_retained` can be added to functions,
6118	C++ methods, and Objective-C methods and properties.
6119	Attributes `X_consumed` can be added to parameters of methods, functions,
6120	and Objective-C methods.)reST";
6121
6122	static const char AttrDoc_OSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6123	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6124	convention (e.g. functions starting with "get" are assumed to return at
6125	`+0`).
6126
6127	It can be overridden using a family of the following attributes. In
6128	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6129	a function communicates that the object is returned at `+1`, and the caller
6130	is responsible for freeing it.
6131	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6132	specifies that the object is returned at `+0` and the ownership remains with
6133	the callee.
6134	The annotation `__attribute__((ns_consumes_self))` specifies that
6135	the Objective-C method call consumes the reference to `self`, e.g. by
6136	attaching it to a supplied parameter.
6137	Additionally, parameters can have an annotation
6138	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6139	as that parameter effectively transfers the ownership, and the caller is no
6140	longer responsible for it.
6141	These attributes affect code generation when interacting with ARC code, and
6142	they are used by the Clang Static Analyzer.
6143
6144	In C programs using CoreFoundation, a similar set of attributes:
6145	`__attribute__((cf_returns_not_retained))`,
6146	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6147	have the same respective semantics when applied to CoreFoundation objects.
6148	These attributes affect code generation when interacting with ARC code, and
6149	they are used by the Clang Static Analyzer.
6150
6151	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6152	the same attribute family is present:
6153	`__attribute__((os_returns_not_retained))`,
6154	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6155	with the same respective semantics.
6156	Similar to `__attribute__((ns_consumes_self))`,
6157	`__attribute__((os_consumes_this))` specifies that the method call consumes
6158	the reference to "this" (e.g., when attaching it to a different object supplied
6159	as a parameter).
6160	Out parameters (parameters the function is meant to write into,
6161	either via pointers-to-pointers or references-to-pointers)
6162	may be annotated with `__attribute__((os_returns_retained))`
6163	or `__attribute__((os_returns_not_retained))` which specifies that the object
6164	written into the out parameter should (or respectively should not) be released
6165	after use.
6166	Since often out parameters may or may not be written depending on the exit
6167	code of the function,
6168	annotations `__attribute__((os_returns_retained_on_zero))`
6169	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6170	an out parameter at `+1` is written if and only if the function returns a zero
6171	(respectively non-zero) error code.
6172	Observe that return-code-dependent out parameter annotations are only
6173	available for retained out parameters, as non-retained object do not have to be
6174	released by the callee.
6175	These attributes are only used by the Clang Static Analyzer.
6176
6177	The family of attributes `X_returns_X_retained` can be added to functions,
6178	C++ methods, and Objective-C methods and properties.
6179	Attributes `X_consumed` can be added to parameters of methods, functions,
6180	and Objective-C methods.)reST";
6181
6182	static const char AttrDoc_OSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6183	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6184	convention (e.g. functions starting with "get" are assumed to return at
6185	`+0`).
6186
6187	It can be overridden using a family of the following attributes. In
6188	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6189	a function communicates that the object is returned at `+1`, and the caller
6190	is responsible for freeing it.
6191	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6192	specifies that the object is returned at `+0` and the ownership remains with
6193	the callee.
6194	The annotation `__attribute__((ns_consumes_self))` specifies that
6195	the Objective-C method call consumes the reference to `self`, e.g. by
6196	attaching it to a supplied parameter.
6197	Additionally, parameters can have an annotation
6198	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6199	as that parameter effectively transfers the ownership, and the caller is no
6200	longer responsible for it.
6201	These attributes affect code generation when interacting with ARC code, and
6202	they are used by the Clang Static Analyzer.
6203
6204	In C programs using CoreFoundation, a similar set of attributes:
6205	`__attribute__((cf_returns_not_retained))`,
6206	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6207	have the same respective semantics when applied to CoreFoundation objects.
6208	These attributes affect code generation when interacting with ARC code, and
6209	they are used by the Clang Static Analyzer.
6210
6211	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6212	the same attribute family is present:
6213	`__attribute__((os_returns_not_retained))`,
6214	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6215	with the same respective semantics.
6216	Similar to `__attribute__((ns_consumes_self))`,
6217	`__attribute__((os_consumes_this))` specifies that the method call consumes
6218	the reference to "this" (e.g., when attaching it to a different object supplied
6219	as a parameter).
6220	Out parameters (parameters the function is meant to write into,
6221	either via pointers-to-pointers or references-to-pointers)
6222	may be annotated with `__attribute__((os_returns_retained))`
6223	or `__attribute__((os_returns_not_retained))` which specifies that the object
6224	written into the out parameter should (or respectively should not) be released
6225	after use.
6226	Since often out parameters may or may not be written depending on the exit
6227	code of the function,
6228	annotations `__attribute__((os_returns_retained_on_zero))`
6229	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6230	an out parameter at `+1` is written if and only if the function returns a zero
6231	(respectively non-zero) error code.
6232	Observe that return-code-dependent out parameter annotations are only
6233	available for retained out parameters, as non-retained object do not have to be
6234	released by the callee.
6235	These attributes are only used by the Clang Static Analyzer.
6236
6237	The family of attributes `X_returns_X_retained` can be added to functions,
6238	C++ methods, and Objective-C methods and properties.
6239	Attributes `X_consumed` can be added to parameters of methods, functions,
6240	and Objective-C methods.)reST";
6241
6242	static const char AttrDoc_OSReturnsRetainedOnNonZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6243	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6244	convention (e.g. functions starting with "get" are assumed to return at
6245	`+0`).
6246
6247	It can be overridden using a family of the following attributes. In
6248	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6249	a function communicates that the object is returned at `+1`, and the caller
6250	is responsible for freeing it.
6251	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6252	specifies that the object is returned at `+0` and the ownership remains with
6253	the callee.
6254	The annotation `__attribute__((ns_consumes_self))` specifies that
6255	the Objective-C method call consumes the reference to `self`, e.g. by
6256	attaching it to a supplied parameter.
6257	Additionally, parameters can have an annotation
6258	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6259	as that parameter effectively transfers the ownership, and the caller is no
6260	longer responsible for it.
6261	These attributes affect code generation when interacting with ARC code, and
6262	they are used by the Clang Static Analyzer.
6263
6264	In C programs using CoreFoundation, a similar set of attributes:
6265	`__attribute__((cf_returns_not_retained))`,
6266	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6267	have the same respective semantics when applied to CoreFoundation objects.
6268	These attributes affect code generation when interacting with ARC code, and
6269	they are used by the Clang Static Analyzer.
6270
6271	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6272	the same attribute family is present:
6273	`__attribute__((os_returns_not_retained))`,
6274	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6275	with the same respective semantics.
6276	Similar to `__attribute__((ns_consumes_self))`,
6277	`__attribute__((os_consumes_this))` specifies that the method call consumes
6278	the reference to "this" (e.g., when attaching it to a different object supplied
6279	as a parameter).
6280	Out parameters (parameters the function is meant to write into,
6281	either via pointers-to-pointers or references-to-pointers)
6282	may be annotated with `__attribute__((os_returns_retained))`
6283	or `__attribute__((os_returns_not_retained))` which specifies that the object
6284	written into the out parameter should (or respectively should not) be released
6285	after use.
6286	Since often out parameters may or may not be written depending on the exit
6287	code of the function,
6288	annotations `__attribute__((os_returns_retained_on_zero))`
6289	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6290	an out parameter at `+1` is written if and only if the function returns a zero
6291	(respectively non-zero) error code.
6292	Observe that return-code-dependent out parameter annotations are only
6293	available for retained out parameters, as non-retained object do not have to be
6294	released by the callee.
6295	These attributes are only used by the Clang Static Analyzer.
6296
6297	The family of attributes `X_returns_X_retained` can be added to functions,
6298	C++ methods, and Objective-C methods and properties.
6299	Attributes `X_consumed` can be added to parameters of methods, functions,
6300	and Objective-C methods.)reST";
6301
6302	static const char AttrDoc_OSReturnsRetainedOnZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
6303	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
6304	convention (e.g. functions starting with "get" are assumed to return at
6305	`+0`).
6306
6307	It can be overridden using a family of the following attributes. In
6308	Objective-C, the annotation `__attribute__((ns_returns_retained))` applied to
6309	a function communicates that the object is returned at `+1`, and the caller
6310	is responsible for freeing it.
6311	Similarly, the annotation `__attribute__((ns_returns_not_retained))`
6312	specifies that the object is returned at `+0` and the ownership remains with
6313	the callee.
6314	The annotation `__attribute__((ns_consumes_self))` specifies that
6315	the Objective-C method call consumes the reference to `self`, e.g. by
6316	attaching it to a supplied parameter.
6317	Additionally, parameters can have an annotation
6318	`__attribute__((ns_consumed))`, which specifies that passing an owned object
6319	as that parameter effectively transfers the ownership, and the caller is no
6320	longer responsible for it.
6321	These attributes affect code generation when interacting with ARC code, and
6322	they are used by the Clang Static Analyzer.
6323
6324	In C programs using CoreFoundation, a similar set of attributes:
6325	`__attribute__((cf_returns_not_retained))`,
6326	`__attribute__((cf_returns_retained))` and `__attribute__((cf_consumed))`
6327	have the same respective semantics when applied to CoreFoundation objects.
6328	These attributes affect code generation when interacting with ARC code, and
6329	they are used by the Clang Static Analyzer.
6330
6331	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
6332	the same attribute family is present:
6333	`__attribute__((os_returns_not_retained))`,
6334	`__attribute__((os_returns_retained))` and `__attribute__((os_consumed))`,
6335	with the same respective semantics.
6336	Similar to `__attribute__((ns_consumes_self))`,
6337	`__attribute__((os_consumes_this))` specifies that the method call consumes
6338	the reference to "this" (e.g., when attaching it to a different object supplied
6339	as a parameter).
6340	Out parameters (parameters the function is meant to write into,
6341	either via pointers-to-pointers or references-to-pointers)
6342	may be annotated with `__attribute__((os_returns_retained))`
6343	or `__attribute__((os_returns_not_retained))` which specifies that the object
6344	written into the out parameter should (or respectively should not) be released
6345	after use.
6346	Since often out parameters may or may not be written depending on the exit
6347	code of the function,
6348	annotations `__attribute__((os_returns_retained_on_zero))`
6349	and `__attribute__((os_returns_retained_on_non_zero))` specify that
6350	an out parameter at `+1` is written if and only if the function returns a zero
6351	(respectively non-zero) error code.
6352	Observe that return-code-dependent out parameter annotations are only
6353	available for retained out parameters, as non-retained object do not have to be
6354	released by the callee.
6355	These attributes are only used by the Clang Static Analyzer.
6356
6357	The family of attributes `X_returns_X_retained` can be added to functions,
6358	C++ methods, and Objective-C methods and properties.
6359	Attributes `X_consumed` can be added to parameters of methods, functions,
6360	and Objective-C methods.)reST";
6361
6362	static const char AttrDoc_ObjCBoxable[] = R"reST(Structs and unions marked with the `objc_boxable` attribute can be used
6363	with the Objective-C boxed expression syntax, `@(...)`.
6364
6365	Usage: `__attribute__((objc_boxable))`. This attribute
6366	can only be placed on a declaration of a trivially-copyable struct or union:
6367
6368	```objc
6369	struct __attribute__((objc_boxable)) some_struct {
6370	int i;
6371	};
6372	union __attribute__((objc_boxable)) some_union {
6373	int i;
6374	float f;
6375	};
6376	typedef struct __attribute__((objc_boxable)) _some_struct some_struct;
6377
6378	// ...
6379
6380	some_struct ss;
6381	NSValue *boxed = @(ss);
6382	```)reST";
6383
6384	static const char AttrDoc_ObjCBridge[] = R"reST(No documentation.)reST";
6385
6386	static const char AttrDoc_ObjCBridgeMutable[] = R"reST(No documentation.)reST";
6387
6388	static const char AttrDoc_ObjCBridgeRelated[] = R"reST(No documentation.)reST";
6389
6390	static const char AttrDoc_ObjCClassStub[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
6391	instantiated at runtime.
6392
6393	Unlike `__attribute__((objc_runtime_visible))`, a class having this attribute
6394	still has a "class stub" that is visible to the linker. This allows categories
6395	to be defined. Static message sends with the class as a receiver use a special
6396	access pattern to ensure the class is lazily instantiated from the class stub.
6397
6398	Classes annotated with this attribute cannot be subclassed and cannot have
6399	implementations defined for them. This attribute is intended for use in
6400	Swift-generated headers for classes defined in Swift.
6401
6402	Adding or removing this attribute to a class is an ABI-breaking change.)reST";
6403
6404	static const char AttrDoc_ObjCDesignatedInitializer[] = R"reST(No documentation.)reST";
6405
6406	static const char AttrDoc_ObjCDirect[] = R"reST(The `objc_direct` attribute can be used to mark an Objective-C method as
6407	being direct. A direct method is treated statically like an ordinary method,
6408	but dynamically it behaves more like a C function. This lowers some of the costs
6409	associated with the method but also sacrifices some of the ordinary capabilities
6410	of Objective-C methods.
6411
6412	A message send of a direct method calls the implementation directly, as if it
6413	were a C function, rather than using ordinary Objective-C method dispatch. This
6414	is substantially faster and potentially allows the implementation to be inlined,
6415	but it also means the method cannot be overridden in subclasses or replaced
6416	dynamically, as ordinary Objective-C methods can.
6417
6418	Furthermore, a direct method is not listed in the class's method lists. This
6419	substantially reduces the code-size overhead of the method but also means it
6420	cannot be called dynamically using ordinary Objective-C method dispatch at all;
6421	in particular, this means that it cannot override a superclass method or satisfy
6422	a protocol requirement.
6423
6424	Because a direct method cannot be overridden, it is an error to perform
6425	a `super` message send of one.
6426
6427	Although a message send of a direct method causes the method to be called
6428	directly as if it were a C function, it still obeys Objective-C semantics in other
6429	ways:
6430
6431	- If the receiver is `nil`, the message send does nothing and returns the zero value
6432	for the return type.
6433	- A message send of a direct class method will cause the class to be initialized,
6434	including calling the `+initialize` method if present.
6435	- The implicit `_cmd` parameter containing the method's selector is still defined.
6436	In order to minimize code-size costs, the implementation will not emit a reference
6437	to the selector if the parameter is unused within the method.
6438
6439	Symbols for direct method implementations are implicitly given hidden
6440	visibility, meaning that they can only be called within the same linkage unit.
6441
6442	It is an error to do any of the following:
6443
6444	- declare a direct method in a protocol,
6445	- declare an override of a direct method with a method in a subclass,
6446	- declare an override of a non-direct method with a direct method in a subclass,
6447	- declare a method with different directness in different class interfaces, or
6448	- implement a non-direct method (as declared in any class interface) with a direct method.
6449
6450	If any of these rules would be violated if every method defined in an
6451	`@implementation` within a single linkage unit were declared in an
6452	appropriate class interface, the program is ill-formed with no diagnostic
6453	required. If a violation of this rule is not diagnosed, behavior remains
6454	well-defined; this paragraph is simply reserving the right to diagnose such
6455	conflicts in the future, not to treat them as undefined behavior.
6456
6457	Additionally, Clang will warn about any `@selector` expression that
6458	names a selector that is only known to be used for direct methods.
6459
6460	For the purpose of these rules, a "class interface" includes a class's primary
6461	`@interface` block, its class extensions, its categories, its declared protocols,
6462	and all the class interfaces of its superclasses.
6463
6464	An Objective-C property can be declared with the `direct` property
6465	attribute. If a direct property declaration causes an implicit declaration of
6466	a getter or setter method (that is, if the given method is not explicitly
6467	declared elsewhere), the method is declared to be direct.
6468
6469	Some programmers may wish to make many methods direct at once. In order
6470	to simplify this, the `objc_direct_members` attribute is provided; see its
6471	documentation for more information.)reST";
6472
6473	static const char AttrDoc_ObjCDirectMembers[] = R"reST(The `objc_direct_members` attribute can be placed on an Objective-C
6474	`@interface` or `@implementation` to mark that methods declared
6475	therein should be considered direct by default. See the documentation
6476	for `objc_direct` for more information about direct methods.
6477
6478	When `objc_direct_members` is placed on an `@interface` block, every
6479	method in the block is considered to be declared as direct. This includes any
6480	implicit method declarations introduced by property declarations. If the method
6481	redeclares a non-direct method, the declaration is ill-formed, exactly as if the
6482	method was annotated with the `objc_direct` attribute.
6483
6484	When `objc_direct_members` is placed on an `@implementation` block,
6485	methods defined in the block are considered to be declared as direct unless
6486	they have been previously declared as non-direct in any interface of the class.
6487	This includes the implicit method definitions introduced by synthesized
6488	properties, including auto-synthesized properties.)reST";
6489
6490	static const char AttrDoc_ObjCException[] = R"reST(No documentation.)reST";
6491
6492	static const char AttrDoc_ObjCExplicitProtocolImpl[] = R"reST(No documentation.)reST";
6493
6494	static const char AttrDoc_ObjCExternallyRetained[] = R"reST(The `objc_externally_retained` attribute can be applied to strong local
6495	variables, functions, methods, or blocks to opt into
6496	{ref}`externally-retained semantics <arc.misc.externally_retained>`.
6497
6498	When applied to the definition of a function, method, or block, every parameter
6499	of the function with implicit strong retainable object pointer type is
6500	considered externally-retained, and becomes `const`. By explicitly annotating
6501	a parameter with `__strong`, you can opt back into the default
6502	non-externally-retained behavior for that parameter. For instance,
6503	`first_param` is externally-retained below, but not `second_param`:
6504
6505	```objc
6506	__attribute__((objc_externally_retained))
6507	void f(NSArray first_param, __strong NSArray second_param) {
6508	// ...
6509	}
6510	```
6511
6512	Likewise, when applied to a strong local variable, that variable becomes
6513	`const` and is considered externally-retained.
6514
6515	When compiled without `-fobjc-arc`, this attribute is ignored.)reST";
6516
6517	static const char AttrDoc_ObjCGC[] = R"reST(No documentation.)reST";
6518
6519	static const char AttrDoc_ObjCIndependentClass[] = R"reST(No documentation.)reST";
6520
6521	static const char AttrDoc_ObjCInertUnsafeUnretained[] = R"reST()reST";
6522
6523	static const char AttrDoc_ObjCKindOf[] = R"reST(No documentation.)reST";
6524
6525	static const char AttrDoc_ObjCMethodFamily[] = R"reST(Many methods in Objective-C have conventional meanings determined by their
6526	selectors. It is sometimes useful to be able to mark a method as having a
6527	particular conventional meaning despite not having the right selector, or as
6528	not having the conventional meaning that its selector would suggest. For these
6529	use cases, we provide an attribute to specifically describe the "method family"
6530	that a method belongs to.
6531
6532	Usage: `__attribute__((objc_method_family(X)))`, where `X` is one of
6533	`none`, `alloc`, `copy`, `init`, `mutableCopy`, or `new`. This
6534	attribute can only be placed at the end of a method declaration:
6535
6536	```objc
6537	- (NSString *)initMyStringValue __attribute__((objc_method_family(none)));
6538	```
6539
6540	Users who do not wish to change the conventional meaning of a method, and who
6541	merely want to document its non-standard retain and release semantics, should
6542	use the retaining behavior attributes (`ns_returns_retained`,
6543	`ns_returns_not_retained`, etc).
6544
6545	Query for this feature with `__has_attribute(objc_method_family)`.)reST";
6546
6547	static const char AttrDoc_ObjCNSObject[] = R"reST(No documentation.)reST";
6548
6549	static const char AttrDoc_ObjCNonLazyClass[] = R"reST(This attribute can be added to an Objective-C `@interface` or
6550	`@implementation` declaration to add the class to the list of non-lazily
6551	initialized classes. A non-lazy class will be initialized eagerly when the
6552	Objective-C runtime is loaded. This is required for certain system classes which
6553	have instances allocated in non-standard ways, such as the classes for blocks
6554	and constant strings. Adding this attribute is essentially equivalent to
6555	providing a trivial `+load` method but avoids the (fairly small) load-time
6556	overheads associated with defining and calling such a method.)reST";
6557
6558	static const char AttrDoc_ObjCNonRuntimeProtocol[] = R"reST(The `objc_non_runtime_protocol` attribute can be used to mark that an
6559	Objective-C protocol is only used during static type-checking and doesn't need
6560	to be represented dynamically. This avoids several small code-size and run-time
6561	overheads associated with handling the protocol's metadata. A non-runtime
6562	protocol cannot be used as the operand of a `@protocol` expression, and
6563	dynamic attempts to find it with `objc_getProtocol` will fail.
6564
6565	If a non-runtime protocol inherits from any ordinary protocols, classes and
6566	derived protocols that declare conformance to the non-runtime protocol will
6567	dynamically list their conformance to those bare protocols.)reST";
6568
6569	static const char AttrDoc_ObjCOwnership[] = R"reST(No documentation.)reST";
6570
6571	static const char AttrDoc_ObjCPreciseLifetime[] = R"reST(No documentation.)reST";
6572
6573	static const char AttrDoc_ObjCRequiresPropertyDefs[] = R"reST(No documentation.)reST";
6574
6575	static const char AttrDoc_ObjCRequiresSuper[] = R"reST(Some Objective-C classes allow a subclass to override a particular method in a
6576	parent class but expect that the overriding method also calls the overridden
6577	method in the parent class. For these cases, we provide an attribute to
6578	designate that a method requires a "call to `super`" in the overriding
6579	method in the subclass.
6580
6581	Usage: `__attribute__((objc_requires_super))`. This attribute can only
6582	be placed at the end of a method declaration:
6583
6584	```objc
6585	- (void)foo __attribute__((objc_requires_super));
6586	```
6587
6588	This attribute can only be applied the method declarations within a class, and
6589	not a protocol. Currently this attribute does not enforce any placement of
6590	where the call occurs in the overriding method (such as in the case of
6591	`-dealloc` where the call must appear at the end). It checks only that it
6592	exists.
6593
6594	Note that on both OS X and iOS that the Foundation framework provides a
6595	convenience macro `NS_REQUIRES_SUPER` that provides syntactic sugar for this
6596	attribute:
6597
6598	```objc
6599	- (void)foo NS_REQUIRES_SUPER;
6600	```
6601
6602	This macro is conditionally defined depending on the compiler's support for
6603	this attribute. If the compiler does not support the attribute the macro
6604	expands to nothing.
6605
6606	Operationally, when a method has this annotation the compiler will warn if the
6607	implementation of an override in a subclass does not call super. For example:
6608
6609	```objc
6610	warning: method possibly missing a [super AnnotMeth] call
6611	- (void) AnnotMeth{};
6612	^
6613	```)reST";
6614
6615	static const char AttrDoc_ObjCReturnsInnerPointer[] = R"reST(No documentation.)reST";
6616
6617	static const char AttrDoc_ObjCRootClass[] = R"reST(No documentation.)reST";
6618
6619	static const char AttrDoc_ObjCRuntimeName[] = R"reST(By default, the Objective-C interface or protocol identifier is used
6620	in the metadata name for that object. The `objc_runtime_name`
6621	attribute allows annotated interfaces or protocols to use the
6622	specified string argument in the object's metadata name instead of the
6623	default name.
6624
6625	Usage: `__attribute__((objc_runtime_name("MyLocalName")))`. This attribute
6626	can only be placed before an @protocol or @interface declaration:
6627
6628	```objc
6629	__attribute__((objc_runtime_name("MyLocalName")))
6630	@interface Message
6631	@end
6632	```)reST";
6633
6634	static const char AttrDoc_ObjCRuntimeVisible[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
6635	visible to the Objective-C runtime but not to the linker. Classes annotated
6636	with this attribute cannot be subclassed and cannot have categories defined for
6637	them.)reST";
6638
6639	static const char AttrDoc_ObjCSubclassingRestricted[] = R"reST(This attribute can be added to an Objective-C `@interface` declaration to
6640	ensure that this class cannot be subclassed.)reST";
6641
6642	static const char AttrDoc_OpenACCRoutineAnnot[] = R"reST()reST";
6643
6644	static const char AttrDoc_OpenACCRoutineDecl[] = R"reST()reST";
6645
6646	static const char AttrDoc_OpenCLAccess[] = R"reST(The access qualifiers must be used with image object arguments or pipe arguments
6647	to declare if they are being read or written by a kernel or function.
6648
6649	The read_only/\_\_read_only, write_only/\_\_write_only and read_write/\_\_read_write
6650	names are reserved for use as access qualifiers and shall not be used otherwise.
6651
6652	```c
6653	kernel void
6654	foo (read_only image2d_t imageA,
6655	write_only image2d_t imageB) {
6656	...
6657	}
6658	```
6659
6660	In the above example imageA is a read-only 2D image object, and imageB is a
6661	write-only 2D image object.
6662
6663	The read_write (or \_\_read_write) qualifier can not be used with pipe.
6664
6665	More details can be found in the OpenCL C language Spec v2.0, Section 6.6.)reST";
6666
6667	static const char AttrDoc_OpenCLConstantAddressSpace[] = R"reST(The constant address space attribute signals that an object is located in
6668	a constant (non-modifiable) memory region. It is available to all work items.
6669	Any type can be annotated with the constant address space attribute. Objects
6670	with the constant address space qualifier can be declared in any scope and must
6671	have an initializer.)reST";
6672
6673	static const char AttrDoc_OpenCLGenericAddressSpace[] = R"reST(The generic address space attribute is only available with OpenCL v2.0 and later.
6674	It can be used with pointer types. Variables in global and local scope and
6675	function parameters in non-kernel functions can have the generic address space
6676	type attribute. It is intended to be a placeholder for any other address space
6677	except for '\_\_constant' in OpenCL code which can be used with multiple address
6678	spaces.)reST";
6679
6680	static const char AttrDoc_OpenCLGlobalAddressSpace[] = R"reST(The global address space attribute specifies that an object is allocated in
6681	global memory, which is accessible by all work items. The content stored in this
6682	memory area persists between kernel executions. Pointer types to the global
6683	address space are allowed as function parameters or local variables. Starting
6684	with OpenCL v2.0, the global address space can be used with global (program
6685	scope) variables and static local variable as well.)reST";
6686
6687	static const char AttrDoc_OpenCLGlobalDeviceAddressSpace[] = R"reST(The `global_device` and `global_host` address space attributes specify that
6688	an object is allocated in global memory on the device/host. It helps to
6689	distinguish USM (Unified Shared Memory) pointers that access global device
6690	memory from those that access global host memory. These new address spaces are
6691	a subset of the `__global/opencl_global` address space, the full address space
6692	set model for OpenCL 2.0 with the extension looks as follows:
6693
6694	```text
6695	generic->global->host
6696	->device
6697	->private
6698	->local
6699	constant
6700	```
6701
6702	As `global_device` and `global_host` are a subset of
6703	`__global/opencl_global` address spaces it is allowed to convert
6704	`global_device` and `global_host` address spaces to
6705	`__global/opencl_global` address spaces (following ISO/IEC TR 18037 5.1.3
6706	"Address space nesting and rules for pointers").
6707
6708	These attributes are deprecated and may be removed in a future version of Clang.)reST";
6709
6710	static const char AttrDoc_OpenCLGlobalHostAddressSpace[] = R"reST(The `global_device` and `global_host` address space attributes specify that
6711	an object is allocated in global memory on the device/host. It helps to
6712	distinguish USM (Unified Shared Memory) pointers that access global device
6713	memory from those that access global host memory. These new address spaces are
6714	a subset of the `__global/opencl_global` address space, the full address space
6715	set model for OpenCL 2.0 with the extension looks as follows:
6716
6717	```text
6718	generic->global->host
6719	->device
6720	->private
6721	->local
6722	constant
6723	```
6724
6725	As `global_device` and `global_host` are a subset of
6726	`__global/opencl_global` address spaces it is allowed to convert
6727	`global_device` and `global_host` address spaces to
6728	`__global/opencl_global` address spaces (following ISO/IEC TR 18037 5.1.3
6729	"Address space nesting and rules for pointers").
6730
6731	These attributes are deprecated and may be removed in a future version of Clang.)reST";
6732
6733	static const char AttrDoc_OpenCLIntelReqdSubGroupSize[] = R"reST(The optional attribute intel_reqd_sub_group_size can be used to indicate that
6734	the kernel must be compiled and executed with the specified subgroup size. When
6735	this attribute is present, get_max_sub_group_size() is guaranteed to return the
6736	specified integer value. This is important for the correctness of many subgroup
6737	algorithms, and in some cases may be used by the compiler to generate more optimal
6738	code. See `cl_intel_required_subgroup_size
6739	<https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt>`
6740	for details.)reST";
6741
6742	static const char AttrDoc_OpenCLLocalAddressSpace[] = R"reST(The local address space specifies that an object is allocated in the local (work
6743	group) memory area, which is accessible to all work items in the same work
6744	group. The content stored in this memory region is not accessible after
6745	the kernel execution ends. In a kernel function scope, any variable can be in
6746	the local address space. In other scopes, only pointer types to the local address
6747	space are allowed. Local address space variables cannot have an initializer.)reST";
6748
6749	static const char AttrDoc_OpenCLPrivateAddressSpace[] = R"reST(The private address space specifies that an object is allocated in the private
6750	(work item) memory. Other work items cannot access the same memory area and its
6751	content is destroyed after work item execution ends. Local variables can be
6752	declared in the private address space. Function arguments are always in the
6753	private address space. Kernel function arguments of a pointer or an array type
6754	cannot point to the private address space.)reST";
6755
6756	static const char AttrDoc_OpenCLUnrollHint[] = R"reST(The opencl_unroll_hint attribute qualifier can be used to specify that a loop
6757	(for, while and do loops) can be unrolled. This attribute qualifier can be
6758	used to specify full unrolling or partial unrolling by a specified amount.
6759	This is a compiler hint and the compiler may ignore this directive. See
6760	[OpenCL v2.0](https://www.khronos.org/registry/cl/specs/opencl-2.0.pdf)
6761	s6.11.5 for details.)reST";
6762
6763	static const char AttrDoc_OptimizeNone[] = R"reST(The `optnone` attribute suppresses essentially all optimizations
6764	on a function or method, regardless of the optimization level applied to
6765	the compilation unit as a whole. This is particularly useful when you
6766	need to debug a particular function, but it is infeasible to build the
6767	entire application without optimization. Avoiding optimization on the
6768	specified function can improve the quality of the debugging information
6769	for that function.
6770
6771	This attribute is incompatible with the `always_inline` and `minsize`
6772	attributes.
6773
6774	Note that this attribute does not apply recursively to nested functions such as
6775	lambdas or blocks when using declaration-specific attribute syntaxes such as double
6776	square brackets (`[[]]`) or `__attribute__`. The `#pragma` syntax can be
6777	used to apply the attribute to all functions, including nested functions, in a
6778	range of source code.)reST";
6779
6780	static const char AttrDoc_OverflowBehavior[] = R"reST(The `overflow_behavior` attribute provides fine-grained, type-level control
6781	over how arithmetic operations on an integer type behave on overflow. It may be
6782	applied to a `typedef`, to a variable or data member, or to an integer type
6783	directly, and accepts one of two behaviors as its argument:
6784
6785	- `wrap`: arithmetic on the attributed type wraps on overflow, using two's
6786	complement semantics. This is equivalent to `-fwrapv` but scoped to the
6787	attributed type, and works for both signed and unsigned types. UBSan's
6788	`signed-integer-overflow`, `unsigned-integer-overflow`,
6789	`implicit-signed-integer-truncation`, and
6790	`implicit-unsigned-integer-truncation` checks are suppressed for the type.
6791	- `trap`: arithmetic on the attributed type is checked for overflow, enabling
6792	overflow checks for the type even when `-fwrapv` is in effect globally.
6793
6794	```c++
6795	typedef unsigned int __attribute__((overflow_behavior(trap))) non_wrapping_uint;
6796
6797	non_wrapping_uint add_one(non_wrapping_uint a) {
6798	return a + 1; // Overflow is checked for this operation.
6799	}
6800
6801	int mul_alot(int n) {
6802	int __attribute__((overflow_behavior(wrap))) a = n;
6803	return a * 1337; // Overflow is not checked and is well-defined.
6804	}
6805	```
6806
6807	The keyword spellings `__ob_wrap` and `__ob_trap` are equivalent to
6808	`overflow_behavior(wrap)` and `overflow_behavior(trap)` respectively.
6809
6810	The attribute wholly overrides global flags (`-ftrapv`, `-fwrapv`,
6811	sanitizers, and Sanitizer Special Case Lists) for the attributed type. It can
6812	only be applied to integer types.
6813
6814	This feature is experimental and must be enabled with the `-cc1` option
6815	`-fexperimental-overflow-behavior-types`. For full details on promotion and
6816	conversion rules, pointer semantics, diagnostics, and interaction with
6817	sanitizers, see {doc}`OverflowBehaviorTypes`.)reST";
6818
6819	static const char AttrDoc_Overloadable[] = R"reST(Clang provides support for C++ function overloading in C. Function overloading
6820	in C is introduced using the `overloadable` attribute. For example, one
6821	might provide several overloaded versions of a `tgsin` function that invokes
6822	the appropriate standard function computing the sine of a value with `float`,
6823	`double`, or `long double` precision:
6824
6825	```c
6826	#include <math.h>
6827	float __attribute__((overloadable)) tgsin(float x) { return sinf(x); }
6828	double __attribute__((overloadable)) tgsin(double x) { return sin(x); }
6829	long double __attribute__((overloadable)) tgsin(long double x) { return sinl(x); }
6830	```
6831
6832	Given these declarations, one can call `tgsin` with a `float` value to
6833	receive a `float` result, with a `double` to receive a `double` result,
6834	etc. Function overloading in C follows the rules of C++ function overloading
6835	to pick the best overload given the call arguments, with a few C-specific
6836	semantics:
6837
6838	- Conversion from `float` or `double` to `long double` is ranked as a
6839	floating-point promotion (per C99) rather than as a floating-point conversion
6840	(as in C++).
6841	- A conversion from a pointer of type `T` to a pointer of type `U` is
6842	considered a pointer conversion (with conversion rank) if `T` and `U` are
6843	compatible types.
6844	- A conversion from type `T` to a value of type `U` is permitted if `T`
6845	and `U` are compatible types. This conversion is given "conversion" rank.
6846	- If no viable candidates are otherwise available, we allow a conversion from a
6847	pointer of type `T` to a pointer of type `U`, where `T` and `U` are
6848	incompatible. This conversion is ranked below all other types of conversions.
6849	Please note: `U` lacking qualifiers that are present on `T` is sufficient
6850	for `T` and `U` to be incompatible.
6851
6852	The declaration of `overloadable` functions is restricted to function
6853	declarations and definitions. If a function is marked with the `overloadable`
6854	attribute, then all declarations and definitions of functions with that name,
6855	except for at most one (see the note below about unmarked overloads), must have
6856	the `overloadable` attribute. In addition, redeclarations of a function with
6857	the `overloadable` attribute must have the `overloadable` attribute, and
6858	redeclarations of a function without the `overloadable` attribute must not
6859	have the `overloadable` attribute. e.g.,
6860
6861	```c
6862	int f(int) __attribute__((overloadable));
6863	float f(float); // error: declaration of "f" must have the "overloadable" attribute
6864	int f(int); // error: redeclaration of "f" must have the "overloadable" attribute
6865
6866	int g(int) __attribute__((overloadable));
6867	int g(int) { } // error: redeclaration of "g" must also have the "overloadable" attribute
6868
6869	int h(int);
6870	int h(int) __attribute__((overloadable)); // error: declaration of "h" must not
6871	// have the "overloadable" attribute
6872	```
6873
6874	Functions marked `overloadable` must have prototypes. Therefore, the
6875	following code is ill-formed:
6876
6877	```c
6878	int h() __attribute__((overloadable)); // error: h does not have a prototype
6879	```
6880
6881	However, `overloadable` functions are allowed to use a ellipsis even if there
6882	are no named parameters (as is permitted in C++). This feature is particularly
6883	useful when combined with the `unavailable` attribute:
6884
6885	```c++
6886	void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error
6887	```
6888
6889	Functions declared with the `overloadable` attribute have their names mangled
6890	according to the same rules as C++ function names. For example, the three
6891	`tgsin` functions in our motivating example get the mangled names
6892	`_Z5tgsinf`, `_Z5tgsind`, and `_Z5tgsine`, respectively. There are two
6893	caveats to this use of name mangling:
6894
6895	- Future versions of Clang may change the name mangling of functions overloaded
6896	in C, so you should not depend on an specific mangling. To be completely
6897	safe, we strongly urge the use of `static inline` with `overloadable`
6898	functions.
6899	- The `overloadable` attribute has almost no meaning when used in C++,
6900	because names will already be mangled and functions are already overloadable.
6901	However, when an `overloadable` function occurs within an `extern "C"`
6902	linkage specification, its name will be mangled in the same way as it
6903	would in C.
6904
6905	For the purpose of backwards compatibility, at most one function with the same
6906	name as other `overloadable` functions may omit the `overloadable`
6907	attribute. In this case, the function without the `overloadable` attribute
6908	will not have its name mangled.
6909
6910	For example:
6911
6912	```c
6913	// Notes with mangled names assume Itanium mangling.
6914	int f(int);
6915	int f(double) __attribute__((overloadable));
6916	void foo() {
6917	f(5); // Emits a call to f (not _Z1fi, as it would with an overload that
6918	// was marked with overloadable).
6919	f(1.0); // Emits a call to _Z1fd.
6920	}
6921	```
6922
6923	Support for unmarked overloads is not present in some versions of clang. You may
6924	query for it using `__has_extension(overloadable_unmarked)`.
6925
6926	Query for this attribute with `__has_attribute(overloadable)`.)reST";
6927
6928	static const char AttrDoc_Override[] = R"reST()reST";
6929
6930	static const char AttrDoc_Owner[] = R"reST(:::{Note}
6931	This attribute is experimental and its effect on analysis is subject to change in
6932	a future version of clang.
6933	:::
6934
6935	The attribute `[[gsl::Owner(T)]]` applies to structs and classes that own an
6936	object of type `T`:
6937
6938	```
6939	class [[gsl::Owner(int)]] IntOwner {
6940	private:
6941	int value;
6942	public:
6943	int *getInt() { return &value; }
6944	};
6945	```
6946
6947	The argument `T` is optional and is ignored.
6948	This attribute may be used by analysis tools and has no effect on code
6949	generation. A `void` argument means that the class can own any type.
6950
6951	See [Pointer] for an example.)reST";
6952
6953	static const char AttrDoc_Ownership[] = R"reST(:::{note}
6954	In order for the Clang Static Analyzer to acknowledge these attributes, the
6955	`Optimistic` config needs to be set to true for the checker
6956	`unix.DynamicMemoryModeling`:
6957
6958	`-Xclang -analyzer-config -Xclang unix.DynamicMemoryModeling:Optimistic=true`
6959	:::
6960
6961	These attributes are used by the Clang Static Analyzer's dynamic memory modeling
6962	facilities to mark custom allocating/deallocating functions.
6963
6964	All 3 attributes' first parameter of type string is the type of the allocation:
6965	`malloc`, `new`, etc. to allow for catching {ref}`mismatched deallocation
6966	<unix-MismatchedDeallocator>` bugs. The allocation type can be any string, e.g.
6967	a function annotated with
6968	returning a piece of memory of type `lasagna` but freed with a function
6969	annotated to release `cheese` typed memory will result in mismatched
6970	deallocation warning.
6971
6972	The (currently) only allocation type having special meaning is `malloc` --
6973	the Clang Static Analyzer makes sure that allocating functions annotated with
6974	`malloc` are treated like they used the standard `malloc()`, and can be
6975	safely deallocated with the standard `free()`.
6976
6977	- Use `ownership_returns` to mark a function as an allocating function.
6978	It takes 1 or 2 arguments.
6979	The first argument is a user-provided identifier representing the "kind" of the allocation.
6980	This is basically what is enforced when checking the deallocation. This is mandatory.
6981	The second argument is optional.
6982	It represents the index of the parameter that represents the allocation size in bytes (counting from 1).
6983	The referenced parameter must have some integral type.
6984	This attribute may appear at most once per declaration.
6985	If this argument is not set, then tooling, such as the Clang Static Analyzer,
6986	won't be able to reason about the size of the allocation, thus check potential out-of-bounds accesses.
6987	However, such tooling could still warn if the wrong deallocation function
6988	was used for the `ownership_returns` attributed resource.
6989	If forward declarations have this attribute, those must have the same arguments.
6990	- Use `ownership_takes` to mark a function as a deallocating function. Takes 2
6991	arguments: the allocation type, and the index of the parameter that is being
6992	deallocated (counting from 1).
6993	- Use `ownership_holds` to mark that a function takes over the ownership of a
6994	piece of memory and will free it at some unspecified point in the future. Like
6995	`ownership_takes`, this takes 2 arguments: the allocation type, and the
6996	index of the parameter whose ownership will be taken over (counting from 1).
6997
6998	The annotations `ownership_takes` and `ownership_holds` both prevent memory
6999	leak reports (concerning the specified parameter); the difference between them
7000	is that using taken memory is a use-after-free error, while using held memory
7001	is assumed to be legitimate. However, releasing the held memory or passing it
7002	to another holding call is reported by the analyzer as an "attempt to release
7003	non-owned memory".
7004
7005	Example:
7006
7007	```c
7008	// Denotes that my_malloc will return with a dynamically allocated piece of
7009	// memory using malloc().
7010	void __attribute((ownership_returns(malloc))) *my_malloc(size_t sz);
7011
7012	// 'sz' (parameter 1) is the allocation size.
7013	void __attribute((ownership_returns(malloc, 1))) *my_sized_malloc(size_t sz);
7014
7015	// Denotes that my_free will deallocate its argument using free().
7016	void __attribute((ownership_takes(malloc, 1))) my_free(void *);
7017
7018	// Denotes that my_hold will take over the ownership of its argument that was
7019	// allocated via malloc().
7020	void __attribute((ownership_holds(malloc, 1))) my_hold(void *);
7021	```
7022
7023	Further reading about dynamic memory modeling in the Clang Static Analyzer is
7024	found in these checker docs:
7025	{ref}`unix.Malloc <unix-Malloc>`, {ref}`unix.MallocSizeof <unix-MallocSizeof>`,
7026	{ref}`unix.MismatchedDeallocator <unix-MismatchedDeallocator>`,
7027	{ref}`cplusplus.NewDelete <cplusplus-NewDelete>`,
7028	{ref}`cplusplus.NewDeleteLeaks <cplusplus-NewDeleteLeaks>`,
7029	{ref}`optin.taint.TaintedAlloc <optin-taint-TaintedAlloc>`.
7030	Mind that many more checkers are affected by dynamic memory modeling changes to
7031	some extent.
7032
7033	Further reading for other annotations:
7034	{doc}`Static Analyzer source annotations <analyzer/user-docs/Annotations>`.)reST";
7035
7036	static const char AttrDoc_Packed[] = R"reST(No documentation.)reST";
7037
7038	static const char AttrDoc_ParamTypestate[] = R"reST(This attribute specifies expectations about function parameters. Calls to an
7039	function with annotated parameters will issue a warning if the corresponding
7040	argument isn't in the expected state. The attribute is also used to set the
7041	initial state of the parameter when analyzing the function's body.)reST";
7042
7043	static const char AttrDoc_Pascal[] = R"reST(No documentation.)reST";
7044
7045	static const char AttrDoc_PassObjectSize[] = R"reST(:::{Note}
7046	The mangling of functions with parameters that are annotated with
7047	`pass_object_size` is subject to change. You can get around this by
7048	using `__asm__("foo")` to explicitly name your functions, thus preserving
7049	your ABI; also, non-overloadable C functions with `pass_object_size` are
7050	not mangled.
7051	:::
7052
7053	The `pass_object_size(Type)` attribute can be placed on function parameters to
7054	instruct clang to call `__builtin_object_size(param, Type)` at each callsite
7055	of said function, and implicitly pass the result of this call in as an invisible
7056	argument of type `size_t` directly after the parameter annotated with
7057	`pass_object_size`. Clang will also replace any calls to
7058	`__builtin_object_size(param, Type)` in the function by said implicit
7059	parameter.
7060
7061	Example usage:
7062
7063	```c
7064	int bzero1(char *const p __attribute__((pass_object_size(0))))
7065	__attribute__((noinline)) {
7066	int i = 0;
7067	for (/**/; i < (int)__builtin_object_size(p, 0); ++i) {
7068	p[i] = 0;
7069	}
7070	return i;
7071	}
7072
7073	int main() {
7074	char chars[100];
7075	int n = bzero1(&chars[0]);
7076	assert(n == sizeof(chars));
7077	return 0;
7078	}
7079	```
7080
7081	If successfully evaluating `__builtin_object_size(param, Type)` at the
7082	callsite is not possible, then the "failed" value is passed in. So, using the
7083	definition of `bzero1` from above, the following code would exit cleanly:
7084
7085	```c
7086	int main2(int argc, char *argv[]) {
7087	int n = bzero1(argv);
7088	assert(n == -1);
7089	return 0;
7090	}
7091	```
7092
7093	`pass_object_size` plays a part in overload resolution. If two overload
7094	candidates are otherwise equally good, then the overload with one or more
7095	parameters with `pass_object_size` is preferred. This implies that the choice
7096	between two identical overloads both with `pass_object_size` on one or more
7097	parameters will always be ambiguous; for this reason, having two such overloads
7098	is illegal. For example:
7099
7100	```c++
7101	#define PS(N) __attribute__((pass_object_size(N)))
7102	// OK
7103	void Foo(char a, char b); // Overload A
7104	// OK -- overload A has no parameters with pass_object_size.
7105	void Foo(char a PS(0), char b PS(0)); // Overload B
7106	// Error -- Same signature (sans pass_object_size) as overload B, and both
7107	// overloads have one or more parameters with the pass_object_size attribute.
7108	void Foo(void a PS(0), void b);
7109
7110	// OK
7111	void Bar(void *a PS(0)); // Overload C
7112	// OK
7113	void Bar(char *c PS(1)); // Overload D
7114
7115	void main() {
7116	char known[10], *unknown;
7117	Foo(unknown, unknown); // Calls overload B
7118	Foo(known, unknown); // Calls overload B
7119	Foo(unknown, known); // Calls overload B
7120	Foo(known, known); // Calls overload B
7121
7122	Bar(known); // Calls overload D
7123	Bar(unknown); // Calls overload D
7124	}
7125	```
7126
7127	Currently, `pass_object_size` is a bit restricted in terms of its usage:
7128
7129	- Only one use of `pass_object_size` is allowed per parameter.
7130	- It is an error to take the address of a function with `pass_object_size` on
7131	any of its parameters. If you wish to do this, you can create an overload
7132	without `pass_object_size` on any parameters.
7133	- It is an error to apply the `pass_object_size` attribute to parameters that
7134	are not pointers. Additionally, any parameter that `pass_object_size` is
7135	applied to must be marked `const` at its function's definition.
7136
7137	Clang also supports the `pass_dynamic_object_size` attribute, which behaves
7138	identically to `pass_object_size`, but evaluates a call to
7139	`__builtin_dynamic_object_size` at the callee instead of
7140	`__builtin_object_size`. `__builtin_dynamic_object_size` provides some extra
7141	runtime checks when the object size can't be determined at compile-time. You can
7142	read more about `__builtin_dynamic_object_size` in
7143	{ref}`Evaluating Object Size <langext-evaluating-object-size>`.)reST";
7144
7145	static const char AttrDoc_PatchableFunctionEntry[] = R"reST(`__attribute__((patchable_function_entry(N,M,Section)))` is used to generate M
7146	NOPs before the function entry and N-M NOPs after the function entry, with a record of
7147	the entry stored in section `Section`. This attribute takes precedence over the
7148	command line option `-fpatchable-function-entry=N,M,Section`. `M` defaults to 0
7149	if omitted. `Section` defaults to the `-fpatchable-function-entry` section name if
7150	set, or to `__patchable_function_entries` otherwise.
7151
7152	This attribute is only supported on
7153	aarch64/aarch64-be/loongarch32/loongarch64/riscv32/riscv64/i386/x86-64/ppc/ppc64/ppc64le/s390x targets.
7154	For ppc/ppc64 targets, AIX is still not supported.)reST";
7155
7156	static const char AttrDoc_Pcs[] = R"reST(On ARM targets, this attribute can be used to select calling conventions
7157	similar to `stdcall` on x86. Valid parameter values are "aapcs" and
7158	"aapcs-vfp".)reST";
7159
7160	static const char AttrDoc_Personality[] = R"reST(`__attribute__((personality(<routine>)))` is used to specify a personality
7161	routine that is different from the language that is being used to implement the
7162	function. This is a targeted, low-level feature aimed at language runtime
7163	implementors who write runtime support code in C/C++ but need that code to
7164	participate in a foreign language's exception-handling or unwinding model.
7165
7166	A personality routine is a language-specific callback attached to each stack
7167	frame that the unwinder invokes to determine whether that frame handles a given
7168	exception and what cleanup actions to perform. It effectively colors the
7169	language-agnostic unwinding mechanism with language-specific semantics, enabling
7170	different languages to coexist on the same call stack while each interpreting
7171	exceptions according to their own rules.)reST";
7172
7173	static const char AttrDoc_Pointer[] = R"reST(:::{Note}
7174	This attribute is experimental and its effect on analysis is subject to change in
7175	a future version of clang.
7176	:::
7177
7178	The attribute `[[gsl::Pointer(T)]]` applies to structs and classes that behave
7179	like pointers to an object of type `T`:
7180
7181	```
7182	class [[gsl::Pointer(int)]] IntPointer {
7183	private:
7184	int *valuePointer;
7185	public:
7186	IntPointer(const IntOwner&);
7187	int *getInt() { return valuePointer; }
7188	};
7189	```
7190
7191	The argument `T` is optional and is ignored.
7192	This attribute may be used by analysis tools and has no effect on code
7193	generation. A `void` argument means that the pointer can point to any type.
7194
7195	Example:
7196	When constructing an instance of a class annotated like this (a Pointer) from
7197	an instance of a class annotated with `[[gsl::Owner]]` (an Owner),
7198	then the analysis will consider the Pointer to point inside the Owner.
7199	When the Owner's lifetime ends, it will consider the Pointer to be dangling.
7200
7201	```c++
7202	int f() {
7203	IntPointer P(IntOwner{}); // P "points into" a temporary IntOwner object
7204	P.getInt(); // P is dangling
7205	}
7206	```
7207
7208	Transparent Member Functions
7209
7210	The analysis automatically tracks certain member functions of `[[gsl::Pointer]]` types
7211	that provide transparent access to the pointed-to object. These include:
7212
7213	- Dereference operators: `operator*`, `operator->`
7214	- Data access methods: `data()`, `c_str()`, `get()`
7215	- Iterator operations: `begin()`, `end()`, `rbegin()`, `rend()`, `cbegin()`, `cend()`, `crbegin()`, `crend()`, `operator+`, `operator-`, `operator++`, `operator--`
7216
7217	When these methods return pointers, view types, or references, the analysis treats them as
7218	transparently borrowing from the same object that the pointer itself borrows from,
7219	enabling detection of use-after-free through these access patterns:
7220
7221	```c++
7222	// For example, .data() here returns a borrow to 's' instead of 'v'.
7223	const char* f() {
7224	std::string s = "hello";
7225	std::string_view v = s; // warning: address of stack memory returned
7226	return v.data(); // note: returned here
7227	}
7228
7229	const MyObj& g(MyObj obj) {
7230	View v = obj; // warning: address of stack memory returned
7231	return *v; // note: returned here
7232	}
7233	```
7234
7235	This tracking also applies to range-based for loops, where the `begin()` and `end()`
7236	iterators are used to access elements:
7237
7238	```c++
7239	std::string_view f(std::vector<std::string> vec) {
7240	for (const std::string& s : vec) { // warning: address of stack memory returned
7241	return s; // note: returned here
7242	}
7243	}
7244	```
7245
7246	Container Template Specialization
7247
7248	If a template class is annotated with `[[gsl::Owner]]`, and the first
7249	instantiated template argument is a pointer type (raw pointer, or `[[gsl::Pointer]]`),
7250	the analysis will consider the instantiated class as a container of the pointer.
7251	When constructing such an object from a GSL owner object, the analysis will
7252	assume that the container holds a pointer to the owner object. Consequently,
7253	when the owner object is destroyed, the pointer will be considered dangling.
7254
7255	```c++
7256	int f() {
7257	std::vector<std::string_view> v = {std::string()}; // v holds a dangling pointer.
7258	std::optional<std::string_view> o = std::string(); // o holds a dangling pointer.
7259	}
7260	```)reST";
7261
7262	static const char AttrDoc_PointerAuth[] = R"reST(The `__ptrauth` qualifier allows the programmer to directly control
7263	how pointers are signed when they are stored in a particular variable.
7264	This can be used to strengthen the default protections of pointer
7265	authentication and make it more difficult for an attacker to escalate
7266	an ability to alter memory into full control of a process.
7267
7268	```c
7269	#include <ptrauth.h>
7270
7271	typedef void (my_callback)(const void);
7272	my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback;
7273	```
7274
7275	The first argument to `__ptrauth` is the name of the signing key.
7276	Valid key names for the target are defined in `<ptrauth.h>`.
7277
7278	The second argument to `__ptrauth` is a flag (0 or 1) specifying whether
7279	the object should use address discrimination.
7280
7281	The third argument to `__ptrauth` is a 16-bit non-negative integer which
7282	allows additional discrimination between objects.)reST";
7283
7284	static const char AttrDoc_PointerFieldProtection[] = R"reST(No documentation.)reST";
7285
7286	static const char AttrDoc_PragmaClangBSSSection[] = R"reST()reST";
7287
7288	static const char AttrDoc_PragmaClangDataSection[] = R"reST()reST";
7289
7290	static const char AttrDoc_PragmaClangRelroSection[] = R"reST()reST";
7291
7292	static const char AttrDoc_PragmaClangRodataSection[] = R"reST()reST";
7293
7294	static const char AttrDoc_PragmaClangTextSection[] = R"reST()reST";
7295
7296	static const char AttrDoc_PreferredName[] = R"reST(The `preferred_name` attribute can be applied to a class template, and
7297	specifies a preferred way of naming a specialization of the template. The
7298	preferred name will be used whenever the corresponding template specialization
7299	would otherwise be printed in a diagnostic or similar context.
7300
7301	The preferred name must be a typedef or type alias declaration that refers to a
7302	specialization of the class template (not including any type qualifiers). In
7303	general this requires the template to be declared at least twice. For example:
7304
7305	```c++
7306	template<typename T> struct basic_string;
7307	using string = basic_string<char>;
7308	using wstring = basic_string<wchar_t>;
7309	template<typename T> struct [[clang::preferred_name(string),
7310	clang::preferred_name(wstring)]] basic_string {
7311	// ...
7312	};
7313	```
7314
7315	Note that the `preferred_name` attribute will be ignored when the compiler
7316	writes a C++20 Module interface now. This is due to a compiler issue
7317	(<https://github.com/llvm/llvm-project/issues/56490>) that blocks users to modularize
7318	declarations with `preferred_name`. This is intended to be fixed in the future.)reST";
7319
7320	static const char AttrDoc_PreferredType[] = R"reST(This attribute allows adjusting the type of a bit-field in debug information.
7321	This can be helpful when a bit-field is intended to store an enumeration value,
7322	but has to be specified as having the enumeration's underlying type in order to
7323	facilitate compiler optimizations or bit-field packing behavior. Normally, the
7324	underlying type is what is emitted in debug information, which can make it hard
7325	for debuggers to know to map a bit-field's value back to a particular enumeration.
7326
7327	```c++
7328	enum Colors { Red, Green, Blue };
7329
7330	struct S {
7331	[[clang::preferred_type(Colors)]] unsigned ColorVal : 2;
7332	[[clang::preferred_type(bool)]] unsigned UseAlternateColorSpace : 1;
7333	} s = { Green, false };
7334	```
7335
7336	Without the attribute, a debugger is likely to display the value `1` for `ColorVal`
7337	and `0` for `UseAlternateColorSpace`. With the attribute, the debugger may now
7338	display `Green` and `false` instead.
7339
7340	This can be used to map a bit-field to an arbitrary type that isn't integral
7341	or an enumeration type. For example:
7342
7343	```c++
7344	struct A {
7345	short a1;
7346	short a2;
7347	};
7348
7349	struct B {
7350	[[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
7351	};
7352	```
7353
7354	will associate the type `A` with the `b1` bit-field and is intended to display
7355	something like this in the debugger:
7356
7357	```text
7358	Process 2755547 stopped
7359	* thread #1, name = 'test-preferred-', stop reason = step in
7360	frame #0: 0x0000555555555148 test-preferred-type`main at test.cxx:13:14
7361	10 int main()
7362	11 {
7363	12 B b;
7364	-> 13 return b.b1;
7365	14 }
7366	(lldb) v -T
7367	(B) b = {
7368	(A:32) b1 = {
7369	(short) a1 = 12
7370	(short) a2 = 15
7371	}
7372	}
7373	```
7374
7375	Note that debuggers may not be able to handle more complex mappings, and so
7376	this usage is debugger-dependent.)reST";
7377
7378	static const char AttrDoc_PreserveAll[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
7379	a function. The `preserve_all` calling convention attempts to make the code
7380	in the caller even less intrusive than the `preserve_most` calling convention.
7381	This calling convention also behaves identical to the `C` calling convention
7382	on how arguments and return values are passed, but it uses a different set of
7383	caller/callee-saved registers. This removes the burden of saving and
7384	recovering a large register set before and after the call in the caller. If
7385	the arguments are passed in callee-saved registers, then they will be
7386	preserved by the callee across the call. This doesn't apply for values
7387	returned in callee-saved registers.
7388
7389	- On X86-64 the callee preserves all general purpose registers, except for
7390	R11. R11 can be used as a scratch register. Furthermore it also preserves
7391	all floating-point registers (XMMs/YMMs).
7392	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
7393	X16-X18. Furthermore it also preserves lower 128 bits of V8-V31 SIMD - floating
7394	point registers.
7395
7396	The idea behind this convention is to support calls to runtime functions
7397	that don't need to call out to any other functions.
7398
7399	This calling convention, like the `preserve_most` calling convention, will be
7400	used by a future version of the Objective-C runtime and should be considered
7401	experimental at this time.)reST";
7402
7403	static const char AttrDoc_PreserveMost[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
7404	a function. The `preserve_most` calling convention attempts to make the code
7405	in the caller as unintrusive as possible. This convention behaves identically
7406	to the `C` calling convention on how arguments and return values are passed,
7407	but it uses a different set of caller/callee-saved registers. This alleviates
7408	the burden of saving and recovering a large register set before and after the
7409	call in the caller. If the arguments are passed in callee-saved registers,
7410	then they will be preserved by the callee across the call. This doesn't
7411	apply for values returned in callee-saved registers.
7412
7413	- On X86-64 the callee preserves all general purpose registers, except for
7414	R11. R11 can be used as a scratch register. Floating-point registers
7415	(XMMs/YMMs) are not preserved and need to be saved by the caller.
7416	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
7417	X16-X18.
7418
7419	The idea behind this convention is to support calls to runtime functions
7420	that have a hot path and a cold path. The hot path is usually a small piece
7421	of code that doesn't use many registers. The cold path might need to call out to
7422	another function and therefore only needs to preserve the caller-saved
7423	registers, which haven't already been saved by the caller. The
7424	`preserve_most` calling convention is very similar to the `cold` calling
7425	convention in terms of caller/callee-saved registers, but they are used for
7426	different types of function calls. `coldcc` is for function calls that are
7427	rarely executed, whereas `preserve_most` function calls are intended to be
7428	on the hot path and definitely executed a lot. Furthermore `preserve_most`
7429	doesn't prevent the inliner from inlining the function call.
7430
7431	This calling convention will be used by a future version of the Objective-C
7432	runtime and should therefore still be considered experimental at this time.
7433	Although this convention was created to optimize certain runtime calls to
7434	the Objective-C runtime, it is not limited to this runtime and might be used
7435	by other runtimes in the future too. The current implementation only
7436	supports X86-64 and AArch64, but the intention is to support more architectures
7437	in the future.)reST";
7438
7439	static const char AttrDoc_PreserveNone[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of a function.
7440	The `preserve_none` calling convention tries to preserve as few general
7441	registers as possible. So all general registers are caller saved registers. It
7442	also uses more general registers to pass arguments. This attribute doesn't
7443	impact floating-point registers. `preserve_none`'s ABI is still unstable, and
7444	may be changed in the future.
7445
7446	- On X86-64, only RSP and RBP are preserved by the callee.
7447	Registers R12, R13, R14, R15, RDI, RSI, RDX, RCX, R8, R9, R11, and RAX now can
7448	be used to pass function arguments. Floating-point registers (XMMs/YMMs) still
7449	follow the C calling convention.
7450	- On AArch64, only LR and FP are preserved by the callee.
7451	Registers X20-X28, X0-X7, and X9-X14 are used to pass function arguments.
7452	X8, X16-X19, SIMD and floating-point registers follow the AAPCS calling
7453	convention. X15 is not available for argument passing on Windows, but is
7454	used to pass arguments on other platforms.)reST";
7455
7456	static const char AttrDoc_PtGuardedBy[] = R"reST(No documentation.)reST";
7457
7458	static const char AttrDoc_PtGuardedVar[] = R"reST(No documentation.)reST";
7459
7460	static const char AttrDoc_Ptr32[] = R"reST(The `__ptr32` qualifier represents a native pointer on a 32-bit system. On a
7461	64-bit system, a pointer with `__ptr32` is extended to a 64-bit pointer. The
7462	`__sptr` and `__uptr` qualifiers can be used to specify whether the pointer
7463	is sign extended or zero extended. This qualifier is enabled under
7464	`-fms-extensions`.)reST";
7465
7466	static const char AttrDoc_Ptr64[] = R"reST(The `__ptr64` qualifier represents a native pointer on a 64-bit system. On a
7467	32-bit system, a `__ptr64` pointer is truncated to a 32-bit pointer. This
7468	qualifier is enabled under `-fms-extensions`.)reST";
7469
7470	static const char AttrDoc_Pure[] = R"reST(No documentation.)reST";
7471
7472	static const char AttrDoc_RISCVInterrupt[] = R"reST(Clang supports the GNU style `__attribute__((interrupt))` attribute on RISCV
7473	targets. This attribute may be attached to a function definition and instructs
7474	the backend to generate appropriate function entry/exit code so that it can be
7475	used directly as an interrupt service routine.
7476
7477	Permissible values for this parameter are `machine`, `supervisor`,
7478	`rnmi`, `qci-nest`, `qci-nonest`, `SiFive-CLIC-preemptible`, and
7479	`SiFive-CLIC-stack-swap`. If there is no parameter, then it defaults to
7480	`machine`.
7481
7482	The `rnmi` value is used for resumable non-maskable interrupts. It requires the
7483	standard Smrnmi extension.
7484
7485	The `qci-nest` and `qci-nonest` values require Qualcomm's Xqciint extension
7486	and are used for Machine-mode Interrupts and Machine-mode Non-maskable
7487	interrupts. These use the following instructions from Xqciint to save and
7488	restore interrupt state to the stack -- the `qci-nest` value will use
7489	`qc.c.mienter.nest` and the `qci-nonest` value will use `qc.c.mienter` to
7490	begin the interrupt handler. Both of these will use `qc.c.mileaveret` to
7491	restore the state and return to the previous context.
7492
7493	The `SiFive-CLIC-preemptible` and `SiFive-CLIC-stack-swap` values are used
7494	for machine-mode interrupts. For `SiFive-CLIC-preemptible` interrupts, the
7495	values of `mcause` and `mepc` are saved onto the stack, and interrupts are
7496	re-enabled. For `SiFive-CLIC-stack-swap` interrupts, the stack pointer is
7497	swapped with `mscratch` before its first use and after its last use.
7498
7499	The SiFive CLIC values may be combined with each other and with the `machine`
7500	attribute value. Any other combination of different values is not allowed.
7501
7502	Repeated interrupt attribute on the same declaration will cause a warning
7503	to be emitted. In case of repeated declarations, the last one prevails.
7504
7505	Refer to:
7506	<https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html>
7507	<https://riscv.org/specifications/privileged-isa/>
7508	The RISC-V Instruction Set Manual Volume II: Privileged Architecture
7509	Version 1.10.
7510	<https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.13.0>
7511	<https://sifive.cdn.prismic.io/sifive/d1984d2b-c9b9-4c91-8de0-d68a5e64fa0f_sifive-interrupt-cookbook-v1p2.pdf>)reST";
7512
7513	static const char AttrDoc_RISCVVLSCC[] = R"reST(The `riscv_vls_cc` attribute can be applied to a function. Functions
7514	declared with this attribute will utilize the standard fixed-length vector
7515	calling convention variant instead of the default calling convention defined by
7516	the ABI. This variant aims to pass fixed-length vectors via vector registers,
7517	if possible, rather than through general-purpose registers.)reST";
7518
7519	static const char AttrDoc_RISCVVectorCC[] = R"reST(The `riscv_vector_cc` attribute can be applied to a function. It preserves 15
7520	registers namely, v1-v7 and v24-v31 as callee-saved. Callers thus don't need
7521	to save these registers before function calls, and callees only need to save
7522	them if they use them.)reST";
7523
7524	static const char AttrDoc_RandomizeLayout[] = R"reST(The attribute `randomize_layout`, when attached to a C structure, selects it
7525	for structure layout field randomization; a compile-time hardening technique. A
7526	"seed" value, is specified via the `-frandomize-layout-seed=` command line flag.
7527	For example:
7528
7529	```bash
7530	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
7531	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
7532	```
7533
7534	You can also supply the seed in a file with `-frandomize-layout-seed-file=`.
7535	For example:
7536
7537	```bash
7538	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
7539	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
7540	```
7541
7542	The randomization is deterministic based for a given seed, so the entire
7543	program should be compiled with the same seed, but keep the seed safe
7544	otherwise.
7545
7546	The attribute `no_randomize_layout`, when attached to a C structure,
7547	instructs the compiler that this structure should not have its field layout
7548	randomized.)reST";
7549
7550	static const char AttrDoc_ReadOnlyPlacement[] = R"reST(This attribute is attached to a structure, class or union declaration.
7551
7552	: When attached to a record declaration/definition, it checks if all instances
7553	of this type can be placed in the read-only data segment of the program. If it
7554	finds an instance that can not be placed in a read-only segment, the compiler
7555	emits a warning at the source location where the type was used.
7556
7557	Examples:
7558	\* `struct __attribute__((enforce_read_only_placement)) Foo;`
7559	\* `struct __attribute__((enforce_read_only_placement)) Bar { ... };`
7560
7561	Both `Foo` and `Bar` types have the `enforce_read_only_placement` attribute.
7562
7563	The goal of introducing this attribute is to assist developers with writing secure
7564	code. A `const`-qualified global is generally placed in the read-only section
7565	of the memory that has additional run time protection from malicious writes. By
7566	attaching this attribute to a declaration, the developer can express the intent
7567	to place all instances of the annotated type in the read-only program memory.
7568
7569	Note 1: The attribute doesn't guarantee that the object will be placed in the
7570	read-only data segment as it does not instruct the compiler to ensure such
7571	a placement. It emits a warning if something in the code can be proven to prevent
7572	an instance from being placed in the read-only data segment.
7573
7574	Note 2: Currently, clang only checks if all global declarations of a given type 'T'
7575	are `const`-qualified. The following conditions would also prevent the data to be
7576	put into read only segment, but the corresponding warnings are not yet implemented.
7577
7578	1. An instance of type `T` is allocated on the heap/stack.
7579	2. Type `T` defines/inherits a mutable field.
7580	3. Type `T` defines/inherits non-constexpr constructor(s) for initialization.
7581	4. A field of type `T` is defined by type `Q`, which does not bear the
7582	`enforce_read_only_placement` attribute.
7583	5. A type `Q` inherits from type `T` and it does not have the
7584	`enforce_read_only_placement` attribute.)reST";
7585
7586	static const char AttrDoc_ReentrantCapability[] = R"reST(No documentation.)reST";
7587
7588	static const char AttrDoc_RegCall[] = R"reST(On x86 targets, this attribute changes the calling convention to
7589	[\_\_regcall][__regcall] convention. This convention aims to pass as many arguments
7590	as possible in registers. It also tries to utilize registers for the
7591	return value whenever it is possible.
7592
7593	[__regcall]: https://www.intel.com/content/www/us/en/docs/dpcpp-cpp-compiler/developer-guide-reference/2023-2/c-c-sycl-calling-conventions.html)reST";
7594
7595	static const char AttrDoc_Reinitializes[] = R"reST(The `reinitializes` attribute can be applied to a non-static, non-const C++
7596	member function to indicate that this member function reinitializes the entire
7597	object to a known state, independent of the previous state of the object.
7598
7599	This attribute can be interpreted by static analyzers that warn about uses of an
7600	object that has been left in an indeterminate state by a move operation. If a
7601	member function marked with the `reinitializes` attribute is called on a
7602	moved-from object, the analyzer can conclude that the object is no longer in an
7603	indeterminate state.
7604
7605	A typical example where this attribute would be used is on functions that clear
7606	a container class:
7607
7608	```c++
7609	template <class T>
7610	class Container {
7611	public:
7612	...
7613	[[clang::reinitializes]] void Clear();
7614	...
7615	};
7616	```)reST";
7617
7618	static const char AttrDoc_ReleaseCapability[] = R"reST(Marks a function as releasing a capability.)reST";
7619
7620	static const char AttrDoc_ReleaseHandle[] = R"reST(If a function parameter is annotated with `release_handle(tag)` it is assumed to
7621	close the handle. It is also assumed to require an open handle to work with. The
7622	attribute requires a string literal argument to identify the handle being released.
7623
7624	```c++
7625	zx_status_t zx_handle_close(zx_handle_t handle [[clang::release_handle("tag")]]);
7626	```)reST";
7627
7628	static const char AttrDoc_ReqdWorkGroupSize[] = R"reST(No documentation.)reST";
7629
7630	static const char AttrDoc_RequiresCapability[] = R"reST(No documentation.)reST";
7631
7632	static const char AttrDoc_Restrict[] = R"reST(The `malloc` attribute has two forms with different functionality. The first
7633	is when it is used without arguments, where it marks that a function acts like
7634	a system memory allocation function, returning a pointer to allocated storage
7635	that does not alias storage from any other object accessible to the caller.
7636
7637	The second form is when `malloc` takes one or two arguments. The first
7638	argument names a function that should be associated with this function as its
7639	deallocation function. When this form is used, it enables the compiler to
7640	diagnose when the incorrect deallocation function is used with this variable.
7641	However the associated warning, spelled `-Wmismatched-dealloc` in GCC, is not
7642	yet implemented in clang.)reST";
7643
7644	static const char AttrDoc_Retain[] = R"reST(This attribute, when attached to a function or variable definition, prevents
7645	section garbage collection in the linker. It does not prevent other discard
7646	mechanisms, such as archive member selection, and COMDAT group resolution.
7647
7648	If the compiler does not emit the definition, e.g. because it was not used in
7649	the translation unit or the compiler was able to eliminate all of the uses,
7650	this attribute has no effect. This attribute is typically combined with the
7651	`used` attribute to force the definition to be emitted and preserved into the
7652	final linked image.
7653
7654	This attribute is only necessary on ELF targets; other targets prevent section
7655	garbage collection by the linker when using the `used` attribute alone.
7656	Using the attributes together should result in consistent behavior across
7657	targets.
7658
7659	This attribute requires the linker to support the `SHF_GNU_RETAIN` extension.
7660	This support is available in GNU `ld` and `gold` as of binutils 2.36, as
7661	well as in `ld.lld` 13.)reST";
7662
7663	static const char AttrDoc_ReturnTypestate[] = R"reST(The `return_typestate` attribute can be applied to functions or parameters.
7664	When applied to a function the attribute specifies the state of the returned
7665	value. The function's body is checked to ensure that it always returns a value
7666	in the specified state. On the caller side, values returned by the annotated
7667	function are initialized to the given state.
7668
7669	When applied to a function parameter it modifies the state of an argument after
7670	a call to the function returns. The function's body is checked to ensure that
7671	the parameter is in the expected state before returning.)reST";
7672
7673	static const char AttrDoc_ReturnsNonNull[] = R"reST(The `returns_nonnull` attribute indicates that a particular function (or
7674	Objective-C method) always returns a non-null pointer. For example, a
7675	particular system `malloc` might be defined to terminate a process when
7676	memory is not available rather than returning a null pointer:
7677
7678	```c
7679	extern void * malloc (size_t size) __attribute__((returns_nonnull));
7680	```
7681
7682	The `returns_nonnull` attribute implies that returning a null pointer is
7683	undefined behavior, which the optimizer may take advantage of. The `_Nonnull`
7684	type qualifier indicates that a pointer cannot be null in a more general manner
7685	(because it is part of the type system) and does not imply undefined behavior,
7686	making it more widely applicable)reST";
7687
7688	static const char AttrDoc_ReturnsTwice[] = R"reST(No documentation.)reST";
7689
7690	static const char AttrDoc_RootSignature[] = R"reST(The `RootSignature` attribute applies to HLSL entry functions to define what
7691	types of resources are bound to the graphics pipeline.
7692
7693	For details about the use and specification of Root Signatures please see here:
7694	<https://learn.microsoft.com/en-us/windows/win32/direct3d12/root-signatures>)reST";
7695
7696	static const char AttrDoc_SPtr[] = R"reST(The `__sptr` qualifier specifies that a 32-bit pointer should be sign
7697	extended when converted to a 64-bit pointer.)reST";
7698
7699	static const char AttrDoc_SYCLConstantAddressSpace[] = R"reST(.. note::
7700
7701	These attributes are intended for use in the implementation of SYCL run-time
7702	libraries and should not be used in any other context.
7703	Programmers writing code intended to conform to the SYCL specification should
7704	use the address space facilities specified in the following sections of the
7705	SYCL 2020 specification.
7706
7707	* `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
7708	* `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
7709	* `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7710	* `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
7711	* `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
7712
7713	The SYCL address space attributes listed below correspond to the five address
7714	spaces described by
7715	`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
7716	`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7717
7718	.. list-table::
7719	:header-rows: 1
7720
7721	* - Address space attribute
7722	- SYCL address space
7723	- Description
7724	* - ``[[clang::sycl_global]]``
7725	- global
7726	- A memory region accessible by all work-items executing on a device.
7727	* - ``[[clang::sycl_local]]``
7728	- local
7729	- A memory region accessible by all work-items of a single work-group.
7730	* - ``[[clang::sycl_private]]``
7731	- private
7732	- A memory region that is private to a single work-item.
7733	* - ``[[clang::sycl_generic]]``
7734	- generic
7735	- A virtual memory region from which the global, local, and private memory
7736	regions may all be accessed.
7737	* - ``[[clang::sycl_constant]]``
7738	- constant
7739	- (deprecated) A memory region that holds constant data for an executing
7740	kernel.
7741
7742	The SYCL address space attributes are type attributes that may be applied to
7743	non-function non-reference types to specify an address space qualified type.
7744
7745	A type with a SYCL address space qualifier is a distinct type from the
7746	otherwise unattributed type. For example, ``int `` and ``int [[clang::sycl_global]]``
7747	designate distinct pointer types which participate in overload resolution and
7748	template specialization.
7749
7750	The top-level type of a variable declaration cannot have a SYCL address space
7751	qualifier. For example:
7752
7753	.. code-block:: c++
7754
7755	int [[clang::sycl_global]] gv; // error: the top-level type has an address space qualifier.
7756	int [[clang::sycl_global]] *pgi; // ok; the address space qualifier is on the pointee type.
7757
7758	Conversions between SYCL address space attributed types are permitted as
7759	follows.
7760
7761	* Types attributed with the global, local, or private address space attributes
7762	are implicitly convertible to matching types with the generic address space
7763	attribute.
7764
7765	The mapping of SYCL address spaces to physical address spaces is target
7766	dependent.
7767
7768	For OpenCL device targets, the SYCL address space attributes are aligned with
7769	the `OpenCL address space attributes <attr-opencl-addrspace_>`_ such that, e.g.,
7770	``int [[clang::sycl_global]]`` and ``int [[clang::opencl_global]]`` specify
7771	distinct types both of which map to the same underlying address space.
7772	Corresponding SYCL and OpenCL address space attributed types are implicitly
7773	convertible; other conversions are permitted as described above; e.g.,
7774	``int [[clang::sycl_global]]*`` is implicitly convertible to
7775	``int [[clang::opencl_generic]]*``.
7776
7777	.. _attr-opencl-addrspace:
7778	https://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces
7779	.. _SYCL-2020-3.8.2:
7780	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model
7781	.. _SYCL-2020-4.7.2:
7782	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:buffers
7783	.. _SYCL-2020-4.7.6:
7784	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:accessors
7785	.. _SYCL-2020-4.7.7:
7786	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes
7787	.. _SYCL-2020-F.7:
7788	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-static-addrspace-cast
7789	.. _SYCL-2020-F.8:
7790	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-dynamic-addrspace-cast)reST";
7791
7792	static const char AttrDoc_SYCLExternal[] = R"reST(The `sycl_external` attribute indicates that a function defined in another
7793	translation unit may be called by a device function defined in the current
7794	translation unit or, if defined in the current translation unit, the function
7795	may be called by device functions defined in other translation units.
7796	The attribute is intended for use in the implementation of the `SYCL_EXTERNAL`
7797	macro as specified in section 5.10.1, "SYCL functions and member functions
7798	linkage", of the SYCL 2020 specification.
7799
7800	The attribute only appertains to functions and only those that meet the
7801	following requirements:
7802
7803	- Has external linkage
7804	- Is not explicitly defined as deleted (the function may be an explicitly
7805	defaulted function that is defined as deleted)
7806
7807	The attribute shall be present on the first declaration of a function and
7808	may optionally be present on subsequent declarations.
7809
7810	When compiling for a SYCL device target that does not support the generic
7811	address space, the function shall not specify a raw pointer or reference type
7812	as the return type or as a parameter type.
7813	See section 5.10, "SYCL offline linking", of the SYCL 2020 specification.
7814	The following examples demonstrate the use of this attribute:
7815
7816	```c++
7817	[[clang::sycl_external]] void Foo(); // Ok.
7818
7819	[[clang::sycl_external]] void Bar() { /* ... */ } // Ok.
7820
7821	[[clang::sycl_external]] extern void Baz(); // Ok.
7822
7823	[[clang::sycl_external]] static void Quux() { /* ... */ } // error: Quux() has internal linkage.
7824	```)reST";
7825
7826	static const char AttrDoc_SYCLGenericAddressSpace[] = R"reST(.. note::
7827
7828	These attributes are intended for use in the implementation of SYCL run-time
7829	libraries and should not be used in any other context.
7830	Programmers writing code intended to conform to the SYCL specification should
7831	use the address space facilities specified in the following sections of the
7832	SYCL 2020 specification.
7833
7834	* `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
7835	* `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
7836	* `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7837	* `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
7838	* `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
7839
7840	The SYCL address space attributes listed below correspond to the five address
7841	spaces described by
7842	`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
7843	`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7844
7845	.. list-table::
7846	:header-rows: 1
7847
7848	* - Address space attribute
7849	- SYCL address space
7850	- Description
7851	* - ``[[clang::sycl_global]]``
7852	- global
7853	- A memory region accessible by all work-items executing on a device.
7854	* - ``[[clang::sycl_local]]``
7855	- local
7856	- A memory region accessible by all work-items of a single work-group.
7857	* - ``[[clang::sycl_private]]``
7858	- private
7859	- A memory region that is private to a single work-item.
7860	* - ``[[clang::sycl_generic]]``
7861	- generic
7862	- A virtual memory region from which the global, local, and private memory
7863	regions may all be accessed.
7864	* - ``[[clang::sycl_constant]]``
7865	- constant
7866	- (deprecated) A memory region that holds constant data for an executing
7867	kernel.
7868
7869	The SYCL address space attributes are type attributes that may be applied to
7870	non-function non-reference types to specify an address space qualified type.
7871
7872	A type with a SYCL address space qualifier is a distinct type from the
7873	otherwise unattributed type. For example, ``int `` and ``int [[clang::sycl_global]]``
7874	designate distinct pointer types which participate in overload resolution and
7875	template specialization.
7876
7877	The top-level type of a variable declaration cannot have a SYCL address space
7878	qualifier. For example:
7879
7880	.. code-block:: c++
7881
7882	int [[clang::sycl_global]] gv; // error: the top-level type has an address space qualifier.
7883	int [[clang::sycl_global]] *pgi; // ok; the address space qualifier is on the pointee type.
7884
7885	Conversions between SYCL address space attributed types are permitted as
7886	follows.
7887
7888	* Types attributed with the global, local, or private address space attributes
7889	are implicitly convertible to matching types with the generic address space
7890	attribute.
7891
7892	The mapping of SYCL address spaces to physical address spaces is target
7893	dependent.
7894
7895	For OpenCL device targets, the SYCL address space attributes are aligned with
7896	the `OpenCL address space attributes <attr-opencl-addrspace_>`_ such that, e.g.,
7897	``int [[clang::sycl_global]]`` and ``int [[clang::opencl_global]]`` specify
7898	distinct types both of which map to the same underlying address space.
7899	Corresponding SYCL and OpenCL address space attributed types are implicitly
7900	convertible; other conversions are permitted as described above; e.g.,
7901	``int [[clang::sycl_global]]*`` is implicitly convertible to
7902	``int [[clang::opencl_generic]]*``.
7903
7904	.. _attr-opencl-addrspace:
7905	https://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces
7906	.. _SYCL-2020-3.8.2:
7907	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model
7908	.. _SYCL-2020-4.7.2:
7909	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:buffers
7910	.. _SYCL-2020-4.7.6:
7911	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:accessors
7912	.. _SYCL-2020-4.7.7:
7913	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes
7914	.. _SYCL-2020-F.7:
7915	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-static-addrspace-cast
7916	.. _SYCL-2020-F.8:
7917	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-dynamic-addrspace-cast)reST";
7918
7919	static const char AttrDoc_SYCLGlobalAddressSpace[] = R"reST(.. note::
7920
7921	These attributes are intended for use in the implementation of SYCL run-time
7922	libraries and should not be used in any other context.
7923	Programmers writing code intended to conform to the SYCL specification should
7924	use the address space facilities specified in the following sections of the
7925	SYCL 2020 specification.
7926
7927	* `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
7928	* `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
7929	* `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7930	* `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
7931	* `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
7932
7933	The SYCL address space attributes listed below correspond to the five address
7934	spaces described by
7935	`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
7936	`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
7937
7938	.. list-table::
7939	:header-rows: 1
7940
7941	* - Address space attribute
7942	- SYCL address space
7943	- Description
7944	* - ``[[clang::sycl_global]]``
7945	- global
7946	- A memory region accessible by all work-items executing on a device.
7947	* - ``[[clang::sycl_local]]``
7948	- local
7949	- A memory region accessible by all work-items of a single work-group.
7950	* - ``[[clang::sycl_private]]``
7951	- private
7952	- A memory region that is private to a single work-item.
7953	* - ``[[clang::sycl_generic]]``
7954	- generic
7955	- A virtual memory region from which the global, local, and private memory
7956	regions may all be accessed.
7957	* - ``[[clang::sycl_constant]]``
7958	- constant
7959	- (deprecated) A memory region that holds constant data for an executing
7960	kernel.
7961
7962	The SYCL address space attributes are type attributes that may be applied to
7963	non-function non-reference types to specify an address space qualified type.
7964
7965	A type with a SYCL address space qualifier is a distinct type from the
7966	otherwise unattributed type. For example, ``int `` and ``int [[clang::sycl_global]]``
7967	designate distinct pointer types which participate in overload resolution and
7968	template specialization.
7969
7970	The top-level type of a variable declaration cannot have a SYCL address space
7971	qualifier. For example:
7972
7973	.. code-block:: c++
7974
7975	int [[clang::sycl_global]] gv; // error: the top-level type has an address space qualifier.
7976	int [[clang::sycl_global]] *pgi; // ok; the address space qualifier is on the pointee type.
7977
7978	Conversions between SYCL address space attributed types are permitted as
7979	follows.
7980
7981	* Types attributed with the global, local, or private address space attributes
7982	are implicitly convertible to matching types with the generic address space
7983	attribute.
7984
7985	The mapping of SYCL address spaces to physical address spaces is target
7986	dependent.
7987
7988	For OpenCL device targets, the SYCL address space attributes are aligned with
7989	the `OpenCL address space attributes <attr-opencl-addrspace_>`_ such that, e.g.,
7990	``int [[clang::sycl_global]]`` and ``int [[clang::opencl_global]]`` specify
7991	distinct types both of which map to the same underlying address space.
7992	Corresponding SYCL and OpenCL address space attributed types are implicitly
7993	convertible; other conversions are permitted as described above; e.g.,
7994	``int [[clang::sycl_global]]*`` is implicitly convertible to
7995	``int [[clang::opencl_generic]]*``.
7996
7997	.. _attr-opencl-addrspace:
7998	https://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces
7999	.. _SYCL-2020-3.8.2:
8000	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model
8001	.. _SYCL-2020-4.7.2:
8002	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:buffers
8003	.. _SYCL-2020-4.7.6:
8004	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:accessors
8005	.. _SYCL-2020-4.7.7:
8006	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes
8007	.. _SYCL-2020-F.7:
8008	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-static-addrspace-cast
8009	.. _SYCL-2020-F.8:
8010	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-dynamic-addrspace-cast)reST";
8011
8012	static const char AttrDoc_SYCLKernel[] = R"reST(The `sycl_kernel` attribute specifies that a function template will be used
8013	to outline device code and to generate an OpenCL kernel.
8014	Here is a code example of the SYCL program, which demonstrates the compiler's
8015	outlining job:
8016
8017	```c++
8018	int foo(int x) { return ++x; }
8019
8020	using namespace cl::sycl;
8021	queue Q;
8022	buffer<int, 1> a(range<1>{1024});
8023	Q.submit([&](handler& cgh) {
8024	auto A = a.get_access<access::mode::write>(cgh);
8025	cgh.parallel_for<init_a>(range<1>{1024}, [=](id<1> index) {
8026	A[index] = index[0] + foo(42);
8027	});
8028	}
8029	```
8030
8031	A C++ function object passed to the `parallel_for` is called a "SYCL kernel".
8032	A SYCL kernel defines the entry point to the "device part" of the code. The
8033	compiler will emit all symbols accessible from a "kernel". In this code
8034	example, the compiler will emit "foo" function. More details about the
8035	compilation of functions for the device part can be found in the SYCL 1.2.1
8036	specification Section 6.4.
8037	To show to the compiler entry point to the "device part" of the code, the SYCL
8038	runtime can use the `sycl_kernel` attribute in the following way:
8039
8040	```c++
8041	namespace cl {
8042	namespace sycl {
8043	class handler {
8044	template <typename KernelName, typename KernelType/, .../>
8045	__attribute__((sycl_kernel)) void sycl_kernel_function(KernelType KernelFuncObj) {
8046	// ...
8047	KernelFuncObj();
8048	}
8049
8050	template <typename KernelName, typename KernelType, int Dims>
8051	void parallel_for(range<Dims> NumWorkItems, KernelType KernelFunc) {
8052	#ifdef __SYCL_DEVICE_ONLY__
8053	sycl_kernel_function<KernelName, KernelType, Dims>(KernelFunc);
8054	#else
8055	// Host implementation
8056	#endif
8057	}
8058	};
8059	} // namespace sycl
8060	} // namespace cl
8061	```
8062
8063	The compiler will also generate an OpenCL kernel using the function marked with
8064	the `sycl_kernel` attribute.
8065	Here is the list of SYCL device compiler expectations with regard to the
8066	function marked with the `sycl_kernel` attribute:
8067
8068	- The function must be a template with at least two type template parameters.
8069	The compiler generates an OpenCL kernel and uses the first template parameter
8070	as a unique name for the generated OpenCL kernel. The host application uses
8071	this unique name to invoke the OpenCL kernel generated for the SYCL kernel
8072	specialized by this name and second template parameter `KernelType` (which
8073	might be an unnamed function object type).
8074	- The function must have at least one parameter. The first parameter is
8075	required to be a function object type (named or unnamed i.e. lambda). The
8076	compiler uses function object type fields to generate OpenCL kernel
8077	parameters.
8078	- The function must return void. The compiler reuses the body of marked functions to
8079	generate the OpenCL kernel body, and the OpenCL kernel must return `void`.
8080
8081	The SYCL kernel in the previous code sample meets these expectations.)reST";
8082
8083	static const char AttrDoc_SYCLKernelEntryPoint[] = R"reST(The `sycl_kernel_entry_point` attribute facilitates the launch of a SYCL
8084	kernel and the generation of an offload kernel entry point, sometimes called
8085	a SYCL kernel caller function, suitable for invoking a SYCL kernel on an
8086	offload device. The attribute is intended for use in the implementation of
8087	SYCL kernel invocation functions like the `single_task` and `parallel_for`
8088	member functions of the `sycl::handler` class specified in section 4.9.4,
8089	"Command group `handler` class", of the SYCL 2020 specification.
8090
8091	The attribute requires a single type argument that meets the requirements for
8092	a SYCL kernel name as described in section 5.2, "Naming of kernels", of the
8093	SYCL 2020 specification. A unique kernel name type is required for each
8094	function declared with the attribute. The attribute may not first appear on a
8095	declaration that follows a definition of the function.
8096
8097	The attribute only appertains to functions and only those that meet the
8098	following requirements.
8099
8100	- Has a non-deduced `void` return type.
8101	- Is not a constructor or destructor.
8102	- Is not a non-static member function with an explicit object parameter.
8103	- Is not a C variadic function.
8104	- Is not a coroutine.
8105	- Is not defined as deleted or as defaulted.
8106	- Is not defined with a function try block.
8107	- Is not declared with the `constexpr` or `consteval` specifiers.
8108	- Is not declared with the `[[noreturn]]` attribute.
8109
8110	Use in the implementation of a SYCL kernel invocation function might look as
8111	follows.
8112
8113	```c++
8114	namespace sycl {
8115	class handler {
8116	template<typename KernelName, typename... Ts>
8117	void sycl_kernel_launch(const char* kernelSymbol, Ts&&... kernelArgs) {
8118	// This code will run on the host and is responsible for calling functions
8119	// appropriate for the desired offload backend (OpenCL, CUDA, HIP,
8120	// Level Zero, etc...) to copy the kernel arguments denoted by kernelArgs
8121	// to a device and to schedule an invocation of the offload kernel entry
8122	// point denoted by kernelSymbol with the copied arguments.
8123	}
8124
8125	template<typename KernelName, typename KernelType>
8126	[[ clang::sycl_kernel_entry_point(KernelName) ]]
8127	void kernel_entry_point(KernelType kernelFunc) {
8128	// This code will run on the device. The call to kernelFunc() invokes
8129	// the SYCL kernel.
8130	kernelFunc();
8131	}
8132
8133	public:
8134	template<typename KernelName, typename KernelType>
8135	void single_task(const KernelType& kernelFunc) {
8136	// This code will run on the host. kernel_entry_point() is called to
8137	// trigger generation of an offload kernel entry point and to schedule
8138	// an invocation of it on a device with kernelFunc (a SYCL kernel object)
8139	// passed as a kernel argument. This call will result in an implicit call
8140	// to sycl_kernel_launch() with the symbol name for the generated offload
8141	// kernel entry point passed as the first function argument followed by
8142	// kernelFunc.
8143	kernel_entry_point<KernelName>(kernelFunc);
8144	}
8145	};
8146	} // namespace sycl
8147	```
8148
8149	A SYCL kernel object is a callable object of class type that is constructed on
8150	a host, often via a lambda expression, and then passed to a SYCL kernel
8151	invocation function to be executed on an offload device. The `kernelFunc`
8152	parameters in the example code above correspond to SYCL kernel objects.
8153
8154	A SYCL kernel object type is required to satisfy the device copyability
8155	requirements specified in section 3.13.1, "Device copyable", of the SYCL 2020
8156	specification. Additionally, any data members of the kernel object type are
8157	required to satisfy section 4.12.4, "Rules for parameter passing to kernels".
8158	For most types, these rules require that the type is trivially copyable.
8159	However, the SYCL specification mandates that certain special SYCL types, such
8160	as `sycl::accessor` and `sycl::stream`, be device copyable even if they are
8161	not trivially copyable. These types require special handling because they cannot
8162	necessarily be copied to device memory as if by `memcpy()`.
8163
8164	The SYCL kernel object and its data members constitute the parameters of an
8165	offload kernel. An offload kernel consists of an offload entry point function
8166	and the set of all functions and variables that are directly or indirectly used
8167	by the entry point function.
8168
8169	A SYCL kernel invocation function is responsible for performing the following
8170	tasks (likely with the help of an offload backend like OpenCL):
8171
8172	1. Identifying the offload kernel entry point to be used for the SYCL kernel.
8173	2. Validating that the SYCL kernel object type and its data members meet the
8174	SYCL device copyability and kernel parameter requirements noted above.
8175	3. Copying the SYCL kernel object and any other kernel arguments to device
8176	memory including any special handling required for SYCL special types.
8177	4. Initiating execution of the offload kernel entry point.
8178
8179	The offload kernel entry point for a SYCL kernel performs the following tasks:
8180
8181	1. Calling the `operator()` member function of the SYCL kernel object.
8182
8183	The `sycl_kernel_entry_point` attribute facilitates or automates these tasks
8184	by providing generation of an offload kernel entry point with a unique symbol
8185	name, type checking of kernel argument requirements, and initiation of kernel
8186	execution via synthesized calls to a `sycl_kernel_launch` template.
8187
8188	A function declared with the `sycl_kernel_entry_point` attribute specifies
8189	the parameters and body of an offload entry point function. Consider the
8190	following call to the `single_task()` SYCL kernel invocation function assuming
8191	an implementation similar to the one shown above.
8192
8193	```c++
8194	struct S { int i; };
8195	void f(sycl::handler &handler, sycl::stream &sout, S s) {
8196	handler.single_task<struct KN>([=] {
8197	sout << "The value of s.i is " << s.i << "\n";
8198	});
8199	}
8200	```
8201
8202	The SYCL kernel object is the result of the lambda expression. The call to
8203	`kernel_entry_point()` via the call to `single_task()` triggers the
8204	generation of an offload kernel entry point function that looks approximately
8205	as follows.
8206
8207	```c++
8208	void sycl-kernel-caller-for-KN(kernel-type kernelFunc) {
8209	kernelFunc();
8210	}
8211	```
8212
8213	There are a few items worthy of note:
8214
8215	1. `sycl-kernel-caller-for-KN` is an exposition only name; the actual name
8216	generated for an entry point is an implementation detail and subject to
8217	change. However, the name will incorporate the SYCL kernel name, `KN`,
8218	that was passed as the `KernelName` template parameter to
8219	`single_task()` and eventually provided as the argument to the
8220	`sycl_kernel_entry_point` attribute in order to ensure that a unique
8221	name is generated for each entry point. There is a one-to-one correspondence
8222	between SYCL kernel names and offload kernel entry points.
8223	2. The SYCL kernel is a lambda closure type and therefore has no name;
8224	`kernel-type` is substituted above and corresponds to the `KernelType`
8225	template parameter deduced in the call to `single_task()`.
8226	3. The parameter and the call to `kernelFunc()` in the function body
8227	correspond to the definition of `kernel_entry_point()` as called by
8228	`single_task()`.
8229	4. The parameter is type checked for conformance with the SYCL device
8230	copyability and kernel parameter requirements.
8231
8232	Within `single_task()`, the call to `kernel_entry_point()` is effectively
8233	replaced with a synthesized call to a ''sycl_kernel_launch\`\` template that
8234	looks approximately as follows.
8235
8236	```c++
8237	sycl_kernel_launch<KN>("sycl-kernel-caller-for-KN", kernelFunc);
8238	```
8239
8240	There are a few items worthy of note:
8241
8242	1. Lookup for the `sycl_kernel_launch` template is performed as if from the
8243	body of the (possibly instantiated) definition of `kernel_entry_point()`.
8244	If name lookup or overload resolution fails, the program is ill-formed.
8245	If the selected overload is a non-static member function, then `this` is
8246	passed as the implicit object parameter.
8247	2. Function arguments passed to `sycl_kernel_launch()` are passed
8248	as if by `std::move(x)`.
8249	3. The `sycl_kernel_launch` template is expected to be provided by the SYCL
8250	library implementation. It is responsible for copying the kernel arguments
8251	to device memory and for scheduling execution of the generated offload
8252	kernel entry point identified by the symbol name passed as the first
8253	function argument. `sycl-kernel-caller-for-KN` is substituted above for
8254	the actual symbol name that would be generated for the offload kernel entry
8255	point.
8256
8257	It is not necessary for a function declared with the `sycl_kernel_entry_point`
8258	attribute to be called for the offload kernel entry point to be emitted. For
8259	inline functions and function templates, any ODR-use will suffice. For other
8260	functions, an ODR-use is not required; the offload kernel entry point will be
8261	emitted if the function is defined. In any case, a call to the function is
8262	required for the synthesized call to `sycl_kernel_launch()` to occur.
8263
8264	A function declared with the `sycl_kernel_entry_point` attribute may include
8265	an exception specification. If a non-throwing exception specification is
8266	present, an exception propagating from the implicit call to the
8267	`sycl_kernel_launch` template will result in a call to `std::terminate()`.
8268	Otherwise, such an exception will propagate normally.
8269
8270	Functions declared with the `sycl_kernel_entry_point` attribute are not
8271	limited to the simple example shown above. They may have additional template
8272	parameters, declare additional function parameters, and have complex control
8273	flow in the function body. The function must abide by the language feature
8274	restrictions described in section 5.4, "Language restrictions for device
8275	functions" in the SYCL 2020 specification. If the function is a non-static
8276	member function, `this` shall not be used in a potentially evaluated
8277	expression.)reST";
8278
8279	static const char AttrDoc_SYCLLocalAddressSpace[] = R"reST(.. note::
8280
8281	These attributes are intended for use in the implementation of SYCL run-time
8282	libraries and should not be used in any other context.
8283	Programmers writing code intended to conform to the SYCL specification should
8284	use the address space facilities specified in the following sections of the
8285	SYCL 2020 specification.
8286
8287	* `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
8288	* `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
8289	* `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
8290	* `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
8291	* `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
8292
8293	The SYCL address space attributes listed below correspond to the five address
8294	spaces described by
8295	`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
8296	`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
8297
8298	.. list-table::
8299	:header-rows: 1
8300
8301	* - Address space attribute
8302	- SYCL address space
8303	- Description
8304	* - ``[[clang::sycl_global]]``
8305	- global
8306	- A memory region accessible by all work-items executing on a device.
8307	* - ``[[clang::sycl_local]]``
8308	- local
8309	- A memory region accessible by all work-items of a single work-group.
8310	* - ``[[clang::sycl_private]]``
8311	- private
8312	- A memory region that is private to a single work-item.
8313	* - ``[[clang::sycl_generic]]``
8314	- generic
8315	- A virtual memory region from which the global, local, and private memory
8316	regions may all be accessed.
8317	* - ``[[clang::sycl_constant]]``
8318	- constant
8319	- (deprecated) A memory region that holds constant data for an executing
8320	kernel.
8321
8322	The SYCL address space attributes are type attributes that may be applied to
8323	non-function non-reference types to specify an address space qualified type.
8324
8325	A type with a SYCL address space qualifier is a distinct type from the
8326	otherwise unattributed type. For example, ``int `` and ``int [[clang::sycl_global]]``
8327	designate distinct pointer types which participate in overload resolution and
8328	template specialization.
8329
8330	The top-level type of a variable declaration cannot have a SYCL address space
8331	qualifier. For example:
8332
8333	.. code-block:: c++
8334
8335	int [[clang::sycl_global]] gv; // error: the top-level type has an address space qualifier.
8336	int [[clang::sycl_global]] *pgi; // ok; the address space qualifier is on the pointee type.
8337
8338	Conversions between SYCL address space attributed types are permitted as
8339	follows.
8340
8341	* Types attributed with the global, local, or private address space attributes
8342	are implicitly convertible to matching types with the generic address space
8343	attribute.
8344
8345	The mapping of SYCL address spaces to physical address spaces is target
8346	dependent.
8347
8348	For OpenCL device targets, the SYCL address space attributes are aligned with
8349	the `OpenCL address space attributes <attr-opencl-addrspace_>`_ such that, e.g.,
8350	``int [[clang::sycl_global]]`` and ``int [[clang::opencl_global]]`` specify
8351	distinct types both of which map to the same underlying address space.
8352	Corresponding SYCL and OpenCL address space attributed types are implicitly
8353	convertible; other conversions are permitted as described above; e.g.,
8354	``int [[clang::sycl_global]]*`` is implicitly convertible to
8355	``int [[clang::opencl_generic]]*``.
8356
8357	.. _attr-opencl-addrspace:
8358	https://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces
8359	.. _SYCL-2020-3.8.2:
8360	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model
8361	.. _SYCL-2020-4.7.2:
8362	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:buffers
8363	.. _SYCL-2020-4.7.6:
8364	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:accessors
8365	.. _SYCL-2020-4.7.7:
8366	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes
8367	.. _SYCL-2020-F.7:
8368	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-static-addrspace-cast
8369	.. _SYCL-2020-F.8:
8370	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-dynamic-addrspace-cast)reST";
8371
8372	static const char AttrDoc_SYCLPrivateAddressSpace[] = R"reST(.. note::
8373
8374	These attributes are intended for use in the implementation of SYCL run-time
8375	libraries and should not be used in any other context.
8376	Programmers writing code intended to conform to the SYCL specification should
8377	use the address space facilities specified in the following sections of the
8378	SYCL 2020 specification.
8379
8380	* `4.7.2, "Buffers" <SYCL-2020-4.7.2_>`_
8381	* `4.7.6, "Accessors" <SYCL-2020-4.7.6_>`_.
8382	* `4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
8383	* `F.7, "sycl_khr_static_addrspace_cast" <SYCL-2020-F.7_>`_.
8384	* `F.8, "sycl_khr_dynamic_addrspace_cast" <SYCL-2020-F.8_>`_.
8385
8386	The SYCL address space attributes listed below correspond to the five address
8387	spaces described by
8388	`SYCL 2020 section 3.8.2, "SYCL device memory model" <SYCL-2020-3.8.2_>`_ and
8389	`SYCL 2020 section 4.7.7, "Address space classes" <SYCL-2020-4.7.7_>`_.
8390
8391	.. list-table::
8392	:header-rows: 1
8393
8394	* - Address space attribute
8395	- SYCL address space
8396	- Description
8397	* - ``[[clang::sycl_global]]``
8398	- global
8399	- A memory region accessible by all work-items executing on a device.
8400	* - ``[[clang::sycl_local]]``
8401	- local
8402	- A memory region accessible by all work-items of a single work-group.
8403	* - ``[[clang::sycl_private]]``
8404	- private
8405	- A memory region that is private to a single work-item.
8406	* - ``[[clang::sycl_generic]]``
8407	- generic
8408	- A virtual memory region from which the global, local, and private memory
8409	regions may all be accessed.
8410	* - ``[[clang::sycl_constant]]``
8411	- constant
8412	- (deprecated) A memory region that holds constant data for an executing
8413	kernel.
8414
8415	The SYCL address space attributes are type attributes that may be applied to
8416	non-function non-reference types to specify an address space qualified type.
8417
8418	A type with a SYCL address space qualifier is a distinct type from the
8419	otherwise unattributed type. For example, ``int `` and ``int [[clang::sycl_global]]``
8420	designate distinct pointer types which participate in overload resolution and
8421	template specialization.
8422
8423	The top-level type of a variable declaration cannot have a SYCL address space
8424	qualifier. For example:
8425
8426	.. code-block:: c++
8427
8428	int [[clang::sycl_global]] gv; // error: the top-level type has an address space qualifier.
8429	int [[clang::sycl_global]] *pgi; // ok; the address space qualifier is on the pointee type.
8430
8431	Conversions between SYCL address space attributed types are permitted as
8432	follows.
8433
8434	* Types attributed with the global, local, or private address space attributes
8435	are implicitly convertible to matching types with the generic address space
8436	attribute.
8437
8438	The mapping of SYCL address spaces to physical address spaces is target
8439	dependent.
8440
8441	For OpenCL device targets, the SYCL address space attributes are aligned with
8442	the `OpenCL address space attributes <attr-opencl-addrspace_>`_ such that, e.g.,
8443	``int [[clang::sycl_global]]`` and ``int [[clang::opencl_global]]`` specify
8444	distinct types both of which map to the same underlying address space.
8445	Corresponding SYCL and OpenCL address space attributed types are implicitly
8446	convertible; other conversions are permitted as described above; e.g.,
8447	``int [[clang::sycl_global]]*`` is implicitly convertible to
8448	``int [[clang::opencl_generic]]*``.
8449
8450	.. _attr-opencl-addrspace:
8451	https://clang.llvm.org/docs/AttributeReference.html#opencl-address-spaces
8452	.. _SYCL-2020-3.8.2:
8453	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_sycl_device_memory_model
8454	.. _SYCL-2020-4.7.2:
8455	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:buffers
8456	.. _SYCL-2020-4.7.6:
8457	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:accessors
8458	.. _SYCL-2020-4.7.7:
8459	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_address_space_classes
8460	.. _SYCL-2020-F.7:
8461	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-static-addrspace-cast
8462	.. _SYCL-2020-F.8:
8463	https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:khr-dynamic-addrspace-cast)reST";
8464
8465	static const char AttrDoc_SYCLSpecialClass[] = R"reST(SYCL defines some special classes (accessor, sampler, and stream) which require
8466	specific handling during the generation of the SPIR entry point.
8467	The `__attribute__((sycl_special_class))` attribute is used in SYCL
8468	headers to indicate that a class or a struct needs a specific handling when
8469	it is passed from host to device.
8470	Special classes will have a mandatory `__init` method and an optional
8471	`__finalize` method (the `__finalize` method is used only with the
8472	`stream` type). Kernel parameters types are extract from the `__init` method
8473	parameters. The kernel function arguments list is derived from the
8474	arguments of the `__init` method. The arguments of the `__init` method are
8475	copied into the kernel function argument list and the `__init` and
8476	`__finalize` methods are called at the beginning and the end of the kernel,
8477	respectively.
8478	The `__init` and `__finalize` methods must be defined inside the
8479	special class.
8480	Please note that this is an attribute that is used as an internal
8481	implementation detail and not intended to be used by external users.
8482
8483	The syntax of the attribute is as follows:
8484
8485	```text
8486	class __attribute__((sycl_special_class)) accessor {};
8487	class [[clang::sycl_special_class]] accessor {};
8488	```
8489
8490	This is a code example that illustrates the use of the attribute:
8491
8492	```c++
8493	class __attribute__((sycl_special_class)) SpecialType {
8494	int F1;
8495	int F2;
8496	void __init(int f1) {
8497	F1 = f1;
8498	F2 = f1;
8499	}
8500	void __finalize() {}
8501	public:
8502	SpecialType() = default;
8503	int getF2() const { return F2; }
8504	};
8505
8506	int main () {
8507	SpecialType T;
8508	cgh.single_task([=] {
8509	T.getF2();
8510	});
8511	}
8512	```
8513
8514	This would trigger the following kernel entry point in the AST:
8515
8516	```c++
8517	void __sycl_kernel(int f1) {
8518	SpecialType T;
8519	T.__init(f1);
8520	...
8521	T.__finalize()
8522	}
8523	```)reST";
8524
8525	static const char AttrDoc_ScopedLockable[] = R"reST(No documentation.)reST";
8526
8527	static const char AttrDoc_Section[] = R"reST(The `section` attribute allows you to specify a specific section a
8528	global variable or function should be in after translation.)reST";
8529
8530	static const char AttrDoc_SelectAny[] = R"reST(This attribute appertains to a global symbol, causing it to have a weak
8531	definition (
8532	[linkonce](https://llvm.org/docs/LangRef.html#linkage-types)
8533	), allowing the linker to select any definition.
8534
8535	For more information see
8536	[gcc documentation](https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html)
8537	or [msvc documentation](https://docs.microsoft.com/pl-pl/cpp/cpp/selectany).)reST";
8538
8539	static const char AttrDoc_Sentinel[] = R"reST(The `sentinel` attribute can be applied to variadic functions and pointers to
8540	variadic functions, to diagnose each function call that does not pass a
8541	sentinel value (a null pointer constant) as the last argument to the function
8542	call. The attribute accepts two optional arguments: the first argument is the
8543	position of the expected sentinel value, starting from the last parameter. The
8544	second argument describes whether the last fixed parameter is treated as a
8545	valid sentinel value when set to '1'.
8546	All arguments described above default to '0' when elided.
8547	The attribute is also supported with blocks and in Objective-C.
8548
8549	```c
8550	void foo(const char*, ...) __attribute__((sentinel));
8551	void bar(int, ...) __attribute__((sentinel(1)));
8552	void baz(const char, const char, ...) __attribute__((sentinel(0, 1)));
8553
8554	void example() {
8555	foo("Example", (void*)0);
8556	foo("Another", "example", NULL);
8557	foo("Missing", "sentinel"); // Not OK
8558
8559	bar(1, 2, NULL, 3); // OK: sentinel value at the 2nd to last position
8560	bar(1, 2, 3, nullptr, 4); // OK: `nullptr` is valid in C23
8561	bar(1, 2, 3, 4, NULL); // Not OK
8562
8563	baz("Test", "with", "multiple", "args", NULL);
8564	baz("One", NULL); // OK: last fixed parameter is a valid sentinel
8565
8566	void (*ptr) (int arg, ...) __attribute__ ((__sentinel__));
8567	ptr(1, 2, 3, NULL);
8568	}
8569	```
8570
8571	```c++
8572	struct Ty {
8573	int value;
8574
8575	template<typename T>
8576	auto&& foo(T&& val, ...) __attribute__((sentinel(1))) {
8577	return std::forward<T>(val);
8578	}
8579
8580	template<class Self>
8581	auto&& bar(this Self&& self, ...) __attribute__((sentinel(1))) {
8582	return std::forward<Self>(self).value;
8583	}
8584	};
8585
8586	void example2() {
8587	auto sty = Ty{};
8588	sty.foo(1, nullptr, 3);
8589	sty.bar(1, nullptr, 3);
8590
8591	auto lmbd = [](int a, ...) __attribute__((sentinel)) {};
8592	lmbd(1, 2, nullptr);
8593	}
8594	```)reST";
8595
8596	static const char AttrDoc_SetTypestate[] = R"reST(Annotate methods that transition an object into a new state with
8597	`__attribute__((set_typestate(new_state)))`. The new state must be
8598	unconsumed, consumed, or unknown.)reST";
8599
8600	static const char AttrDoc_SizedBy[] = R"reST(The `sized_by` attribute is applied to a pointer to indicate that the pointer
8601	points to memory containing at least the number of bytes given by the
8602	attribute's argument. It is closely related to `counted_by`; the difference is
8603	that `counted_by` counts the number of elements of the pointee type, whereas
8604	`sized_by` counts the number of bytes. This makes `sized_by` the natural
8605	choice for `void *` and other byte buffers.
8606
8607	This attribute is used by {doc}`-fbounds-safety <BoundsSafety>` to propagate
8608	bounds information on API surfaces without any ABI changes. This attribute is
8609	also used to improve the results of the array bound sanitizer and the
8610	`__builtin_dynamic_object_size` builtin.
8611
8612	The argument is an expression of integer type, following the same rules as the
8613	argument of `counted_by`. Unlike `counted_by`, `sized_by` cannot be
8614	applied to a C99 flexible array member; it applies to pointers only. For
8615	example:
8616
8617	```c
8618	struct object {
8619	unsigned long size;
8620	void *data __attribute__((sized_by(size)));
8621	};
8622	```
8623
8624	A pointer annotated with `sized_by` must have a size of zero when it is null.
8625	This requirement is currently only enforced when compiling with
8626	{doc}`-fbounds-safety <BoundsSafety>` (see {ref}`Current status of
8627	-fbounds-safety support in upstream Clang <bounds-safety-current-upstream-status>`). Use
8628	`sized_by_or_null` for a pointer that may be null while carrying a nonzero
8629	size.
8630
8631	#### Keeping pointer and size in sync
8632
8633	The `sized_by` attribute establishes a relationship between the annotated
8634	pointer and its size: the pointer must point to at least `size` bytes.
8635	Assigning to only one of them can break this relationship.
8636	Without {doc}`-fbounds-safety <BoundsSafety>`, it is the programmer's
8637	responsibility to ensure the pointer and size remain in sync. With
8638	`-fbounds-safety` it is automatically enforced. For example:
8639
8640	```c
8641	struct buffer {
8642	uint8_t *buf __attribute__((sized_by(size)));
8643	size_t size;
8644	};
8645
8646	void grow(struct buffer *b, size_t new_size) {
8647	// b->buf isn't updated. The underlying memory pointed to by b->buf might be
8648	// smaller than new_size which would contradict the sized_by attribute.
8649	// Compile error with -fbounds-safety but allowed without -fbounds-safety.
8650	b->size = new_size;
8651	}
8652	```
8653
8654	Updating both together - so that `buf` points to `size` bytes - keeps
8655	the attribute true. For example:
8656
8657	```c
8658	void grow(struct buffer *b, size_t new_size) {
8659	// Allowed by -fbounds-safety
8660	uint8_t *new_buf = malloc(new_size);
8661	// -fbounds-safety enforces that the `new_buf` points to at least `new_size`
8662	// bytes at runtime. Without -fbounds-safety nothing enforces this.
8663	b->buf = new_buf;
8664	b->size = new_size;
8665	}
8666	```
8667
8668	#### Incomplete and variable-length pointees
8669
8670	`sized_by` is typically applied to `void *` or a pointer to a byte-sized
8671	type, but it may be used with any pointee type. Two situations call for this,
8672	both of which rule out counting fixed-size elements:
8673
8674	First, the pointee type may be incomplete, such as an opaque type. Its element
8675	size is then unavailable, so `counted_by` cannot be used, whereas `sized_by`
8676	bounds the memory in bytes and imposes no completeness requirement.
8677
8678	Second, the buffer may hold variable-length elements, so there is no fixed
8679	element size to count, even though the total byte size is well defined. For
8680	example, a buffer might pack together several structures that each end in a
8681	flexible array member of differing length:
8682
8683	```c
8684	struct var_len {
8685	int fam_size;
8686	char data[] __attribute__((counted_by(fam_size)));
8687	};
8688
8689	struct buffer_view {
8690	int byte_size;
8691	struct var_len *buf __attribute__((sized_by(byte_size)));
8692	};
8693	```
8694
8695	Here `counted_by` cannot be applied to `buf` because its pointee is a
8696	variable-length structure, but `sized_by` bounds the whole region in bytes;
8697	the region is traversed by advancing a byte offset rather than by indexing
8698	elements.)reST";
8699
8700	static const char AttrDoc_SizedByOrNull[] = R"reST(The `sized_by_or_null` attribute is applied to a pointer to indicate that, if
8701	the pointer is non-null, it points to memory containing at least the number of
8702	bytes given by the attribute's argument. If the pointer is null, the value of
8703	the argument is ignored and the pointer points to zero bytes.
8704
8705	The `sized_by_or_null` attribute is identical to `sized_by` except in how
8706	it treats null pointers. Whereas `sized_by` requires a null pointer to have a
8707	size of zero, `sized_by_or_null` allows the pointer to be null regardless of
8708	the value of the size. This supports the common idiom where a pointer is either
8709	null or points to memory containing at least the given number of bytes.
8710
8711	Currently only {doc}`-fbounds-safety <BoundsSafety>` makes use of the
8712	distinction between `sized_by_or_null` and `sized_by` (see
8713	{ref}`Current status of -fbounds-safety support in upstream Clang
8714	<bounds-safety-current-upstream-status>`).)reST";
8715
8716	static const char AttrDoc_SpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
8717	that [Speculative Load Hardening][slh]
8718	should be enabled for the function body. This can also be applied to a method
8719	in Objective C. This attribute will take precedence over the command line flag
8720	in the case where {option}`-mno-speculative-load-hardening` is specified.
8721
8722	[slh]: https://llvm.org/docs/SpeculativeLoadHardening.html
8723
8724	Speculative Load Hardening is a best-effort mitigation against
8725	information leak attacks that make use of control flow
8726	miss-speculation - specifically miss-speculation of whether a branch
8727	is taken or not. Typically vulnerabilities enabling such attacks are
8728	classified as "Spectre variant #1". Notably, this does not attempt to
8729	mitigate against miss-speculation of branch target, classified as
8730	"Spectre variant #2" vulnerabilities.
8731
8732	When inlining, the attribute is sticky. Inlining a function that
8733	carries this attribute will cause the caller to gain the
8734	attribute. This is intended to provide a maximally conservative model
8735	where the code in a function annotated with this attribute will always
8736	(even after inlining) end up hardened.)reST";
8737
8738	static const char AttrDoc_StackProtectorIgnore[] = R"reST(The `stack_protector_ignore` attribute skips analysis of the given local
8739	variable when determining if a function should use a stack protector.
8740
8741	The `-fstack-protector` option uses a heuristic to only add stack protectors
8742	to functions which contain variables or buffers over some size threshold. This
8743	attribute overrides that heuristic for the attached variable, opting
8744	them out. If this results in no variables or buffers remaining over the stack
8745	protector threshold, then the function will no longer use a stack protector.)reST";
8746
8747	static const char AttrDoc_StandaloneDebug[] = R"reST(The `standalone_debug` attribute causes debug info to be emitted for a record
8748	type regardless of the debug info optimizations that are enabled with
8749	-fno-standalone-debug. This attribute only has an effect when debug info
8750	optimizations are enabled (e.g. with -fno-standalone-debug), and is C++-only.)reST";
8751
8752	static const char AttrDoc_StdCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
8753	function to clear parameters off of the stack on return. This convention does
8754	not support variadic calls or unprototyped functions in C, and has no effect on
8755	x86_64 targets. This calling convention is used widely by the Windows API and
8756	COM applications. See the documentation for [\_\_stdcall][__stdcall] on MSDN.
8757
8758	[__stdcall]: http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx)reST";
8759
8760	static const char AttrDoc_StrictFP[] = R"reST()reST";
8761
8762	static const char AttrDoc_StrictGuardStackCheck[] = R"reST(Clang supports the Microsoft style `__declspec((strict_gs_check))` attribute
8763	which upgrades the stack protector check from `-fstack-protector` to
8764	`-fstack-protector-strong`.
8765
8766	For example, it upgrades the stack protector for the function `foo` to
8767	`-fstack-protector-strong` but function `bar` will still be built with the
8768	stack protector with the `-fstack-protector` option.
8769
8770	```c
8771	__declspec((strict_gs_check))
8772	int foo(int x); // stack protection will be upgraded for foo.
8773
8774	int bar(int y); // bar can be built with the standard stack protector checks.
8775	```)reST";
8776
8777	static const char AttrDoc_Suppress[] = R"reST(The `suppress` attribute suppresses unwanted warnings coming from static
8778	analysis tools such as the Clang Static Analyzer. The tool will not report
8779	any issues in source code annotated with the attribute.
8780
8781	The attribute cannot be used to suppress traditional Clang warnings, because
8782	many such warnings are emitted before the attribute is fully parsed.
8783	Consider using `#pragma clang diagnostic` to control such diagnostics,
8784	as described in
8785	{ref}`Controlling Diagnostics via Pragmas <pragma-gcc-diagnostic>`.
8786
8787	The `suppress` attribute can be placed on an individual statement in order to
8788	suppress warnings about undesirable behavior occurring at that statement:
8789
8790	```c++
8791	int foo() {
8792	int *x = nullptr;
8793	...
8794	[[clang::suppress]]
8795	return *x; // null pointer dereference warning suppressed here
8796	}
8797	```
8798
8799	Putting the attribute on a compound statement suppresses all warnings in scope:
8800
8801	```c++
8802	int foo() {
8803	[[clang::suppress]] {
8804	int *x = nullptr;
8805	...
8806	return *x; // warnings suppressed in the entire scope
8807	}
8808	}
8809	```
8810
8811	The attribute can also be placed on entire declarations of functions, classes,
8812	variables, member variables, and so on, to suppress warnings related
8813	to the declarations themselves. When used this way, the attribute additionally
8814	suppresses all warnings in the lexical scope of the declaration:
8815
8816	```c++
8817	class [[clang::suppress]] C {
8818	int foo() {
8819	int *x = nullptr;
8820	...
8821	return *x; // warnings suppressed in the entire class scope
8822	}
8823
8824	int bar();
8825	};
8826
8827	int C::bar() {
8828	int *x = nullptr;
8829	...
8830	return *x; // warning NOT suppressed! - not lexically nested in 'class C{}'
8831	}
8832	```
8833
8834	Some static analysis warnings are accompanied by one or more notes, and the
8835	line of code against which the warning is emitted isn't necessarily the best
8836	for suppression purposes. In such cases the tools are allowed to implement
8837	additional ways to suppress specific warnings based on the attribute attached
8838	to a note location.
8839
8840	For example, the Clang Static Analyzer suppresses memory leak warnings when
8841	the suppression attribute is placed at the allocation site (highlited by
8842	a "note: memory is allocated"), which may be different from the line of code
8843	at which the program "loses track" of the pointer (where the warning
8844	is ultimately emitted):
8845
8846	```c
8847	int bar1(bool coin_flip) {
8848	__attribute__((suppress))
8849	int result = (int )malloc(sizeof(int));
8850	if (coin_flip)
8851	return 1; // warning about this leak path is suppressed
8852
8853	return *result; // warning about this leak path is also suppressed
8854	}
8855
8856	int bar2(bool coin_flip) {
8857	int result = (int )malloc(sizeof(int));
8858	if (coin_flip)
8859	return 1; // leak warning on this path NOT suppressed
8860
8861	__attribute__((suppress))
8862	return *result; // leak warning is suppressed only on this path
8863	}
8864	```
8865
8866	When written as `[[gsl::suppress]]`, this attribute suppresses specific
8867	clang-tidy diagnostics for rules of the [C++ Core Guidelines][c++ core guidelines] in a portable
8868	way. The attribute can be attached to declarations, statements, and at
8869	namespace scope.
8870
8871	```c++
8872	[[gsl::suppress("Rh-public")]]
8873	void f_() {
8874	int *p;
8875	[[gsl::suppress("type")]] {
8876	p = reinterpret_cast<int*>(7);
8877	}
8878	}
8879	namespace N {
8880	[[clang::suppress("type", "bounds")]];
8881	...
8882	}
8883	```
8884
8885	[c++ core guidelines]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement)reST";
8886
8887	static const char AttrDoc_SwiftAsync[] = R"reST(The `swift_async` attribute specifies if and how a particular function or
8888	Objective-C method is imported into a swift async method. For instance:
8889
8890	```objc
8891	@interface MyClass : NSObject
8892	-(void)notActuallyAsync:(int)p1 withCompletionHandler:(void (^)())handler
8893	__attribute__((swift_async(none)));
8894
8895	-(void)actuallyAsync:(int)p1 callThisAsync:(void (^)())fun
8896	__attribute__((swift_async(swift_private, 1)));
8897	@end
8898	```
8899
8900	Here, `notActuallyAsync:withCompletionHandler` would have been imported as
8901	`async` (because it's last parameter's selector piece is
8902	`withCompletionHandler`) if not for the `swift_async(none)` attribute.
8903	Conversely, `actuallyAsync:callThisAsync` wouldn't have been imported as
8904	`async` if not for the `swift_async` attribute because it doesn't match the
8905	naming convention.
8906
8907	When using `swift_async` to enable importing, the first argument to the
8908	attribute is either `swift_private` or `not_swift_private` to indicate
8909	whether the function/method is private to the current framework, and the second
8910	argument is the index of the completion handler parameter.)reST";
8911
8912	static const char AttrDoc_SwiftAsyncCall[] = R"reST(The `swiftasynccall` attribute indicates that a function is
8913	compatible with the low-level conventions of Swift async functions,
8914	provided it declares the right formal arguments.
8915
8916	In most respects, this is similar to the `swiftcall` attribute, except for
8917	the following:
8918
8919	- A parameter may be marked `swift_async_context`, `swift_context`
8920	or `swift_indirect_result` (with the same restrictions on parameter
8921	ordering as `swiftcall`) but the parameter attribute
8922	`swift_error_result` is not permitted.
8923	- A `swiftasynccall` function must have return type `void`.
8924	- Within a `swiftasynccall` function, a call to a `swiftasynccall`
8925	function that is the immediate operand of a `return` statement is
8926	guaranteed to be performed as a tail call. This syntax is allowed even
8927	in C as an extension (a call to a void-returning function cannot be a
8928	return operand in standard C). If something in the calling function would
8929	semantically be performed after a guaranteed tail call, such as the
8930	non-trivial destruction of a local variable or temporary,
8931	then the program is ill-formed.
8932
8933	Query for this attribute with `__has_attribute(swiftasynccall)`. Query if
8934	the target supports the calling convention with
8935	`__has_extension(swiftasynccc)`.
8936
8937	Since this attribute follows the Swift async calling convention, it is
8938	considered ABI-unstable except on targets where the Swift project
8939	has declared ABI stability. Users are responsible for ensuring that
8940	calls and definitions of functions with this attribute are compiled
8941	with compatible compilers. Note that different operating systems
8942	on the same architecture may use different ABIs and therefore may
8943	have different standards for ABI stability.)reST";
8944
8945	static const char AttrDoc_SwiftAsyncContext[] = R"reST(The `swift_async_context` attribute marks a parameter of a `swiftasynccall`
8946	function as having the special asynchronous context-parameter ABI treatment.
8947
8948	If the function is not `swiftasynccall`, this attribute only generates
8949	extended frame information.
8950
8951	A context parameter must have pointer or reference type.)reST";
8952
8953	static const char AttrDoc_SwiftAsyncError[] = R"reST(The `swift_async_error` attribute specifies how an error state will be
8954	represented in a swift async method. It's a bit analogous to the `swift_error`
8955	attribute for the generated async method. The `swift_async_error` attribute
8956	can indicate a variety of different ways of representing an error.
8957
8958	- `__attribute__((swift_async_error(zero_argument, N)))`, specifies that the
8959	async method is considered to have failed if the Nth argument to the
8960	completion handler is zero.
8961	- `__attribute__((swift_async_error(nonzero_argument, N)))`, specifies that
8962	the async method is considered to have failed if the Nth argument to the
8963	completion handler is non-zero.
8964	- `__attribute__((swift_async_error(nonnull_error)))`, specifies that the
8965	async method is considered to have failed if the `NSError *` argument to the
8966	completion handler is non-null.
8967	- `__attribute__((swift_async_error(none)))`, specifies that the async method
8968	cannot fail.
8969
8970	For instance:
8971
8972	```objc
8973	@interface MyClass : NSObject
8974	-(void)asyncMethod:(void (^)(char, int, float))handler
8975	__attribute__((swift_async(swift_private, 1)))
8976	__attribute__((swift_async_error(zero_argument, 2)));
8977	@end
8978	```
8979
8980	Here, the `swift_async` attribute specifies that `handler` is the completion
8981	handler for this method, and the `swift_async_error` attribute specifies that
8982	the `int` parameter is the one that represents the error.)reST";
8983
8984	static const char AttrDoc_SwiftAsyncName[] = R"reST(The `swift_async_name` attribute provides the name of the `async` overload for
8985	the given declaration in Swift. If this attribute is absent, the name is
8986	transformed according to the algorithm built into the Swift compiler.
8987
8988	The argument is a string literal that contains the Swift name of the function or
8989	method. The name may be a compound Swift name. The function or method with such
8990	an attribute must have more than zero parameters, as its last parameter is
8991	assumed to be a callback that's eliminated in the Swift `async` name.
8992
8993	```objc
8994	@interface URL
8995	+ (void) loadContentsFrom:(URL )url callback:(void (^)(NSData ))data __attribute__((__swift_async_name__("URL.loadContentsFrom(_:)")))
8996	@end
8997	```)reST";
8998
8999	static const char AttrDoc_SwiftAttr[] = R"reST(The `swift_attr` provides a Swift-specific annotation for the declaration
9000	or type to which the attribute appertains to. It can be used on any declaration
9001	or type in Clang. This kind of annotation is ignored by Clang as it doesn't have any
9002	semantic meaning in languages supported by Clang. The Swift compiler can
9003	interpret these annotations according to its own rules when importing C or
9004	Objective-C declarations.)reST";
9005
9006	static const char AttrDoc_SwiftBridge[] = R"reST(The `swift_bridge` attribute indicates that the declaration to which the
9007	attribute appertains is bridged to the named Swift type.
9008
9009	```objc
9010	__attribute__((__objc_root__))
9011	@interface Base
9012	- (instancetype)init;
9013	@end
9014
9015	__attribute__((__swift_bridge__("BridgedI")))
9016	@interface I : Base
9017	@end
9018	```
9019
9020	In this example, the Objective-C interface `I` will be made available to Swift
9021	with the name `BridgedI`. It would be possible for the compiler to refer to
9022	`I` still in order to bridge the type back to Objective-C.)reST";
9023
9024	static const char AttrDoc_SwiftBridgedTypedef[] = R"reST(The `swift_bridged_typedef` attribute indicates that when the typedef to which
9025	the attribute appertains is imported into Swift, it should refer to the bridged
9026	Swift type (e.g. Swift's `String`) rather than the Objective-C type as written
9027	(e.g. `NSString`).
9028
9029	```objc
9030	@interface NSString;
9031	typedef NSString *AliasedString __attribute__((__swift_bridged_typedef__));
9032
9033	extern void acceptsAliasedString(AliasedString _Nonnull parameter);
9034	```
9035
9036	In this case, the function `acceptsAliasedString` will be imported into Swift
9037	as a function which accepts a `String` type parameter.)reST";
9038
9039	static const char AttrDoc_SwiftCall[] = R"reST(The `swiftcall` attribute indicates that a function should be called
9040	using the Swift calling convention for a function or function pointer.
9041
9042	The lowering for the Swift calling convention, as described by the Swift
9043	ABI documentation, occurs in multiple phases. The first, "high-level"
9044	phase breaks down the formal parameters and results into innately direct
9045	and indirect components, adds implicit parameters for the generic
9046	signature, and assigns the context and error ABI treatments to parameters
9047	where applicable. The second phase breaks down the direct parameters
9048	and results from the first phase and assigns them to registers or the
9049	stack. The `swiftcall` convention only handles this second phase of
9050	lowering; the C function type must accurately reflect the results
9051	of the first phase, as follows:
9052
9053	- Results classified as indirect by high-level lowering should be
9054	represented as parameters with the `swift_indirect_result` attribute.
9055
9056	- Results classified as direct by high-level lowering should be represented
9057	as follows:
9058
9059	- First, remove any empty direct results.
9060	- If there are no direct results, the C result type should be `void`.
9061	- If there is one direct result, the C result type should be a type with
9062	the exact layout of that result type.
9063	- If there are a multiple direct results, the C result type should be
9064	a struct type with the exact layout of a tuple of those results.
9065
9066	- Parameters classified as indirect by high-level lowering should be
9067	represented as parameters of pointer type.
9068
9069	- Parameters classified as direct by high-level lowering should be
9070	omitted if they are empty types; otherwise, they should be represented
9071	as a parameter type with a layout exactly matching the layout of the
9072	Swift parameter type.
9073
9074	- The context parameter, if present, should be represented as a trailing
9075	parameter with the `swift_context` attribute.
9076
9077	- The error result parameter, if present, should be represented as a
9078	trailing parameter (always following a context parameter) with the
9079	`swift_error_result` attribute.
9080
9081	`swiftcall` does not support variadic arguments or unprototyped functions.
9082
9083	The parameter ABI treatment attributes are aspects of the function type.
9084	A function type which applies an ABI treatment attribute to a
9085	parameter is a different type from an otherwise-identical function type
9086	that does not. A single parameter may not have multiple ABI treatment
9087	attributes.
9088
9089	Support for this feature is target-dependent, although it should be
9090	supported on every target that Swift supports. Query for this attribute
9091	with `__has_attribute(swiftcall)`. Query if the target supports the
9092	calling convention with `__has_extension(swiftcc)`. This implies
9093	support for the `swift_context`, `swift_error_result`, and
9094	`swift_indirect_result` attributes.
9095
9096	Since this attribute follows the Swift calling convention, it is
9097	considered ABI-unstable except on targets where the Swift project
9098	has declared ABI stability. Users are responsible for ensuring that
9099	calls and definitions of functions with this attribute are compiled
9100	with compatible compilers. Note that different operating systems
9101	on the same architecture may use different ABIs and therefore may
9102	have different standards for ABI stability.)reST";
9103
9104	static const char AttrDoc_SwiftContext[] = R"reST(The `swift_context` attribute marks a parameter of a `swiftcall`
9105	or `swiftasynccall` function as having the special context-parameter
9106	ABI treatment.
9107
9108	This treatment generally passes the context value in a special register
9109	which is normally callee-preserved.
9110
9111	A `swift_context` parameter must either be the last parameter or must be
9112	followed by a `swift_error_result` parameter (which itself must always be
9113	the last parameter).
9114
9115	A context parameter must have pointer or reference type.)reST";
9116
9117	static const char AttrDoc_SwiftError[] = R"reST(The `swift_error` attribute controls whether a particular function (or
9118	Objective-C method) is imported into Swift as a throwing function, and if so,
9119	which dynamic convention it uses.
9120
9121	All of these conventions except `none` require the function to have an error
9122	parameter. Currently, the error parameter is always the last parameter of type
9123	`NSError*` or `CFErrorRef`. Swift will remove the error parameter from
9124	the imported API. When calling the API, Swift will always pass a valid address
9125	initialized to a null pointer.
9126
9127	- `swift_error(none)` means that the function should not be imported as
9128	throwing. The error parameter and result type will be imported normally.
9129	- `swift_error(null_result)` means that calls to the function should be
9130	considered to have thrown if they return a null value. The return type must be
9131	a pointer type, and it will be imported into Swift with a non-optional type.
9132	This is the default error convention for Objective-C methods that return
9133	pointers.
9134	- `swift_error(zero_result)` means that calls to the function should be
9135	considered to have thrown if they return a zero result. The return type must be
9136	an integral type. If the return type would have been imported as `Bool`, it
9137	is instead imported as `Void`. This is the default error convention for
9138	Objective-C methods that return a type that would be imported as `Bool`.
9139	- `swift_error(nonzero_result)` means that calls to the function should be
9140	considered to have thrown if they return a non-zero result. The return type must
9141	be an integral type. If the return type would have been imported as `Bool`,
9142	it is instead imported as `Void`.
9143	- `swift_error(nonnull_error)` means that calls to the function should be
9144	considered to have thrown if they leave a non-null error in the error parameter.
9145	The return type is left unmodified.)reST";
9146
9147	static const char AttrDoc_SwiftErrorResult[] = R"reST(The `swift_error_result` attribute marks a parameter of a `swiftcall`
9148	function as having the special error-result ABI treatment.
9149
9150	This treatment generally passes the underlying error value in and out of
9151	the function through a special register which is normally callee-preserved.
9152	This is modeled in C by pretending that the register is addressable memory:
9153
9154	- The caller appears to pass the address of a variable of pointer type.
9155	The current value of this variable is copied into the register before
9156	the call; if the call returns normally, the value is copied back into the
9157	variable.
9158	- The callee appears to receive the address of a variable. This address
9159	is actually a hidden location in its own stack, initialized with the
9160	value of the register upon entry. When the function returns normally,
9161	the value in that hidden location is written back to the register.
9162
9163	A `swift_error_result` parameter must be the last parameter, and it must be
9164	preceded by a `swift_context` parameter.
9165
9166	A `swift_error_result` parameter must have type `T*` or `T&` for some
9167	type T. Note that no qualifiers are permitted on the intermediate level.
9168
9169	It is undefined behavior if the caller does not pass a pointer or
9170	reference to a valid object.
9171
9172	The standard convention is that the error value itself (that is, the
9173	value stored in the apparent argument) will be null upon function entry,
9174	but this is not enforced by the ABI.)reST";
9175
9176	static const char AttrDoc_SwiftImportAsNonGeneric[] = R"reST()reST";
9177
9178	static const char AttrDoc_SwiftImportPropertyAsAccessors[] = R"reST()reST";
9179
9180	static const char AttrDoc_SwiftIndirectResult[] = R"reST(The `swift_indirect_result` attribute marks a parameter of a `swiftcall`
9181	or `swiftasynccall` function as having the special indirect-result ABI
9182	treatment.
9183
9184	This treatment gives the parameter the target's normal indirect-result
9185	ABI treatment, which may involve passing it differently from an ordinary
9186	parameter. However, only the first indirect result will receive this
9187	treatment. Furthermore, low-level lowering may decide that a direct result
9188	must be returned indirectly; if so, this will take priority over the
9189	`swift_indirect_result` parameters.
9190
9191	A `swift_indirect_result` parameter must either be the first parameter or
9192	follow another `swift_indirect_result` parameter.
9193
9194	A `swift_indirect_result` parameter must have type `T*` or `T&` for
9195	some object type `T`. If `T` is a complete type at the point of
9196	definition of a function, it is undefined behavior if the argument
9197	value does not point to storage of adequate size and alignment for a
9198	value of type `T`.
9199
9200	Making indirect results explicit in the signature allows C functions to
9201	directly construct objects into them without relying on language
9202	optimizations like C++'s named return value optimization (NRVO).)reST";
9203
9204	static const char AttrDoc_SwiftName[] = R"reST(The `swift_name` attribute provides the name of the declaration in Swift. If
9205	this attribute is absent, the name is transformed according to the algorithm
9206	built into the Swift compiler.
9207
9208	The argument is a string literal that contains the Swift name of the function,
9209	variable, or type. When renaming a function, the name may be a compound Swift
9210	name. For a type, enum constant, property, or variable declaration, the name
9211	must be a simple or qualified identifier.
9212
9213	```objc
9214	@interface URL
9215	- (void) initWithString:(NSString *)s __attribute__((__swift_name__("URL.init(_:)")))
9216	@end
9217
9218	void __attribute__((__swift_name__("squareRoot()"))) sqrt(double v) {
9219	}
9220	```)reST";
9221
9222	static const char AttrDoc_SwiftNewType[] = R"reST(The `swift_newtype` attribute indicates that the typedef to which the
9223	attribute appertains is imported as a new Swift type of the typedef's name.
9224	Previously, the attribute was spelt `swift_wrapper`. While the behaviour of
9225	the attribute is identical with either spelling, `swift_wrapper` is
9226	deprecated, only exists for compatibility purposes, and should not be used in
9227	new code.
9228
9229	- `swift_newtype(struct)` means that a Swift struct will be created for this
9230	typedef.
9231
9232	- `swift_newtype(enum)` means that a Swift enum will be created for this
9233	typedef.
9234
9235	```c
9236	// Import UIFontTextStyle as an enum type, with enumerated values being
9237	// constants.
9238	typedef NSString * UIFontTextStyle __attribute__((__swift_newtype__(enum)));
9239
9240	// Import UIFontDescriptorFeatureKey as a structure type, with enumerated
9241	// values being members of the type structure.
9242	typedef NSString * UIFontDescriptorFeatureKey __attribute__((__swift_newtype__(struct)));
9243	```)reST";
9244
9245	static const char AttrDoc_SwiftNullability[] = R"reST()reST";
9246
9247	static const char AttrDoc_SwiftObjCMembers[] = R"reST(This attribute indicates that Swift subclasses and members of Swift extensions
9248	of this class will be implicitly marked with the `@objcMembers` Swift
9249	attribute, exposing them back to Objective-C.)reST";
9250
9251	static const char AttrDoc_SwiftPrivate[] = R"reST(Declarations marked with the `swift_private` attribute are hidden from the
9252	framework client but are still made available for use within the framework or
9253	Swift SDK overlay.
9254
9255	The purpose of this attribute is to permit a more idomatic implementation of
9256	declarations in Swift while hiding the non-idiomatic one.)reST";
9257
9258	static const char AttrDoc_SwiftType[] = R"reST()reST";
9259
9260	static const char AttrDoc_SwiftVersionedAddition[] = R"reST()reST";
9261
9262	static const char AttrDoc_SwiftVersionedRemoval[] = R"reST()reST";
9263
9264	static const char AttrDoc_SysVABI[] = R"reST(On Windows x86_64 targets, this attribute changes the calling convention of a
9265	function to match the default convention used on Sys V targets such as Linux,
9266	Mac, and BSD. This attribute has no effect on other targets.)reST";
9267
9268	static const char AttrDoc_TLSModel[] = R"reST(The `tls_model` attribute allows you to specify which thread-local storage
9269	model to use. It accepts the following strings:
9270
9271	- global-dynamic
9272	- local-dynamic
9273	- initial-exec
9274	- local-exec
9275
9276	TLS models are mutually exclusive.)reST";
9277
9278	static const char AttrDoc_Target[] = R"reST(Clang supports the GNU style `__attribute__((target("OPTIONS")))` attribute.
9279	This attribute may be attached to a function definition and instructs
9280	the backend to use different code generation options than were passed on the
9281	command line.
9282
9283	The current set of options correspond to the existing "subtarget features" for
9284	the target with or without a "-mno-" in front corresponding to the absence
9285	of the feature, as well as `arch="CPU"` which will change the default "CPU"
9286	for the function.
9287
9288	For X86, the attribute also allows `tune="CPU"` to optimize the generated
9289	code for the given CPU without changing the available instructions.
9290
9291	For AArch64, `arch="Arch"` will set the architecture, similar to the -march
9292	command line options. `cpu="CPU"` can be used to select a specific cpu,
9293	as per the `-mcpu` option, similarly for `tune=`. The attribute also allows the
9294	"branch-protection=\<args>" option, where the permissible arguments and their
9295	effect on code generation are the same as for the command-line option
9296	`-mbranch-protection`.
9297
9298	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
9299	"avx", "xop" and largely correspond to the machine specific options handled by
9300	the front end.
9301
9302	Note that this attribute does not apply transitively to nested functions such
9303	as blocks or C++ lambdas.
9304
9305	Additionally, this attribute supports function multiversioning for ELF based
9306	x86/x86-64 targets, which can be used to create multiple implementations of the
9307	same function that will be resolved at runtime based on the priority of their
9308	`target` attribute strings. A function is considered a multiversioned function
9309	if either two declarations of the function have different `target` attribute
9310	strings, or if it has a `target` attribute string of `default`. For
9311	example:
9312
9313	```c++
9314	__attribute__((target("arch=atom")))
9315	void foo() {} // will be called on 'atom' processors.
9316	__attribute__((target("default")))
9317	void foo() {} // will be called on any other processors.
9318	```
9319
9320	All multiversioned functions must contain a `default` (fallback)
9321	implementation, otherwise usages of the function are considered invalid.
9322	Additionally, a function may not become multiversioned after its first use.)reST";
9323
9324	static const char AttrDoc_TargetClones[] = R"reST(Clang supports the `target_clones("OPTIONS")` attribute. This attribute may be
9325	attached to a function declaration and causes function multiversioning, where
9326	multiple versions of the function will be emitted with different code
9327	generation options. Additionally, these versions will be resolved at runtime
9328	based on the priority of their attribute options. All `target_clone` functions
9329	are considered multiversioned functions.
9330
9331	For AArch64 target:
9332	The attribute contains comma-separated strings of target features joined by "+"
9333	sign. For example:
9334
9335	```c++
9336	__attribute__((target_clones("sha2+memtag", "fcma+sve2-pmull128")))
9337	void foo() {}
9338	```
9339
9340	For every multiversioned function a `default` (fallback) implementation
9341	always generated if not specified directly.
9342
9343	For x86/x86-64 targets:
9344	All multiversioned functions must contain a `default` (fallback)
9345	implementation, otherwise usages of the function are considered invalid.
9346	Additionally, a function may not become multiversioned after its first use.
9347
9348	The options to `target_clones` can either be a target-specific architecture
9349	(specified as `arch=CPU`), or one of a list of subtarget features.
9350
9351	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
9352	"avx", "xop" and largely correspond to the machine specific options handled by
9353	the front end.
9354
9355	The versions can either be listed as a comma-separated sequence of string
9356	literals or as a single string literal containing a comma-separated list of
9357	versions. For compatibility with GCC, the two formats can be mixed. For
9358	example, the following will emit 4 versions of the function:
9359
9360	```c++
9361	__attribute__((target_clones("arch=atom,avx2","arch=ivybridge","default")))
9362	void foo() {}
9363	```
9364
9365	For targets that support the GNU indirect function (IFUNC) feature, dispatch
9366	is performed by emitting an indirect function that is resolved to the appropriate
9367	target clone at load time. The indirect function is given the name the
9368	multiversioned function would have if it had been declared without the attribute.
9369	For backward compatibility with earlier Clang releases, a function alias with an
9370	`.ifunc` suffix is also emitted. The `.ifunc` suffixed symbol is a deprecated
9371	feature and support for it may be removed in the future.
9372
9373	For PowerPC targets, `target_clones` is supported on AIX only. Only CPU
9374	(specified as `cpu=CPU`) and `default` options are allowed. IFUNC is supported
9375	on AIX in Clang, so dispatch is implemented similar to other targets using IFUNC.
9376	An FMV function that is only declared in a translation unit is treated as a
9377	non-FMV. The resolver and the function clones are given internal linkage.)reST";
9378
9379	static const char AttrDoc_TargetVersion[] = R"reST(For AArch64 target clang supports function multiversioning by
9380	`__attribute__((target_version("OPTIONS")))` attribute. When applied to a
9381	function it instructs compiler to emit multiple function versions based on
9382	`target_version` attribute strings, which resolved at runtime depend on their
9383	priority and target features availability. One of the versions is always
9384	( implicitly or explicitly ) the `default` (fallback). Attribute strings can
9385	contain dependent features names joined by the "+" sign.
9386
9387	For targets that support the GNU indirect function (IFUNC) feature, dispatch
9388	is performed by emitting an indirect function that is resolved to the appropriate
9389	target clone at load time. The indirect function is given the name the
9390	multiversioned function would have if it had been declared without the attribute.
9391	For backward compatibility with earlier Clang releases, a function alias with an
9392	`.ifunc` suffix is also emitted. The `.ifunc` suffixed symbol is a deprecated
9393	feature and support for it may be removed in the future.)reST";
9394
9395	static const char AttrDoc_TestTypestate[] = R"reST(Use `__attribute__((test_typestate(tested_state)))` to indicate that a method
9396	returns true if the object is in the specified state..)reST";
9397
9398	static const char AttrDoc_ThisCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
9399	function to use ECX for the first parameter (typically the implicit `this`
9400	parameter of C++ methods) and clear parameters off of the stack on return. This
9401	convention does not support variadic calls or unprototyped functions in C, and
9402	has no effect on x86_64 targets. See the documentation for [\_\_thiscall][__thiscall] on
9403	MSDN.
9404
9405	[__thiscall]: http://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx)reST";
9406
9407	static const char AttrDoc_Thread[] = R"reST(The `__declspec(thread)` attribute declares a variable with thread local
9408	storage. It is available under the `-fms-extensions` flag for MSVC
9409	compatibility. See the documentation for [\_\_declspec(thread)][__declspec(thread)] on MSDN.
9410
9411	In Clang, `__declspec(thread)` is generally equivalent in functionality to the
9412	GNU `__thread` keyword. The variable must not have a destructor and must have
9413	a constant initializer, if any. The attribute only applies to variables
9414	declared with static storage duration, such as globals, class static data
9415	members, and static locals.
9416
9417	[__declspec(thread)]: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx)reST";
9418
9419	static const char AttrDoc_TransparentUnion[] = R"reST(This attribute can be applied to a union to change the behavior of calls to
9420	functions that have an argument with a transparent union type. The compiler
9421	behavior is changed in the following manner:
9422
9423	- A value whose type is any member of the transparent union can be passed as an
9424	argument without the need to cast that value.
9425	- The argument is passed to the function using the calling convention of the
9426	first member of the transparent union. Consequently, all the members of the
9427	transparent union should have the same calling convention as its first member.
9428
9429	Transparent unions are not supported in C++.)reST";
9430
9431	static const char AttrDoc_TrivialABI[] = R"reST(The `trivial_abi` attribute can be applied to a C++ class, struct, or union.
9432	It instructs the compiler to pass and return the type using the C ABI for the
9433	underlying type when the type would otherwise be considered non-trivial for the
9434	purpose of calls.
9435	A class annotated with `trivial_abi` can have non-trivial destructors or
9436	copy/move constructors without automatically becoming non-trivial for the
9437	purposes of calls. For example:
9438
9439	```c++
9440	// A is trivial for the purposes of calls because `trivial_abi` makes the
9441	// user-provided special functions trivial.
9442	struct __attribute__((trivial_abi)) A {
9443	~A();
9444	A(const A &);
9445	A(A &&);
9446	int x;
9447	};
9448
9449	// B's destructor and copy/move constructor are considered trivial for the
9450	// purpose of calls because A is trivial.
9451	struct B {
9452	A a;
9453	};
9454	```
9455
9456	If a type is trivial for the purposes of calls, has a non-trivial destructor,
9457	and is passed as an argument by value, the convention is that the callee will
9458	destroy the object before returning. The lifetime of the copy of the parameter
9459	in the caller ends without a destructor call when the call begins.
9460
9461	If a type is trivial for the purpose of calls, it is assumed to be trivially
9462	relocatable for the purpose of `__is_trivially_relocatable` and
9463	`__builtin_is_cpp_trivially_relocatable`.
9464	When a type marked with `[[trivial_abi]]` is used as a function argument,
9465	the compiler may omit the call to the copy constructor.
9466	Thus, side effects of the copy constructor are potentially not performed.
9467	For example, objects that contain pointers to themselves or otherwise depend
9468	on their address (or the address or their subobjects) should not be declared
9469	`[[trivial_abi]]`.
9470
9471	Attribute `trivial_abi` has no effect in the following cases:
9472
9473	- The class directly declares a virtual base or virtual methods.
9474
9475	- Copy constructors and move constructors of the class are all deleted.
9476
9477	- The class has a base class that is non-trivial for the purposes of calls.
9478
9479	- The class has a non-static data member whose type is non-trivial for the
9480	purposes of calls, which includes:
9481
9482	- classes that are non-trivial for the purposes of calls
9483	- \_\_weak-qualified types in Objective-C++
9484	- arrays of any of the above)reST";
9485
9486	static const char AttrDoc_TryAcquireCapability[] = R"reST(Marks a function that attempts to acquire a capability. This function may fail to
9487	actually acquire the capability; they accept a Boolean value determining
9488	whether acquiring the capability means success (true), or failing to acquire
9489	the capability means success (false).)reST";
9490
9491	static const char AttrDoc_TypeNonNull[] = R"reST(The `_Nonnull` nullability qualifier indicates that null is not a meaningful
9492	value for a value of the `_Nonnull` pointer type. For example, given a
9493	declaration such as:
9494
9495	```c
9496	int fetch(int * _Nonnull ptr);
9497	```
9498
9499	a caller of `fetch` should not provide a null value, and the compiler will
9500	produce a warning if it sees a literal null value passed to `fetch`. Note
9501	that, unlike the declaration attribute `nonnull`, the presence of
9502	`_Nonnull` does not imply that passing null is undefined behavior: `fetch`
9503	is free to consider null undefined behavior or (perhaps for
9504	backward-compatibility reasons) defensively handle null.)reST";
9505
9506	static const char AttrDoc_TypeNullUnspecified[] = R"reST(The `_Null_unspecified` nullability qualifier indicates that neither the
9507	`_Nonnull` nor `_Nullable` qualifiers make sense for a particular pointer
9508	type. It is used primarily to indicate that the role of null with specific
9509	pointers in a nullability-annotated header is unclear, e.g., due to
9510	overly-complex implementations or historical factors with a long-lived API.)reST";
9511
9512	static const char AttrDoc_TypeNullable[] = R"reST(The `_Nullable` nullability qualifier indicates that a value of the
9513	`_Nullable` pointer type can be null. For example, given:
9514
9515	```c
9516	int fetch_or_zero(int * _Nullable ptr);
9517	```
9518
9519	a caller of `fetch_or_zero` can provide null.
9520
9521	The `_Nullable` attribute on classes indicates that the given class can
9522	represent null values, and so the `_Nullable`, `_Nonnull` etc qualifiers
9523	make sense for this type. For example:
9524
9525	```c
9526	class _Nullable ArenaPointer { ... };
9527
9528	ArenaPointer _Nonnull x = ...;
9529	ArenaPointer _Nullable y = nullptr;
9530	```)reST";
9531
9532	static const char AttrDoc_TypeNullableResult[] = R"reST(The `_Nullable_result` nullability qualifier means that a value of the
9533	`_Nullable_result` pointer can be `nil`, just like `_Nullable`. Where this
9534	attribute differs from `_Nullable` is when it's used on a parameter to a
9535	completion handler in a Swift async method. For instance, here:
9536
9537	```objc
9538	-(void)fetchSomeDataWithID:(int)identifier
9539	completionHandler:(void (^)(Data _Nullable_result result, NSError error))completionHandler;
9540	```
9541
9542	This method asynchronously calls `completionHandler` when the data is
9543	available, or calls it with an error. `_Nullable_result` indicates to the
9544	Swift importer that this is the uncommon case where `result` can get `nil`
9545	even if no error has occurred, and will therefore import it as a Swift optional
9546	type. Otherwise, if `result` was annotated with `_Nullable`, the Swift
9547	importer will assume that `result` will always be non-nil unless an error
9548	occurred.)reST";
9549
9550	static const char AttrDoc_TypeTagForDatatype[] = R"reST(When declaring a variable, use
9551	`__attribute__((type_tag_for_datatype(kind, type)))` to create a type tag that
9552	is tied to the `type` argument given to the attribute.
9553
9554	In the attribute prototype above:
9555	: - `kind` is an identifier that should be used when annotating all applicable
9556	type tags.
9557	- `type` indicates the name of the type.
9558
9559	Clang supports annotating type tags of two forms.
9560
9561	- Type tag that is a reference to a declared identifier.
9562	Use `__attribute__((type_tag_for_datatype(kind, type)))` when declaring that
9563	identifier:
9564
9565	```c++
9566	typedef int MPI_Datatype;
9567	extern struct mpi_datatype mpi_datatype_int
9568	__attribute__(( type_tag_for_datatype(mpi,int) ));
9569	#define MPI_INT ((MPI_Datatype) &mpi_datatype_int)
9570	// &mpi_datatype_int is a type tag. It is tied to type "int".
9571	```
9572
9573	- Type tag that is an integral literal.
9574	Declare a `static const` variable with an initializer value and attach
9575	`__attribute__((type_tag_for_datatype(kind, type)))` on that declaration:
9576
9577	```c++
9578	typedef int MPI_Datatype;
9579	static const MPI_Datatype mpi_datatype_int
9580	__attribute__(( type_tag_for_datatype(mpi,int) )) = 42;
9581	#define MPI_INT ((MPI_Datatype) 42)
9582	// The number 42 is a type tag. It is tied to type "int".
9583	```
9584
9585	The `type_tag_for_datatype` attribute also accepts an optional third argument
9586	that determines how the type of the function argument specified by either
9587	`arg_idx` or `ptr_idx` is compared against the type associated with the type
9588	tag. (Recall that for the `argument_with_type_tag` attribute, the type of the
9589	function argument specified by `arg_idx` is compared against the type
9590	associated with the type tag. Also recall that for the `pointer_with_type_tag`
9591	attribute, the pointee type of the function argument specified by `ptr_idx` is
9592	compared against the type associated with the type tag.) There are two supported
9593	values for this optional third argument:
9594
9595	- `layout_compatible` will cause types to be compared according to
9596	layout-compatibility rules (In C++11 [class.mem] p 17, 18, see the
9597	layout-compatibility rules for two standard-layout struct types and for two
9598	standard-layout union types). This is useful when creating a type tag
9599	associated with a struct or union type. For example:
9600
9601	```c++
9602	/* In mpi.h */
9603	typedef int MPI_Datatype;
9604	struct internal_mpi_double_int { double d; int i; };
9605	extern struct mpi_datatype mpi_datatype_double_int
9606	__attribute__(( type_tag_for_datatype(mpi,
9607	struct internal_mpi_double_int, layout_compatible) ));
9608
9609	#define MPI_DOUBLE_INT ((MPI_Datatype) &mpi_datatype_double_int)
9610
9611	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
9612	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
9613
9614	/* In user code */
9615	struct my_pair { double a; int b; };
9616	struct my_pair *buffer;
9617	MPI_Send(buffer, 1, MPI_DOUBLE_INT /, ... /); // no warning because the
9618	// layout of my_pair is
9619	// compatible with that of
9620	// internal_mpi_double_int
9621
9622	struct my_int_pair { int a; int b; }
9623	struct my_int_pair *buffer2;
9624	MPI_Send(buffer2, 1, MPI_DOUBLE_INT /, ... /); // warning because the
9625	// layout of my_int_pair
9626	// does not match that of
9627	// internal_mpi_double_int
9628	```
9629
9630	- `must_be_null` specifies that the function argument specified by either
9631	`arg_idx` (for the `argument_with_type_tag` attribute) or `ptr_idx` (for
9632	the `pointer_with_type_tag` attribute) should be a null pointer constant.
9633	The second argument to the `type_tag_for_datatype` attribute is ignored. For
9634	example:
9635
9636	```c++
9637	/* In mpi.h */
9638	typedef int MPI_Datatype;
9639	extern struct mpi_datatype mpi_datatype_null
9640	__attribute__(( type_tag_for_datatype(mpi, void, must_be_null) ));
9641
9642	#define MPI_DATATYPE_NULL ((MPI_Datatype) &mpi_datatype_null)
9643	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
9644	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
9645
9646	/* In user code */
9647	struct my_pair { double a; int b; };
9648	struct my_pair *buffer;
9649	MPI_Send(buffer, 1, MPI_DATATYPE_NULL /, ... /); // warning: MPI_DATATYPE_NULL
9650	// was specified but buffer
9651	// is not a null pointer
9652	```)reST";
9653
9654	static const char AttrDoc_TypeVisibility[] = R"reST(The `type_visibility` attribute allows the visibility of a type and its vague
9655	linkage objects (vtable, typeinfo, typeinfo name) to be controlled separately from
9656	the visibility of functions and data members of the type.
9657
9658	For example, this can be used to give default visibility to the typeinfo and the vtable
9659	of a type while still keeping hidden visibility on its member functions and static data
9660	members.
9661
9662	This attribute can only be applied to types and namespaces.
9663
9664	If both `visibility` and `type_visibility` are applied to a type or a namespace, the
9665	visibility specified with the `type_visibility` attribute overrides the visibility
9666	provided with the regular `visibility` attribute.)reST";
9667
9668	static const char AttrDoc_UPtr[] = R"reST(The `__uptr` qualifier specifies that a 32-bit pointer should be zero
9669	extended when converted to a 64-bit pointer.)reST";
9670
9671	static const char AttrDoc_Unavailable[] = R"reST(No documentation.)reST";
9672
9673	static const char AttrDoc_Uninitialized[] = R"reST(The command-line parameter `-ftrivial-auto-var-init=*` can be used to
9674	initialize trivial automatic stack variables. By default, trivial automatic
9675	stack variables are uninitialized. This attribute is used to override the
9676	command-line parameter, forcing variables to remain uninitialized. It has no
9677	semantic meaning in that using uninitialized values is undefined behavior,
9678	it rather documents the programmer's intent.)reST";
9679
9680	static const char AttrDoc_Unlikely[] = R"reST(The `likely` and `unlikely` attributes are used as compiler hints.
9681	The attributes are used to aid the compiler to determine which branch is
9682	likely or unlikely to be taken. This is done by marking the branch substatement
9683	with one of the two attributes.
9684
9685	It isn't allowed to annotate a single statement with both `likely` and
9686	`unlikely`. Annotating the `true` and `false` branch of an `if`
9687	statement with the same likelihood attribute will result in a diagnostic and
9688	the attributes are ignored on both branches.
9689
9690	In a `switch` statement it's allowed to annotate multiple `case` labels
9691	or the `default` label with the same likelihood attribute. This makes
9692	\* all labels without an attribute have a neutral likelihood,
9693	\* all labels marked `[[likely]]` have an equally positive likelihood, and
9694	\* all labels marked `[[unlikely]]` have an equally negative likelihood.
9695	The neutral likelihood is the more likely of path execution than the negative
9696	likelihood. The positive likelihood is the more likely of path of execution
9697	than the neutral likelihood.
9698
9699	These attributes have no effect on the generated code when using
9700	PGO (Profile-Guided Optimization) or at optimization level 0.
9701
9702	In Clang, the attributes will be ignored if they're not placed on
9703	\* the `case` or `default` label of a `switch` statement,
9704	\* or on the substatement of an `if` or `else` statement,
9705	\* or on the substatement of an `for` or `while` statement.
9706	The C++ Standard recommends to honor them on every statement in the
9707	path of execution, but that can be confusing:
9708
9709	```c++
9710	if (b) {
9711	[[unlikely]] --b; // Per the standard this is in the path of
9712	// execution, so this branch should be considered
9713	// unlikely. However, Clang ignores the attribute
9714	// here since it is not on the substatement.
9715	}
9716
9717	if (b) {
9718	--b;
9719	if(b)
9720	return;
9721	[[unlikely]] --b; // Not in the path of execution,
9722	} // the branch has no likelihood information.
9723
9724	if (b) {
9725	--b;
9726	foo(b);
9727	// Whether or not the next statement is in the path of execution depends
9728	// on the declaration of foo():
9729	// In the path of execution: void foo(int);
9730	// Not in the path of execution: [[noreturn]] void foo(int);
9731	// This means the likelihood of the branch depends on the declaration
9732	// of foo().
9733	[[unlikely]] --b;
9734	}
9735	```
9736
9737	Below are some example usages of the likelihood attributes and their effects:
9738
9739	```c++
9740	if (b) [[likely]] { // Placement on the first statement in the branch.
9741	// The compiler will optimize to execute the code here.
9742	} else {
9743	}
9744
9745	if (b)
9746	[[unlikely]] b++; // Placement on the first statement in the branch.
9747	else {
9748	// The compiler will optimize to execute the code here.
9749	}
9750
9751	if (b) {
9752	[[unlikely]] b++; // Placement on the second statement in the branch.
9753	} // The attribute will be ignored.
9754
9755	if (b) [[likely]] {
9756	[[unlikely]] b++; // No contradiction since the second attribute
9757	} // is ignored.
9758
9759	if (b)
9760	;
9761	else [[likely]] {
9762	// The compiler will optimize to execute the code here.
9763	}
9764
9765	if (b)
9766	;
9767	else
9768	// The compiler will optimize to execute the next statement.
9769	[[likely]] b = f();
9770
9771	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
9772	else [[likely]]; // and the attributes are ignored.
9773
9774	if (b)
9775	[[likely]] int i = 5; // Issues a diagnostic since the attribute
9776	// isn't allowed on a declaration.
9777
9778	switch (i) {
9779	[[likely]] case 1: // This value is likely
9780	...
9781	break;
9782
9783	[[unlikely]] case 2: // This value is unlikely
9784	...
9785	[[fallthrough]];
9786
9787	case 3: // No likelihood attribute
9788	...
9789	[[likely]] break; // No effect
9790
9791	case 4: [[likely]] { // attribute on substatement has no effect
9792	...
9793	break;
9794	}
9795
9796	[[unlikely]] default: // All other values are unlikely
9797	...
9798	break;
9799	}
9800
9801	switch (i) {
9802	[[likely]] case 0: // This value and code path is likely
9803	...
9804	[[fallthrough]];
9805
9806	case 1: // No likelihood attribute, code path is neutral
9807	break; // falling through has no effect on the likelihood
9808
9809	case 2: // No likelihood attribute, code path is neutral
9810	[[fallthrough]];
9811
9812	[[unlikely]] default: // This value and code path are both unlikely
9813	break;
9814	}
9815
9816	for(int i = 0; i != size; ++i) [[likely]] {
9817	... // The loop is the likely path of execution
9818	}
9819
9820	for(const auto &E : Elements) [[likely]] {
9821	... // The loop is the likely path of execution
9822	}
9823
9824	while(i != size) [[unlikely]] {
9825	... // The loop is the unlikely path of execution
9826	} // The generated code will optimize to skip the loop body
9827
9828	while(true) [[unlikely]] {
9829	... // The attribute has no effect
9830	} // Clang elides the comparison and generates an infinite
9831	// loop
9832	```)reST";
9833
9834	static const char AttrDoc_UnsafeBufferUsage[] = R"reST(The attribute `[[clang::unsafe_buffer_usage]]` should be placed on functions
9835	that need to be avoided as they are prone to buffer overflows or unsafe buffer
9836	struct fields. It is designed to work together with the off-by-default compiler
9837	warning `-Wunsafe-buffer-usage` to help codebases transition away from raw pointer
9838	based buffer management, in favor of safer abstractions such as C++20 `std::span`.
9839	The attribute causes `-Wunsafe-buffer-usage` to warn on every use of the function or
9840	the field it is attached to, and it may also lead to emission of automatic fix-it
9841	hints which would help the user replace the use of unsafe functions(/fields) with safe
9842	alternatives, though the attribute can be used even when the fix can't be automated.
9843
9844	- Attribute attached to functions: The attribute suppresses all
9845	`-Wunsafe-buffer-usage` warnings within the function it is attached to, as the
9846	function is now classified as unsafe. The attribute should be used carefully, as it
9847	will silence all unsafe operation warnings inside the function; including any new
9848	unsafe operations introduced in the future.
9849
9850	The attribute is warranted even if the only way a function can overflow
9851	the buffer is by violating the function's preconditions. For example, it
9852	would make sense to put the attribute on function `foo()` below because
9853	passing an incorrect size parameter would cause a buffer overflow:
9854
9855	```c++
9856	[[clang::unsafe_buffer_usage]]
9857	void foo(int *buf, size_t size) {
9858	for (size_t i = 0; i < size; ++i) {
9859	buf[i] = i;
9860	}
9861	}
9862	```
9863
9864	The attribute is NOT warranted when the function uses safe abstractions,
9865	assuming that these abstractions weren't misused outside the function.
9866	For example, function `bar()` below doesn't need the attribute,
9867	because assuming that the container `buf` is well-formed (has size that
9868	fits the original buffer it refers to), overflow cannot occur:
9869
9870	```c++
9871	void bar(std::span<int> buf) {
9872	for (size_t i = 0; i < buf.size(); ++i) {
9873	buf[i] = i;
9874	}
9875	}
9876	```
9877
9878	In this case function `bar()` enables the user to keep the buffer
9879	"containerized" in a span for as long as possible. On the other hand,
9880	Function `foo()` in the previous example may have internal
9881	consistency, but by accepting a raw buffer it requires the user to unwrap
9882	their span, which is undesirable according to the programming model
9883	behind `-Wunsafe-buffer-usage`.
9884
9885	The attribute is warranted when a function accepts a raw buffer only to
9886	immediately put it into a span:
9887
9888	```c++
9889	[[clang::unsafe_buffer_usage]]
9890	void baz(int *buf, size_t size) {
9891	std::span<int> sp{ buf, size };
9892	for (size_t i = 0; i < sp.size(); ++i) {
9893	sp[i] = i;
9894	}
9895	}
9896	```
9897
9898	In this case `baz()` does not contain any unsafe operations, but the awkward
9899	parameter type causes the caller to unwrap the span unnecessarily.
9900	Note that regardless of the attribute, code inside `baz()` isn't flagged
9901	by `-Wunsafe-buffer-usage` as unsafe. It is definitely undesirable,
9902	but if `baz()` is on an API surface, there is no way to improve it
9903	to make it as safe as `bar()` without breaking the source and binary
9904	compatibility with existing users of the function. In such cases
9905	the proper solution would be to create a different function (possibly
9906	an overload of `baz()`) that accepts a safe container like `bar()`,
9907	and then use the attribute on the original `baz()` to help the users
9908	update their code to use the new function.
9909
9910	- Attribute attached to fields: The attribute should only be attached to
9911	struct fields, if the fields can not be updated to a safe type with bounds
9912	check, such as std::span. In other words, the buffers prone to unsafe accesses
9913	should always be updated to use safe containers/views and attaching the attribute
9914	must be last resort when such an update is infeasible.
9915
9916	The attribute can be placed on individual fields or a set of them as shown below.
9917
9918	```c++
9919	struct A {
9920	[[clang::unsafe_buffer_usage]]
9921	int *ptr1;
9922
9923	[[clang::unsafe_buffer_usage]]
9924	int *ptr2, buf[10];
9925
9926	[[clang::unsafe_buffer_usage]]
9927	size_t sz;
9928	};
9929	```
9930
9931	Here, every read/write to the fields ptr1, ptr2, buf and sz will trigger a warning
9932	that the field has been explcitly marked as unsafe due to unsafe-buffer operations.)reST";
9933
9934	static const char AttrDoc_Unused[] = R"reST(When passing the `-Wunused` flag to Clang, entities that are unused by the
9935	program may be diagnosed. The `[[maybe_unused]]` (or
9936	`__attribute__((unused))`) attribute can be used to silence such diagnostics
9937	when the entity cannot be removed. For instance, a local variable may exist
9938	solely for use in an `assert()` statement, which makes the local variable
9939	unused when `NDEBUG` is defined.
9940
9941	The attribute may be applied to the declaration of a class, a typedef, a
9942	variable, a function or method, a function parameter, an enumeration, an
9943	enumerator, a non-static data member, or a label.
9944
9945	```c++
9946	#include <cassert>
9947
9948	[[maybe_unused]] void f([[maybe_unused]] bool thing1,
9949	[[maybe_unused]] bool thing2) {
9950	[[maybe_unused]] bool b = thing1 && thing2;
9951	assert(b);
9952	}
9953	```)reST";
9954
9955	static const char AttrDoc_UseHandle[] = R"reST(A function taking a handle by value might close the handle. If a function
9956	parameter is annotated with `use_handle(tag)` it is assumed to not to change
9957	the state of the handle. It is also assumed to require an open handle to work with.
9958	The attribute requires a string literal argument to identify the handle being used.
9959
9960	```c++
9961	zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle("zircon")]],
9962	zx_time_t deadline,
9963	zx_port_packet_t* packet);
9964	```)reST";
9965
9966	static const char AttrDoc_Used[] = R"reST(This attribute, when attached to a function or variable definition, indicates
9967	that there may be references to the entity which are not apparent in the source
9968	code. For example, it may be referenced from inline `asm`, or it may be
9969	found through a dynamic symbol or section lookup.
9970
9971	The compiler must emit the definition even if it appears to be unused, and it
9972	must not apply optimizations which depend on fully understanding how the entity
9973	is used.
9974
9975	Whether this attribute has any effect on the linker depends on the target and
9976	the linker. Most linkers support the feature of section garbage collection
9977	(`--gc-sections`), also known as "dead stripping" (`ld64 -dead_strip`) or
9978	discarding unreferenced sections (`link.exe /OPT:REF`). On COFF and Mach-O
9979	targets (Windows and Apple platforms), the `used` attribute prevents symbols
9980	from being removed by linker section GC. On ELF targets, it has no effect on its
9981	own, and the linker may remove the definition if it is not otherwise referenced.
9982	This linker GC can be avoided by also adding the `retain` attribute. Note
9983	that `retain` requires special support from the linker; see that attribute's
9984	documentation for further information.)reST";
9985
9986	static const char AttrDoc_UsingIfExists[] = R"reST(The `using_if_exists` attribute applies to a using-declaration. It allows
9987	programmers to import a declaration that potentially does not exist, instead
9988	deferring any errors to the point of use. For instance:
9989
9990	```c++
9991	namespace empty_namespace {};
9992	__attribute__((using_if_exists))
9993	using empty_namespace::does_not_exist; // no error!
9994
9995	does_not_exist x; // error: use of unresolved 'using_if_exists'
9996	```
9997
9998	The C++ spelling of the attribute (`[[clang::using_if_exists]]`) is also
9999	supported as a clang extension, since ISO C++ doesn't support attributes in this
10000	position. If the entity referred to by the using-declaration is found by name
10001	lookup, the attribute has no effect. This attribute is useful for libraries
10002	(primarily, libc++) that wish to redeclare a set of declarations in another
10003	namespace, when the availability of those declarations is difficult or
10004	impossible to detect at compile time with the preprocessor.)reST";
10005
10006	static const char AttrDoc_Uuid[] = R"reST(No documentation.)reST";
10007
10008	static const char AttrDoc_VTablePointerAuthentication[] = R"reST(No documentation.)reST";
10009
10010	static const char AttrDoc_VecReturn[] = R"reST(No documentation.)reST";
10011
10012	static const char AttrDoc_VecTypeHint[] = R"reST(No documentation.)reST";
10013
10014	static const char AttrDoc_VectorCall[] = R"reST(On 32-bit x86 and x86_64 targets, this attribute changes the calling
10015	convention of a function to pass vector parameters in SSE registers.
10016
10017	On 32-bit x86 targets, this calling convention is similar to `__fastcall`.
10018	The first two integer parameters are passed in ECX and EDX. Subsequent integer
10019	parameters are passed in memory, and callee clears the stack. On x86_64
10020	targets, the callee does not clear the stack, and integer parameters are
10021	passed in RCX, RDX, R8, and R9 as is done for the default Windows x64 calling
10022	convention.
10023
10024	On both 32-bit x86 and x86_64 targets, vector and floating point arguments are
10025	passed in XMM0-XMM5. Homogeneous vector aggregates of up to four elements are
10026	passed in sequential SSE registers if enough are available. If AVX is enabled,
10027	256 bit vectors are passed in YMM0-YMM5. Any vector or aggregate type that
10028	cannot be passed in registers for any reason is passed by reference, which
10029	allows the caller to align the parameter memory.
10030
10031	See the documentation for [\_\_vectorcall][__vectorcall] on MSDN for more details.
10032
10033	[__vectorcall]: http://msdn.microsoft.com/en-us/library/dn375768.aspx)reST";
10034
10035	static const char AttrDoc_Visibility[] = R"reST(No documentation.)reST";
10036
10037	static const char AttrDoc_WarnUnused[] = R"reST(The `warn_unused` attribute can be placed on the declaration of a structure or union type.
10038	When the `-Wunused-variable` diagnostic is enabled, local variables of types which have a non-trivial constructor or destructor are considered "used" by virtue of the constructor or destructor invocations involved.
10039	Those constructor or destructor invocations are not considered a use if the type is declared with the `warn_unused` attribute.
10040	The variable is considered used if it is named outside of its declaration.
10041
10042	This attribute is available in both C and C++ language modes but is primarily useful in C++ for classes which have a non-trivial constructor or destructor but act as a value type rather than an RAII type.
10043
10044	```c++
10045	struct [[gnu::warn_unused]] S {
10046	S();
10047	~S();
10048	};
10049
10050	struct T {
10051	T();
10052	~T();
10053	};
10054
10055	int func() {
10056	S s1; // -Wunused-variable warning
10057	S s2; // No -Wunused-variable warning because of the member access expression below
10058	S s3; // No -Wunused-variable warning because of the sizeof operand below
10059	T t; // No -Wunused-variable warning
10060
10061	s2.~S();
10062	return sizeof(s3);
10063	}
10064	```)reST";
10065
10066	static const char AttrDoc_WarnUnusedResult[] = R"reST(Clang supports the ability to diagnose when the results of a function call
10067	expression are discarded under suspicious circumstances. A diagnostic is
10068	generated when a function or its return type is marked with `[[nodiscard]]`
10069	(or `__attribute__((warn_unused_result))`) and the function call appears as a
10070	potentially-evaluated discarded-value expression that is not explicitly cast to
10071	`void`.
10072
10073	A string literal may optionally be provided to the attribute, which will be
10074	reproduced in any resulting diagnostics. Redeclarations using different forms
10075	of the attribute (with or without the string literal or with different string
10076	literal contents) are allowed. If there are redeclarations of the entity with
10077	differing string literals, it is unspecified which one will be used by Clang
10078	in any resulting diagnostics.
10079
10080	```c++
10081	struct [[nodiscard]] error_info { /.../ };
10082	error_info enable_missile_safety_mode();
10083
10084	void launch_missiles();
10085	void test_missiles() {
10086	enable_missile_safety_mode(); // diagnoses
10087	launch_missiles();
10088	}
10089	error_info &foo();
10090	void f() { foo(); } // Does not diagnose, error_info is a reference.
10091	```
10092
10093	Additionally, discarded temporaries resulting from a call to a constructor
10094	marked with `[[nodiscard]]` or a constructor of a type marked
10095	`[[nodiscard]]` will also diagnose. This also applies to type conversions that
10096	use the annotated `[[nodiscard]]` constructor or result in an annotated type.
10097
10098	```c++
10099	struct [[nodiscard]] marked_type {/../ };
10100	struct marked_ctor {
10101	[[nodiscard]] marked_ctor();
10102	marked_ctor(int);
10103	};
10104
10105	struct S {
10106	operator marked_type() const;
10107	[[nodiscard]] operator int() const;
10108	};
10109
10110	void usages() {
10111	marked_type(); // diagnoses.
10112	marked_ctor(); // diagnoses.
10113	marked_ctor(3); // Does not diagnose, int constructor isn't marked nodiscard.
10114
10115	S s;
10116	static_cast<marked_type>(s); // diagnoses
10117	(int)s; // diagnoses
10118	}
10119	```)reST";
10120
10121	static const char AttrDoc_Weak[] = R"reST(In supported output formats the `weak` attribute can be used to
10122	specify that a variable or function should be emitted as a symbol with
10123	`weak` (if a definition) or `extern_weak` (if a declaration of an
10124	external symbol) [linkage](https://llvm.org/docs/LangRef.html#linkage-types).
10125
10126	If there is a non-weak definition of the symbol the linker will select
10127	that over the weak. They must have same type and alignment (variables
10128	must also have the same size), but may have a different value.
10129
10130	If there are multiple weak definitions of same symbol, but no non-weak
10131	definition, they should have same type, size, alignment and value, the
10132	linker will select one of them (see also [selectany] attribute).
10133
10134	If the `weak` attribute is applied to a `const` qualified variable
10135	definition that variable is no longer consider a compiletime constant
10136	as its value can change during linking (or dynamic linking). This
10137	means that it can e.g no longer be part of an initializer expression.
10138
10139	```c
10140	const int ANSWER __attribute__ ((weak)) = 42;
10141
10142	/* This function may be replaced link-time */
10143	__attribute__ ((weak)) void debug_log(const char *msg)
10144	{
10145	fprintf(stderr, "DEBUG: %s\n", msg);
10146	}
10147
10148	int main(int argc, const char **argv)
10149	{
10150	debug_log ("Starting up...");
10151
10152	/* This may print something else than "6 * 7 = 42",
10153	if there is a non-weak definition of "ANSWER" in
10154	an object linked in */
10155	printf("6 * 7 = %d\n", ANSWER);
10156
10157	return 0;
10158	}
10159	```
10160
10161	If an external declaration is marked weak and that symbol does not
10162	exist during linking (possibly dynamic) the address of the symbol will
10163	evaluate to NULL.
10164
10165	```c
10166	void may_not_exist(void) __attribute__ ((weak));
10167
10168	int main(int argc, const char **argv)
10169	{
10170	if (may_not_exist) {
10171	may_not_exist();
10172	} else {
10173	printf("Function did not exist\n");
10174	}
10175	return 0;
10176	}
10177	```)reST";
10178
10179	static const char AttrDoc_WeakImport[] = R"reST(No documentation.)reST";
10180
10181	static const char AttrDoc_WeakRef[] = R"reST(No documentation.)reST";
10182
10183	static const char AttrDoc_WebAssemblyExportName[] = R"reST(Clang supports the `__attribute__((export_name(<name>)))`
10184	attribute for the WebAssembly target. This attribute may be attached to a
10185	function declaration, where it modifies how the symbol is to be exported
10186	from the linked WebAssembly.
10187
10188	WebAssembly functions are exported via string name. By default when a symbol
10189	is exported, the export name for C/C++ symbols are the same as their C/C++
10190	symbol names. This attribute can be used to override the default behavior, and
10191	request a specific string name be used instead.)reST";
10192
10193	static const char AttrDoc_WebAssemblyFuncref[] = R"reST(Clang supports the `__attribute__((export_name(<name>)))`
10194	attribute for the WebAssembly target. This attribute may be attached to a
10195	function declaration, where it modifies how the symbol is to be exported
10196	from the linked WebAssembly.
10197
10198	WebAssembly functions are exported via string name. By default when a symbol
10199	is exported, the export name for C/C++ symbols are the same as their C/C++
10200	symbol names. This attribute can be used to override the default behavior, and
10201	request a specific string name be used instead.)reST";
10202
10203	static const char AttrDoc_WebAssemblyImportModule[] = R"reST(Clang supports the `__attribute__((import_module(<module_name>)))`
10204	attribute for the WebAssembly target. This attribute may be attached to a
10205	function declaration, where it modifies how the symbol is to be imported
10206	within the WebAssembly linking environment.
10207
10208	WebAssembly imports use a two-level namespace scheme, consisting of a module
10209	name, which typically identifies a module from which to import, and a field
10210	name, which typically identifies a field from that module to import. By
10211	default, module names for C/C++ symbols are assigned automatically by the
10212	linker. This attribute can be used to override the default behavior, and
10213	request a specific module name be used instead.)reST";
10214
10215	static const char AttrDoc_WebAssemblyImportName[] = R"reST(Clang supports the `__attribute__((import_name(<name>)))`
10216	attribute for the WebAssembly target. This attribute may be attached to a
10217	function declaration, where it modifies how the symbol is to be imported
10218	within the WebAssembly linking environment.
10219
10220	WebAssembly imports use a two-level namespace scheme, consisting of a module
10221	name, which typically identifies a module from which to import, and a field
10222	name, which typically identifies a field from that module to import. By
10223	default, field names for C/C++ symbols are the same as their C/C++ symbol
10224	names. This attribute can be used to override the default behavior, and
10225	request a specific field name be used instead.)reST";
10226
10227	static const char AttrDoc_WorkGroupSizeHint[] = R"reST(No documentation.)reST";
10228
10229	static const char AttrDoc_X86ForceAlignArgPointer[] = R"reST(Use this attribute to force stack alignment.
10230
10231	Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
10232	(like 'movaps') that work with the stack require operands to be 16-byte aligned.
10233	This attribute realigns the stack in the function prologue to make sure the
10234	stack can be used with SSE instructions.
10235
10236	Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
10237	Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
10238	rare cases where the caller does not align the stack properly (e.g. flow
10239	jumps from i386 arch code).
10240
10241	```c
10242	__attribute__ ((force_align_arg_pointer))
10243	void f () {
10244	...
10245	}
10246	```)reST";
10247
10248	static const char AttrDoc_XRayInstrument[] = R"reST(`__attribute__((xray_always_instrument))` or
10249	`[[clang::xray_always_instrument]]` is used to mark member functions (in C++),
10250	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
10251	instrumented with XRay. This will cause the function to always have space at
10252	the beginning and exit points to allow for runtime patching.
10253
10254	Conversely, `__attribute__((xray_never_instrument))` or
10255	`[[clang::xray_never_instrument]]` will inhibit the insertion of these
10256	instrumentation points.
10257
10258	If a function has neither of these attributes, they become subject to the XRay
10259	heuristics used to determine whether a function should be instrumented or
10260	otherwise.
10261
10262	`__attribute__((xray_log_args(N)))` or `[[clang::xray_log_args(N)]]` is
10263	used to preserve N function arguments for the logging function. Currently,
10264	only N==1 is supported.)reST";
10265
10266	static const char AttrDoc_XRayLogArgs[] = R"reST(`__attribute__((xray_always_instrument))` or
10267	`[[clang::xray_always_instrument]]` is used to mark member functions (in C++),
10268	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
10269	instrumented with XRay. This will cause the function to always have space at
10270	the beginning and exit points to allow for runtime patching.
10271
10272	Conversely, `__attribute__((xray_never_instrument))` or
10273	`[[clang::xray_never_instrument]]` will inhibit the insertion of these
10274	instrumentation points.
10275
10276	If a function has neither of these attributes, they become subject to the XRay
10277	heuristics used to determine whether a function should be instrumented or
10278	otherwise.
10279
10280	`__attribute__((xray_log_args(N)))` or `[[clang::xray_log_args(N)]]` is
10281	used to preserve N function arguments for the logging function. Currently,
10282	only N==1 is supported.)reST";
10283
10284	static const char AttrDoc_ZeroCallUsedRegs[] = R"reST(This attribute, when attached to a function, causes the compiler to zero a
10285	subset of all call-used registers before the function returns. It's used to
10286	increase program security by either mitigating [Return-Oriented Programming][return-oriented programming]
10287	(ROP) attacks or preventing information leakage through registers.
10288
10289	The term "call-used" means registers which are not guaranteed to be preserved
10290	unchanged for the caller by the current calling convention. This could also be
10291	described as "caller-saved" or "not callee-saved".
10292
10293	The `choice` parameters gives the programmer flexibility to choose the subset
10294	of the call-used registers to be zeroed:
10295
10296	- `skip` doesn't zero any call-used registers. This choice overrides any
10297	command-line arguments.
10298	- `used` only zeros call-used registers used in the function. By `used`, we
10299	mean a register whose contents have been set or referenced in the function.
10300	- `used-gpr` only zeros call-used GPR registers used in the function.
10301	- `used-arg` only zeros call-used registers used to pass arguments to the
10302	function.
10303	- `used-gpr-arg` only zeros call-used GPR registers used to pass arguments to
10304	the function.
10305	- `all` zeros all call-used registers.
10306	- `all-gpr` zeros all call-used GPR registers.
10307	- `all-arg` zeros all call-used registers used to pass arguments to the
10308	function.
10309	- `all-gpr-arg` zeros all call-used GPR registers used to pass arguments to
10310	the function.
10311
10312	The default for the attribute is controlled by the `-fzero-call-used-regs`
10313	flag.
10314
10315	[return-oriented programming]: https://en.wikipedia.org/wiki/Return-oriented_programming)reST";
10316

Browse the source code of llvm_projects/build/tools/clang/lib/AST/AttrDocTable.inc