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`_ 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_AMDGPUFlatWorkGroupSize[] = R"reST(The flat work-group size is the number of work-items in the work-group size
53	specified when the kernel is dispatched. It is the product of the sizes of the
54	x, y, and z dimension of the work-group.
55
56	Clang supports the
57	``__attribute__((amdgpu_flat_work_group_size(<min>, <max>)))`` attribute for the
58	AMDGPU target. This attribute may be attached to a kernel function definition
59	and is an optimization hint.
60
61	``<min>`` parameter specifies the minimum flat work-group size, and ``<max>``
62	parameter specifies the maximum flat work-group size (must be greater than
63	``<min>``) to which all dispatches of the kernel will conform. Passing ``0, 0``
64	as ``<min>, <max>`` implies the default behavior (``128, 256``).
65
66	If specified, the AMDGPU target backend might be able to produce better machine
67	code for barriers and perform scratch promotion by estimating available group
68	segment size.
69
70	An error will be given if:
71	- Specified values violate subtarget specifications;
72	- Specified values are not compatible with values provided through other
73	attributes.)reST";
74
75	static const char AttrDoc_AMDGPUMaxNumWorkGroups[] = R"reST(This attribute specifies the max number of work groups when the kernel
76	is dispatched.
77
78	Clang supports the
79	``__attribute__((amdgpu_max_num_work_groups(<x>, <y>, <z>)))`` or
80	``[[clang::amdgpu_max_num_work_groups(<x>, <y>, <z>)]]`` attribute for the
81	AMDGPU target. This attribute may be attached to HIP or OpenCL kernel function
82	definitions and is an optimization hint.
83
84	The ``<x>`` parameter specifies the maximum number of work groups in the x dimension.
85	Similarly ``<y>`` and ``<z>`` are for the y and z dimensions respectively.
86	Each of the three values must be greater than 0 when provided. The ``<x>`` parameter
87	is required, while ``<y>`` and ``<z>`` are optional with default value of 1.
88
89	If specified, the AMDGPU target backend might be able to produce better machine
90	code.
91
92	An error will be given if:
93	- Specified values violate subtarget specifications;
94	- Specified values are not compatible with values provided through other
95	attributes.)reST";
96
97	static const char AttrDoc_AMDGPUNumSGPR[] = R"reST(Clang supports the ``__attribute__((amdgpu_num_sgpr(<num_sgpr>)))`` and
98	``__attribute__((amdgpu_num_vgpr(<num_vgpr>)))`` attributes for the AMDGPU
99	target. These attributes may be attached to a kernel function definition and are
100	an optimization hint.
101
102	If these attributes are specified, then the AMDGPU target backend will attempt
103	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
104	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
105	allocation requirements or constraints of the subtarget. Passing ``0`` as
106	``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits).
107
108	These attributes can be used to test the AMDGPU target backend. It is
109	recommended that the ``amdgpu_waves_per_eu`` attribute be used to control
110	resources such as SGPRs and VGPRs since it is aware of the limits for different
111	subtargets.
112
113	An error will be given if:
114	- Specified values violate subtarget specifications;
115	- Specified values are not compatible with values provided through other
116	attributes;
117	- The AMDGPU target backend is unable to create machine code that can meet the
118	request.)reST";
119
120	static const char AttrDoc_AMDGPUNumVGPR[] = R"reST(Clang supports the ``__attribute__((amdgpu_num_sgpr(<num_sgpr>)))`` and
121	``__attribute__((amdgpu_num_vgpr(<num_vgpr>)))`` attributes for the AMDGPU
122	target. These attributes may be attached to a kernel function definition and are
123	an optimization hint.
124
125	If these attributes are specified, then the AMDGPU target backend will attempt
126	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
127	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
128	allocation requirements or constraints of the subtarget. Passing ``0`` as
129	``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits).
130
131	These attributes can be used to test the AMDGPU target backend. It is
132	recommended that the ``amdgpu_waves_per_eu`` attribute be used to control
133	resources such as SGPRs and VGPRs since it is aware of the limits for different
134	subtargets.
135
136	An error will be given if:
137	- Specified values violate subtarget specifications;
138	- Specified values are not compatible with values provided through other
139	attributes;
140	- The AMDGPU target backend is unable to create machine code that can meet the
141	request.)reST";
142
143	static const char AttrDoc_AMDGPUWavesPerEU[] = R"reST(A compute unit (CU) is responsible for executing the wavefronts of a work-group.
144	It is composed of one or more execution units (EU), which are responsible for
145	executing the wavefronts. An EU can have enough resources to maintain the state
146	of more than one executing wavefront. This allows an EU to hide latency by
147	switching between wavefronts in a similar way to symmetric multithreading on a
148	CPU. In order to allow the state for multiple wavefronts to fit on an EU, the
149	resources used by a single wavefront have to be limited. For example, the number
150	of SGPRs and VGPRs. Limiting such resources can allow greater latency hiding,
151	but can result in having to spill some register state to memory.
152
153	Clang supports the ``__attribute__((amdgpu_waves_per_eu(<min>[, <max>])))``
154	attribute for the AMDGPU target. This attribute may be attached to a kernel
155	function definition and is an optimization hint.
156
157	``<min>`` parameter specifies the requested minimum number of waves per EU, and
158	optional ``<max>`` parameter specifies the requested maximum number of waves
159	per EU (must be greater than ``<min>`` if specified). If ``<max>`` is omitted,
160	then there is no restriction on the maximum number of waves per EU other than
161	the one dictated by the hardware for which the kernel is compiled. Passing
162	``0, 0`` as ``<min>, <max>`` implies the default behavior (no limits).
163
164	If specified, this attribute allows an advanced developer to tune the number of
165	wavefronts that are capable of fitting within the resources of an EU. The AMDGPU
166	target backend can use this information to limit resources, such as number of
167	SGPRs, number of VGPRs, size of available group and private memory segments, in
168	such a way that guarantees that at least ``<min>`` wavefronts and at most
169	``<max>`` wavefronts are able to fit within the resources of an EU. Requesting
170	more wavefronts can hide memory latency but limits available registers which
171	can result in spilling. Requesting fewer wavefronts can help reduce cache
172	thrashing, but can reduce memory latency hiding.
173
174	This attribute controls the machine code generated by the AMDGPU target backend
175	to ensure it is capable of meeting the requested values. However, when the
176	kernel is executed, there may be other reasons that prevent meeting the request,
177	for example, there may be wavefronts from other kernels executing on the EU.
178
179	An error will be given if:
180	- Specified values violate subtarget specifications;
181	- Specified values are not compatible with values provided through other
182	attributes;
183
184	The AMDGPU target backend will emit a warning whenever it is unable to
185	create machine code that meets the request.)reST";
186
187	static const char AttrDoc_ARMInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt("TYPE")))`` attribute on
188	ARM targets. This attribute may be attached to a function definition and
189	instructs the backend to generate appropriate function entry/exit code so that
190	it can be used directly as an interrupt service routine.
191
192	The parameter passed to the interrupt attribute is optional, but if
193	provided it must be a string literal with one of the following values: "IRQ",
194	"FIQ", "SWI", "ABORT", "UNDEF".
195
196	The semantics are as follows:
197
198	- If the function is AAPCS, Clang instructs the backend to realign the stack to
199	8 bytes on entry. This is a general requirement of the AAPCS at public
200	interfaces, but may not hold when an exception is taken. Doing this allows
201	other AAPCS functions to be called.
202	- If the CPU is M-class this is all that needs to be done since the architecture
203	itself is designed in such a way that functions obeying the normal AAPCS ABI
204	constraints are valid exception handlers.
205	- If the CPU is not M-class, the prologue and epilogue are modified to save all
206	non-banked registers that are used, so that upon return the user-mode state
207	will not be corrupted. Note that to avoid unnecessary overhead, only
208	general-purpose (integer) registers are saved in this way. If VFP operations
209	are needed, that state must be saved manually.
210
211	Specifically, interrupt kinds other than "FIQ" will save all core registers
212	except "lr" and "sp". "FIQ" interrupts will save r0-r7.
213	- If the CPU is not M-class, the return instruction is changed to one of the
214	canonical sequences permitted by the architecture for exception return. Where
215	possible the function itself will make the necessary "lr" adjustments so that
216	the "preferred return address" is selected.
217
218	Unfortunately the compiler is unable to make this guarantee for an "UNDEF"
219	handler, where the offset from "lr" to the preferred return address depends on
220	the execution state of the code which generated the exception. In this case
221	a sequence equivalent to "movs pc, lr" will be used.)reST";
222
223	static const char AttrDoc_ARMInterruptSaveFP[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt_save_fp("TYPE")))``
224	on ARM targets. This attribute behaves the same way as the ARM interrupt
225	attribute, except the general purpose floating point registers are also saved,
226	along with FPEXC and FPSCR. Note, even on M-class CPUs, where the floating
227	point context can be automatically saved depending on the FPCCR, the general
228	purpose floating point registers will be saved.)reST";
229
230	static const char AttrDoc_ARMSaveFP[] = R"reST()reST";
231
232	static const char AttrDoc_AVRInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on
233	AVR targets. This attribute may be attached to a function definition and instructs
234	the backend to generate appropriate function entry/exit code so that it can be used
235	directly as an interrupt service routine.
236
237	On the AVR, the hardware globally disables interrupts when an interrupt is executed.
238	The first instruction of an interrupt handler declared with this attribute is a SEI
239	instruction to re-enable interrupts. See also the signal attribute that
240	does not insert a SEI instruction.)reST";
241
242	static const char AttrDoc_AVRSignal[] = R"reST(Clang supports the GNU style ``__attribute__((signal))`` attribute on
243	AVR targets. This attribute may be attached to a function definition and instructs
244	the backend to generate appropriate function entry/exit code so that it can be used
245	directly as an interrupt service routine.
246
247	Interrupt handler functions defined with the signal attribute do not re-enable interrupts.)reST";
248
249	static const char AttrDoc_AbiTag[] = R"reST(The ``abi_tag`` attribute can be applied to a function, variable, class or
250	inline namespace declaration to modify the mangled name of the entity. It gives
251	the ability to distinguish between different versions of the same entity but
252	with different ABI versions supported. For example, a newer version of a class
253	could have a different set of data members and thus have a different size. Using
254	the ``abi_tag`` attribute, it is possible to have different mangled names for
255	a global variable of the class type. Therefore, the old code could keep using
256	the old mangled name and the new code will use the new mangled name with tags.)reST";
257
258	static const char AttrDoc_AcquireCapability[] = R"reST(Marks a function as acquiring a capability.)reST";
259
260	static const char AttrDoc_AcquireHandle[] = R"reST(If this annotation is on a function or a function type it is assumed to return
261	a new handle. In case this annotation is on an output parameter,
262	the function is assumed to fill the corresponding argument with a new
263	handle. The attribute requires a string literal argument which used to
264	identify the handle with later uses of ``use_handle`` or
265	``release_handle``.
266
267	.. code-block:: c++
268
269	// Output arguments from Zircon.
270	zx_status_t zx_socket_create(uint32_t options,
271	zx_handle_t __attribute__((acquire_handle("zircon"))) * out0,
272	zx_handle_t* out1 [[clang::acquire_handle("zircon")]]);
273
274
275	// Returned handle.
276	[[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
277	int open(const char *path, int oflag, ... ) __attribute__((acquire_handle("tag")));)reST";
278
279	static const char AttrDoc_AcquiredAfter[] = R"reST(No documentation.)reST";
280
281	static const char AttrDoc_AcquiredBefore[] = R"reST(No documentation.)reST";
282
283	static const char AttrDoc_AddressSpace[] = R"reST(.. Note:: This attribute is mainly intended to be used by target headers
284	provided by the toolchain. End users should prefer the documented, named
285	address space annotations for their platform, such as the
286	`OpenCL address spaces`_, ``__global__``, ``__local__``, or something else.
287
288	The ``address_space`` attribute functions as a type qualifier that allows the
289	programmer to specify the address space for a pointer or reference type.
290	Qualified pointer types are considered distinct types for the purposes of
291	overload resolution. The attribute takes a single, non-negative integer
292	constant expression identifying the address space. For example:
293
294	.. code-block:: c
295
296	int * __attribute__((address_space(1))) ptr;
297
298	void foo(__attribute__((address_space(2))) float *buf);
299
300
301	Only one address space qualifier may be applied to a given pointer or reference
302	type. Where address spaces are allowed (e.g., variables, parameters, return
303	types) and what values are valid depends on the target and language mode.
304
305	The meaning of each value is defined by the target; multiple address spaces are
306	used in environments such as OpenCL, CUDA, HIP, and other GPU programming
307	models to distinguish global, local, constant, and private memory. See for
308	example the address spaces defined in the `NVPTX Usage Guide`_ and the
309	`AMDGPU Usage Guide`_.
310
311	.. _`NVPTX Usage Guide`: https://llvm.org/docs/NVPTXUsage.html#address-spaces
312	.. _`AMDGPU Usage Guide`: https://llvm.org/docs/AMDGPUUsage.html#address-spaces
313
314	Address spaces may partially overlap or be entirely distinct. The compiler may
315	reject attempts to convert between distinct, incompatible address spaces.
316	Pointer width may vary between different address spaces, so some explicit casts
317	may truncate.
318
319	For more information, refer to `ISO TR18037`_, which covers embedded C language
320	extensions. Section 5 covers named address spaces.
321
322	.. _`ISO TR18037`: https://standards.iso.org/ittf/PubliclyAvailableStandards/c051126_ISO_IEC_TR_18037_2008.zip)reST";
323
324	static const char AttrDoc_Alias[] = R"reST(No documentation.)reST";
325
326	static const char AttrDoc_AlignMac68k[] = R"reST()reST";
327
328	static const char AttrDoc_AlignNatural[] = R"reST()reST";
329
330	static const char AttrDoc_AlignValue[] = R"reST(The align_value attribute can be added to the typedef of a pointer type or the
331	declaration of a variable of pointer or reference type. It specifies that the
332	pointer will point to, or the reference will bind to, only objects with at
333	least the provided alignment. This alignment value must be some positive power
334	of 2.
335
336	.. code-block:: c
337
338	typedef double * aligned_double_ptr __attribute__((align_value(64)));
339	void foo(double & x __attribute__((align_value(128))),
340	aligned_double_ptr y) { ... }
341
342	If the pointer value does not have the specified alignment at runtime, the
343	behavior of the program is undefined.)reST";
344
345	static const char AttrDoc_Aligned[] = R"reST(No documentation.)reST";
346
347	static const char AttrDoc_AllocAlign[] = R"reST(Use ``__attribute__((alloc_align(<alignment>))`` on a function
348	declaration to specify that the return value of the function (which must be a
349	pointer type) is at least as aligned as the value of the indicated parameter. The
350	parameter is given by its index in the list of formal parameters; the first
351	parameter has index 1 unless the function is a C++ non-static member function,
352	in which case the first parameter has index 2 to account for the implicit ``this``
353	parameter.
354
355	.. code-block:: c++
356
357	// The returned pointer has the alignment specified by the first parameter.
358	void *a(size_t align) __attribute__((alloc_align(1)));
359
360	// The returned pointer has the alignment specified by the second parameter.
361	void b(void v, size_t align) __attribute__((alloc_align(2)));
362
363	// The returned pointer has the alignment specified by the second visible
364	// parameter, however it must be adjusted for the implicit 'this' parameter.
365	void Foo::b(void v, size_t align) __attribute__((alloc_align(3)));
366
367	Note that this attribute merely informs the compiler that a function always
368	returns a sufficiently aligned pointer. It does not cause the compiler to
369	emit code to enforce that alignment. The behavior is undefined if the returned
370	pointer is not sufficiently aligned.)reST";
371
372	static const char AttrDoc_AllocSize[] = R"reST(The ``alloc_size`` attribute can be placed on functions that return pointers in
373	order to hint to the compiler how many bytes of memory will be available at the
374	returned pointer. ``alloc_size`` takes one or two arguments.
375
376	- ``alloc_size(N)`` implies that argument number N equals the number of
377	available bytes at the returned pointer.
378	- ``alloc_size(N, M)`` implies that the product of argument number N and
379	argument number M equals the number of available bytes at the returned
380	pointer.
381
382	Argument numbers are 1-based.
383
384	An example of how to use ``alloc_size``
385
386	.. code-block:: c
387
388	void *my_malloc(int a) __attribute__((alloc_size(1)));
389	void *my_calloc(int a, int b) __attribute__((alloc_size(1, 2)));
390
391	int main() {
392	void *const p = my_malloc(100);
393	assert(__builtin_object_size(p, 0) == 100);
394	void *const a = my_calloc(20, 5);
395	assert(__builtin_object_size(a, 0) == 100);
396	}
397
398	When ``-Walloc-size`` is enabled, this attribute allows the compiler to
399	diagnose cases when the allocated memory is insufficient for the size of the
400	type the returned pointer is cast to.
401
402	.. code-block:: c
403
404	void *my_malloc(int a) __attribute__((alloc_size(1)));
405	void consumer_func(int *);
406
407	int main() {
408	int *ptr = my_malloc(sizeof(int)); // no warning
409	int *w = my_malloc(1); // warning: allocation of insufficient size '1' for type 'int' with size '4'
410	consumer_func(my_malloc(1)); // warning: allocation of insufficient size '1' for type 'int' with size '4'
411	}
412
413	.. Note:: This attribute works differently in clang than it does in GCC.
414	Specifically, clang will only trace ``const`` pointers (as above); we give up
415	on pointers that are not marked as ``const``. In the vast majority of cases,
416	this is unimportant, because LLVM has support for the ``alloc_size``
417	attribute. However, this may cause mildly unintuitive behavior when used with
418	other attributes, such as ``enable_if``.)reST";
419
420	static const char AttrDoc_Allocating[] = R"reST(Declares that a function potentially allocates heap memory, and prevents any potential inference
421	of ``nonallocating`` by the compiler.)reST";
422
423	static const char AttrDoc_AlwaysDestroy[] = R"reST(The ``always_destroy`` attribute specifies that a variable with static or thread
424	storage duration should have its exit-time destructor run. This attribute is the
425	default unless clang was invoked with -fno-c++-static-destructors.
426
427	If a variable is explicitly declared with this attribute, Clang will silence
428	otherwise applicable ``-Wexit-time-destructors`` warnings.)reST";
429
430	static const char AttrDoc_AlwaysInline[] = R"reST(Inlining heuristics are disabled and inlining is always attempted regardless of
431	optimization level.
432
433	``[[clang::always_inline]]`` spelling can be used as a statement attribute; other
434	spellings of the attribute are not supported on statements. If a statement is
435	marked ``[[clang::always_inline]]`` and contains calls, the compiler attempts
436	to inline those calls.
437
438	.. code-block:: c
439
440	int example(void) {
441	int i;
442	[[clang::always_inline]] foo(); // attempts to inline foo
443	[[clang::always_inline]] i = bar(); // attempts to inline bar
444	[[clang::always_inline]] return f(42, baz(bar())); // attempts to inline everything
445	}
446
447	A declaration statement, which is a statement, is not a statement that can have an
448	attribute associated with it (the attribute applies to the declaration, not the
449	statement in that case). So this use case will not work:
450
451	.. code-block:: c
452
453	int example(void) {
454	[[clang::always_inline]] int i = bar();
455	return i;
456	}
457
458	This attribute does not guarantee that inline substitution actually occurs.
459
460	<ins>Note: applying this attribute to a coroutine at the `-O0` optimization level
461	has no effect; other optimization levels may only partially inline and result in a
462	diagnostic.</ins>
463
464	See also `the Microsoft Docs on Inline Functions`_, `the GCC Common Function
465	Attribute docs`_, and `the GCC Inline docs`_.
466
467	.. _the Microsoft Docs on Inline Functions: https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp
468	.. _the GCC Common Function Attribute docs: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
469	.. _the GCC Inline docs: https://gcc.gnu.org/onlinedocs/gcc/Inline.html)reST";
470
471	static const char AttrDoc_AnalyzerNoReturn[] = R"reST(No documentation.)reST";
472
473	static const char AttrDoc_Annotate[] = R"reST(No documentation.)reST";
474
475	static const char AttrDoc_AnnotateType[] = R"reST(This attribute is used to add annotations to types, typically for use by static
476	analysis tools that are not integrated into the core Clang compiler (e.g.,
477	Clang-Tidy checks or out-of-tree Clang-based tools). It is a counterpart to the
478	`annotate` attribute, which serves the same purpose, but for declarations.
479
480	The attribute takes a mandatory string literal argument specifying the
481	annotation category and an arbitrary number of optional arguments that provide
482	additional information specific to the annotation category. The optional
483	arguments must be constant expressions of arbitrary type.
484
485	For example:
486
487	.. code-block:: c++
488
489	int* [[clang::annotate_type("category1", "foo", 1)]] f(int[[clang::annotate_type("category2")]] *);
490
491	The attribute does not have any effect on the semantics of the type system,
492	neither type checking rules, nor runtime semantics. In particular:
493
494	- ``std::is_same<T, T [[clang::annotate_type("foo")]]>`` is true for all types
495	``T``.
496
497	- It is not permissible for overloaded functions or template specializations
498	to differ merely by an ``annotate_type`` attribute.
499
500	- The presence of an ``annotate_type`` attribute will not affect name
501	mangling.)reST";
502
503	static const char AttrDoc_AnyX86Interrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on X86
504	targets. This attribute may be attached to a function definition and instructs
505	the backend to generate appropriate function entry/exit code so that it can be
506	used directly as an interrupt service routine.
507
508	Interrupt handlers have access to the stack frame pushed onto the stack by the processor,
509	and return using the ``IRET`` instruction. All registers in an interrupt handler are callee-saved.
510	Exception handlers also have access to the error code pushed onto the stack by the processor,
511	when applicable.
512
513	An interrupt handler must take the following arguments:
514
515	.. code-block:: c
516
517	__attribute__ ((interrupt))
518	void f (struct stack_frame *frame) {
519	...
520	}
521
522	Where ``struct stack_frame`` is a suitable struct matching the stack frame pushed by the
523	processor.
524
525	An exception handler must take the following arguments:
526
527	.. code-block:: c
528
529	__attribute__ ((interrupt))
530	void g (struct stack_frame *frame, unsigned long code) {
531	...
532	}
533
534	On 32-bit targets, the ``code`` argument should be of type ``unsigned int``.
535
536	Exception handlers should only be used when an error code is pushed by the processor.
537	Using the incorrect handler type will crash the system.
538
539	Interrupt and exception handlers cannot be called by other functions and must have return type ``void``.
540
541	Interrupt and exception handlers should only call functions with the 'no_caller_saved_registers'
542	attribute, or should be compiled with the '-mgeneral-regs-only' flag to avoid saving unused
543	non-GPR registers.)reST";
544
545	static const char AttrDoc_AnyX86NoCallerSavedRegisters[] = R"reST(Use this attribute to indicate that the specified function has no
546	caller-saved registers. That is, all registers are callee-saved except for
547	registers used for passing parameters to the function or returning parameters
548	from the function.
549	The compiler saves and restores any modified registers that were not used for
550	passing or returning arguments to the function.
551
552	The user can call functions specified with the 'no_caller_saved_registers'
553	attribute from an interrupt handler without saving and restoring all
554	call-clobbered registers.
555
556	Functions specified with the 'no_caller_saved_registers' attribute should only
557	call other functions with the 'no_caller_saved_registers' attribute, or should be
558	compiled with the '-mgeneral-regs-only' flag to avoid saving unused non-GPR registers.
559
560	Note that 'no_caller_saved_registers' attribute is not a calling convention.
561	In fact, it only overrides the decision of which registers should be saved by
562	the caller, but not how the parameters are passed from the caller to the callee.
563
564	For example:
565
566	.. code-block:: c
567
568	__attribute__ ((no_caller_saved_registers, fastcall))
569	void f (int arg1, int arg2) {
570	...
571	}
572
573	In this case parameters 'arg1' and 'arg2' will be passed in registers.
574	In this case, on 32-bit x86 targets, the function 'f' will use ECX and EDX as
575	register parameters. However, it will not assume any scratch registers and
576	should save and restore any modified registers except for ECX and EDX.)reST";
577
578	static const char AttrDoc_AnyX86NoCfCheck[] = R"reST(Jump Oriented Programming attacks rely on tampering with addresses used by
579	indirect call / jmp, e.g. redirect control-flow to non-programmer
580	intended bytes in the binary.
581	X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow
582	Enforcement Technology (CET). IBT instruments ENDBR instructions used to
583	specify valid targets of indirect call / jmp.
584	The ``nocf_check`` attribute has two roles:
585	1. Appertains to a function - do not add ENDBR instruction at the beginning of
586	the function.
587	2. Appertains to a function pointer - do not track the target function of this
588	pointer (by adding nocf_check prefix to the indirect-call instruction).)reST";
589
590	static const char AttrDoc_ArcWeakrefUnavailable[] = R"reST(No documentation.)reST";
591
592	static const char AttrDoc_ArgumentWithTypeTag[] = R"reST(Use ``__attribute__((argument_with_type_tag(arg_kind, arg_idx,
593	type_tag_idx)))`` on a function declaration to specify that the function
594	accepts a type tag that determines the type of some other argument.
595
596	This attribute is primarily useful for checking arguments of variadic functions
597	(``pointer_with_type_tag`` can be used in most non-variadic cases).
598
599	In the attribute prototype above:
600	* ``arg_kind`` is an identifier that should be used when annotating all
601	applicable type tags.
602	* ``arg_idx`` provides the position of a function argument. The expected type of
603	this function argument will be determined by the function argument specified
604	by ``type_tag_idx``. In the code example below, "3" means that the type of the
605	function's third argument will be determined by ``type_tag_idx``.
606	* ``type_tag_idx`` provides the position of a function argument. This function
607	argument will be a type tag. The type tag will determine the expected type of
608	the argument specified by ``arg_idx``. In the code example below, "2" means
609	that the type tag associated with the function's second argument should agree
610	with the type of the argument specified by ``arg_idx``.
611
612	For example:
613
614	.. code-block:: c++
615
616	int fcntl(int fd, int cmd, ...)
617	__attribute__(( argument_with_type_tag(fcntl,3,2) ));
618	// The function's second argument will be a type tag; this type tag will
619	// determine the expected type of the function's third argument.)reST";
620
621	static const char AttrDoc_ArmAgnostic[] = R"reST(The ``__arm_agnostic`` keyword applies to prototyped function types and
622	affects the function's calling convention for a given state S. This
623	attribute allows the user to describe a function that preserves S, without
624	requiring the function to share S with its callers and without making
625	the assumption that S exists.
626
627	If a function has the ``__arm_agnostic(S)`` attribute and calls a function
628	without this attribute, then the function's object code will contain code
629	to preserve state S. Otherwise, the function's object code will be the same
630	as if it did not have the attribute.
631
632	The attribute takes string arguments to describe state S. The supported
633	states are:
634
635	* ``"sme_za_state"`` for state enabled by PSTATE.ZA, such as ZA and ZT0.
636
637	The attribute ``__arm_agnostic("sme_za_state")`` cannot be used in conjunction
638	with ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` or
639	``__arm_preserves(S)`` where state S describes state enabled by PSTATE.ZA,
640	such as "za" or "zt0".)reST";
641
642	static const char AttrDoc_ArmBuiltinAlias[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics.
643	It allows the intrinsic functions to
644	be declared using the names defined in ACLE, and still be recognized
645	as clang builtins equivalent to the underlying name. For example,
646	``arm_mve.h`` declares the function ``vaddq_u32`` with
647	``__attribute__((__clang_arm_mve_alias(__builtin_arm_mve_vaddq_u32)))``,
648	and similarly, one of the type-overloaded declarations of ``vaddq``
649	will have the same attribute. This ensures that both functions are
650	recognized as that clang builtin, and in the latter case, the choice
651	of which builtin to identify the function as can be deferred until
652	after overload resolution.
653
654	This attribute can only be used to set up the aliases for certain Arm
655	intrinsic functions; it is intended for use only inside ``arm_*.h``
656	and is not a general mechanism for declaring arbitrary aliases for
657	clang builtin functions.
658
659	In order to avoid duplicating the attribute definitions for similar
660	purpose for other architecture, there is a general form for the
661	attribute `clang_builtin_alias`.)reST";
662
663	static const char AttrDoc_ArmIn[] = R"reST(The ``__arm_in`` keyword applies to prototyped function types and specifies
664	that the function shares a given state S with its caller. For ``__arm_in``, the
665	function takes the state S as input and returns with the state S unchanged.
666
667	The attribute takes string arguments to instruct the compiler which state
668	is shared. The supported states for S are:
669
670	* ``"za"`` for Matrix Storage (requires SME)
671
672	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
673	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
674
675	static const char AttrDoc_ArmInOut[] = R"reST(The ``__arm_inout`` keyword applies to prototyped function types and specifies
676	that the function shares a given state S with its caller. For ``__arm_inout``,
677	the function takes the state S as input and returns new state for S.
678
679	The attribute takes string arguments to instruct the compiler which state
680	is shared. The supported states for S are:
681
682	* ``"za"`` for Matrix Storage (requires SME)
683
684	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
685	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
686
687	static const char AttrDoc_ArmLocallyStreaming[] = R"reST(The ``__arm_locally_streaming`` keyword applies to function declarations
688	and specifies that all the statements in the function are executed in
689	streaming mode. This means that:
690
691	* the function requires that the target processor implements the Scalable Matrix
692	Extension (SME).
693
694	* the program automatically puts the machine into streaming mode before
695	executing the statements and automatically restores the previous mode
696	afterwards.
697
698	Clang manages PSTATE.SM automatically; it is not the source code's
699	responsibility to do this. For example, Clang will emit code to enable
700	streaming mode at the start of the function, and disable streaming mode
701	at the end of the function.)reST";
702
703	static const char AttrDoc_ArmMveStrictPolymorphism[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics for the Arm
704	MVE instruction set. It is used to define the vector types used by the MVE
705	intrinsics.
706
707	Its effect is to modify the behavior of a vector type with respect to function
708	overloading. If a candidate function for overload resolution has a parameter
709	type with this attribute, then the selection of that candidate function will be
710	disallowed if the actual argument can only be converted via a lax vector
711	conversion. The aim is to prevent spurious ambiguity in ARM MVE polymorphic
712	intrinsics.
713
714	.. code-block:: c++
715
716	void overloaded(uint16x8_t vector, uint16_t scalar);
717	void overloaded(int32x4_t vector, int32_t scalar);
718	uint16x8_t myVector;
719	uint16_t myScalar;
720
721	// myScalar is promoted to int32_t as a side effect of the addition,
722	// so if lax vector conversions are considered for myVector, then
723	// the two overloads are equally good (one argument conversion
724	// each). But if the vector has the __clang_arm_mve_strict_polymorphism
725	// attribute, only the uint16x8_t,uint16_t overload will match.
726	overloaded(myVector, myScalar + 1);
727
728	However, this attribute does not prohibit lax vector conversions in contexts
729	other than overloading.
730
731	.. code-block:: c++
732
733	uint16x8_t function();
734
735	// This is still permitted with lax vector conversion enabled, even
736	// if the vector types have __clang_arm_mve_strict_polymorphism
737	int32x4_t result = function();)reST";
738
739	static const char AttrDoc_ArmNew[] = R"reST(The ``__arm_new`` keyword applies to function declarations and specifies
740	that the function will create a new scope for state S.
741
742	The attribute takes string arguments to instruct the compiler for which state
743	to create new scope. The supported states for S are:
744
745	* ``"za"`` for Matrix Storage (requires SME)
746
747	For state ``"za"``, this means that:
748
749	* the function requires that the target processor implements the Scalable Matrix
750	Extension (SME).
751
752	* the function will commit any lazily saved ZA data.
753
754	* the function will create a new ZA context and enable PSTATE.ZA.
755
756	* the function will disable PSTATE.ZA (by setting it to 0) before returning.
757
758	For ``__arm_new("za")`` functions Clang will set up the ZA context automatically
759	on entry to the function and disable it before returning. For example, if ZA is
760	in a dormant state Clang will generate the code to commit a lazy-save and set up
761	a new ZA state before executing user code.)reST";
762
763	static const char AttrDoc_ArmOut[] = R"reST(The ``__arm_out`` keyword applies to prototyped function types and specifies
764	that the function shares a given state S with its caller. For ``__arm_out``,
765	the function ignores the incoming state for S and returns new state for S.
766
767	The attribute takes string arguments to instruct the compiler which state
768	is shared. The supported states for S are:
769
770	* ``"za"`` for Matrix Storage (requires SME)
771
772	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
773	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
774
775	static const char AttrDoc_ArmPreserves[] = R"reST(The ``__arm_preserves`` keyword applies to prototyped function types and
776	specifies that the function does not read a given state S and returns
777	with state S unchanged.
778
779	The attribute takes string arguments to instruct the compiler which state
780	is shared. The supported states for S are:
781
782	* ``"za"`` for Matrix Storage (requires SME)
783
784	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
785	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
786
787	static const char AttrDoc_ArmStreaming[] = R"reST(The ``__arm_streaming`` keyword applies to prototyped function types and specifies
788	that the function has a "streaming interface". This means that:
789
790	* the function requires that the processor implements the Scalable Matrix
791	Extension (SME).
792
793	* the function must be entered in streaming mode (that is, with PSTATE.SM
794	set to 1)
795
796	* the function must return in streaming mode
797
798	Clang manages PSTATE.SM automatically; it is not the source code's
799	responsibility to do this. For example, if a non-streaming
800	function calls an ``__arm_streaming`` function, Clang generates code
801	that switches into streaming mode before calling the function and
802	switches back to non-streaming mode on return.)reST";
803
804	static const char AttrDoc_ArmStreamingCompatible[] = R"reST(The ``__arm_streaming_compatible`` keyword applies to prototyped function types and
805	specifies that the function has a "streaming compatible interface". This
806	means that:
807
808	* the function may be entered in either non-streaming mode (PSTATE.SM=0) or
809	in streaming mode (PSTATE.SM=1).
810
811	* the function must return in the same mode as it was entered.
812
813	* the code executed in the function is compatible with either mode.
814
815	Clang manages PSTATE.SM automatically; it is not the source code's
816	responsibility to do this. Clang will ensure that the generated code in
817	streaming-compatible functions is valid in either mode (PSTATE.SM=0 or
818	PSTATE.SM=1). For example, if an ``__arm_streaming_compatible`` function calls a
819	non-streaming function, Clang generates code to temporarily switch out of streaming
820	mode before calling the function and switch back to streaming-mode on return if
821	``PSTATE.SM`` is ``1`` on entry of the caller. If ``PSTATE.SM`` is ``0`` on
822	entry to the ``__arm_streaming_compatible`` function, the call will be executed
823	without changing modes.)reST";
824
825	static const char AttrDoc_Artificial[] = R"reST(The ``artificial`` attribute can be applied to an inline function. If such a
826	function is inlined, the attribute indicates that debuggers should associate
827	the resulting instructions with the call site, rather than with the
828	corresponding line within the inlined callee.)reST";
829
830	static const char AttrDoc_AsmLabel[] = R"reST(This attribute can be used on a function or variable to specify its symbol name.
831
832	On some targets, all C symbols are prefixed by default with a single character,
833	typically ``_``. This was done historically to distinguish them from symbols
834	used by other languages. (This prefix is also added to the standard Itanium
835	C++ ABI prefix on "mangled" symbol names, so that e.g. on such targets the true
836	symbol name for a C++ variable declared as ``int cppvar;`` would be
837	``__Z6cppvar``; note the two underscores.) This prefix is not added to the
838	symbol names specified by the ``__asm`` attribute; programmers wishing to match
839	a C symbol name must compensate for this.
840
841	For example, consider the following C code:
842
843	.. code-block:: c
844
845	int var1 __asm("altvar") = 1; // "altvar" in symbol table.
846	int var2 = 1; // "_var2" in symbol table.
847
848	void func1(void) __asm("altfunc");
849	void func1(void) {} // "altfunc" in symbol table.
850	void func2(void) {} // "_func2" in symbol table.
851
852	Clang's implementation of this attribute is compatible with GCC's, `documented here <https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html>`_.
853
854	While it is possible to use this attribute to name a special symbol used
855	internally by the compiler, such as an LLVM intrinsic, this is neither
856	recommended nor supported and may cause the compiler to crash or miscompile.
857	Users who wish to gain access to intrinsic behavior are strongly encouraged to
858	request new builtin functions.)reST";
859
860	static const char AttrDoc_AssertCapability[] = R"reST(Marks a function that dynamically tests whether a capability is held, and halts
861	the program if it is not held.)reST";
862
863	static const char AttrDoc_AssumeAligned[] = R"reST(Use ``__attribute__((assume_aligned(<alignment>[,<offset>]))`` on a function
864	declaration to specify that the return value of the function (which must be a
865	pointer type) has the specified offset, in bytes, from an address with the
866	specified alignment. The offset is taken to be zero if omitted.
867
868	.. code-block:: c++
869
870	// The returned pointer value has 32-byte alignment.
871	void *a() __attribute__((assume_aligned (32)));
872
873	// The returned pointer value is 4 bytes greater than an address having
874	// 32-byte alignment.
875	void *b() __attribute__((assume_aligned (32, 4)));
876
877	Note that this attribute provides information to the compiler regarding a
878	condition that the code already ensures is true. It does not cause the compiler
879	to enforce the provided alignment assumption.)reST";
880
881	static const char AttrDoc_Atomic[] = R"reST(The ``atomic`` attribute can be applied to compound statements to override or
882	further specify the default atomic code-generation behavior, especially on
883	targets such as AMDGPU. You can annotate compound statements with options
884	to modify how atomic instructions inside that statement are emitted at the IR
885	level.
886
887	For details, see the documentation for `@atomic
888	<http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-controlling-atomic-code-generation>`_)reST";
889
890	static const char AttrDoc_Availability[] = R"reST(The ``availability`` attribute can be placed on declarations to describe the
891	lifecycle of that declaration relative to operating system versions. Consider
892	the function declaration for a hypothetical function ``f``:
893
894	.. code-block:: c++
895
896	void f(void) __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
897
898	The availability attribute states that ``f`` was introduced in macOS 10.4,
899	deprecated in macOS 10.6, and obsoleted in macOS 10.7. This information
900	is used by Clang to determine when it is safe to use ``f``: for example, if
901	Clang is instructed to compile code for macOS 10.5, a call to ``f()``
902	succeeds. If Clang is instructed to compile code for macOS 10.6, the call
903	succeeds but Clang emits a warning specifying that the function is deprecated.
904	Finally, if Clang is instructed to compile code for macOS 10.7, the call
905	fails because ``f()`` is no longer available.
906
907	Clang is instructed to compile code for a minimum deployment version using
908	the ``-target`` or ``-mtargetos`` command line arguments. For example,
909	macOS 10.7 would be specified as ``-target x86_64-apple-macos10.7`` or
910	``-mtargetos=macos10.7``. Variants like Mac Catalyst are specified as
911	``-target arm64-apple-ios15.0-macabi`` or ``-mtargetos=ios15.0-macabi``
912
913	The availability attribute is a comma-separated list starting with the
914	platform name and then including clauses specifying important milestones in the
915	declaration's lifetime (in any order) along with additional information. Those
916	clauses can be:
917
918	introduced=\ version
919	The first version in which this declaration was introduced.
920
921	deprecated=\ version
922	The first version in which this declaration was deprecated, meaning that
923	users should migrate away from this API.
924
925	obsoleted=\ version
926	The first version in which this declaration was obsoleted, meaning that it
927	was removed completely and can no longer be used.
928
929	unavailable
930	This declaration is never available on this platform.
931
932	message=\ string-literal
933	Additional message text that Clang will provide when emitting a warning or
934	error about use of a deprecated or obsoleted declaration. Useful to direct
935	users to replacement APIs.
936
937	replacement=\ string-literal
938	Additional message text that Clang will use to provide Fix-It when emitting
939	a warning about use of a deprecated declaration. The Fix-It will replace
940	the deprecated declaration with the new declaration specified.
941
942	environment=\ identifier
943	Target environment in which this declaration is available. If present,
944	the availability attribute applies only to targets with the same platform
945	and environment. The parameter is currently supported only in HLSL.
946
947	Multiple availability attributes can be placed on a declaration, which may
948	correspond to different platforms. For most platforms, the availability
949	attribute with the platform corresponding to the target platform will be used;
950	any others will be ignored. However, the availability for ``watchOS`` and
951	``tvOS`` can be implicitly inferred from an ``iOS`` availability attribute.
952	Any explicit availability attributes for those platforms are still preferred over
953	the implicitly inferred availability attributes. If no availability attribute
954	specifies availability for the current target platform, the availability
955	attributes are ignored. Supported platforms are:
956
957	``iOS``
958	``macOS``
959	``tvOS``
960	``watchOS``
961	``iOSApplicationExtension``
962	``macOSApplicationExtension``
963	``tvOSApplicationExtension``
964	``watchOSApplicationExtension``
965	``macCatalyst``
966	``macCatalystApplicationExtension``
967	``visionOS``
968	``visionOSApplicationExtension``
969	``driverkit``
970	``swift``
971	``android``
972	``fuchsia``
973	``ohos``
974	``zos``
975	``ShaderModel``
976
977	Some platforms have alias names:
978
979	``ios``
980	``macos``
981	``macosx (deprecated)``
982	``tvos``
983	``watchos``
984	``ios_app_extension``
985	``macos_app_extension``
986	``macosx_app_extension (deprecated)``
987	``tvos_app_extension``
988	``watchos_app_extension``
989	``maccatalyst``
990	``maccatalyst_app_extension``
991	``visionos``
992	``visionos_app_extension``
993	``shadermodel``
994
995	Supported environment names for the ShaderModel platform:
996
997	``pixel``
998	``vertex``
999	``geometry``
1000	``hull``
1001	``domain``
1002	``compute``
1003	``raygeneration``
1004	``intersection``
1005	``anyhit``
1006	``closesthit``
1007	``miss``
1008	``callable``
1009	``mesh``
1010	``amplification``
1011	``library``
1012
1013	A declaration can typically be used even when deploying back to a platform
1014	version prior to when the declaration was introduced. When this happens, the
1015	declaration is `weakly linked
1016	<https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,
1017	as if the ``weak_import`` attribute were added to the declaration. A
1018	weakly-linked declaration may or may not be present a run-time, and a program
1019	can determine whether the declaration is present by checking whether the
1020	address of that declaration is non-NULL.
1021
1022	The flag ``strict`` disallows using API when deploying back to a
1023	platform version prior to when the declaration was introduced. An
1024	attempt to use such API before its introduction causes a hard error.
1025	Weakly-linking is almost always a better API choice, since it allows
1026	users to query availability at runtime.
1027
1028	If there are multiple declarations of the same entity, the availability
1029	attributes must either match on a per-platform basis or later
1030	declarations must not have availability attributes for that
1031	platform. For example:
1032
1033	.. code-block:: c
1034
1035	void g(void) __attribute__((availability(macos,introduced=10.4)));
1036	void g(void) __attribute__((availability(macos,introduced=10.4))); // okay, matches
1037	void g(void) __attribute__((availability(ios,introduced=4.0))); // okay, adds a new platform
1038	void g(void); // okay, inherits both macos and ios availability from above.
1039	void g(void) __attribute__((availability(macos,introduced=10.5))); // error: mismatch
1040
1041	When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,:
1042
1043	.. code-block:: objc
1044
1045	@interface A
1046	- (id)method __attribute__((availability(macos,introduced=10.4)));
1047	- (id)method2 __attribute__((availability(macos,introduced=10.4)));
1048	@end
1049
1050	@interface B : A
1051	- (id)method __attribute__((availability(macos,introduced=10.3))); // okay: method moved into base class later
1052	- (id)method __attribute__((availability(macos,introduced=10.5))); // error: this method was available via the base class in 10.4
1053	@end
1054
1055	Starting with the macOS 10.12 SDK, the ``API_AVAILABLE`` macro from
1056	``<os/availability.h>`` can simplify the spelling:
1057
1058	.. code-block:: objc
1059
1060	@interface A
1061	- (id)method API_AVAILABLE(macos(10.11)));
1062	- (id)otherMethod API_AVAILABLE(macos(10.11), ios(11.0));
1063	@end
1064
1065	Availability attributes can also be applied using a ``#pragma clang attribute``.
1066	Any explicit availability attribute whose platform corresponds to the target
1067	platform is applied to a declaration regardless of the availability attributes
1068	specified in the pragma. For example, in the code below,
1069	``hasExplicitAvailabilityAttribute`` will use the ``macOS`` availability
1070	attribute that is specified with the declaration, whereas
1071	``getsThePragmaAvailabilityAttribute`` will use the ``macOS`` availability
1072	attribute that is applied by the pragma.
1073
1074	.. code-block:: c
1075
1076	#pragma clang attribute push (__attribute__((availability(macOS, introduced=10.12))), apply_to=function)
1077	void getsThePragmaAvailabilityAttribute(void);
1078	void hasExplicitAvailabilityAttribute(void) __attribute__((availability(macos,introduced=10.4)));
1079	#pragma clang attribute pop
1080
1081	For platforms like ``watchOS`` and ``tvOS``, whose availability attributes can
1082	be implicitly inferred from an ``iOS`` availability attribute, the logic is
1083	slightly more complex. The explicit and the pragma-applied availability
1084	attributes whose platform corresponds to the target platform are applied as
1085	described in the previous paragraph. However, the implicitly inferred attributes
1086	are applied to a declaration only when there is no explicit or pragma-applied
1087	availability attribute whose platform corresponds to the target platform. For
1088	example, the function below will receive the ``tvOS`` availability from the
1089	pragma rather than using the inferred ``iOS`` availability from the declaration:
1090
1091	.. code-block:: c
1092
1093	#pragma clang attribute push (__attribute__((availability(tvOS, introduced=12.0))), apply_to=function)
1094	void getsThePragmaTVOSAvailabilityAttribute(void) __attribute__((availability(iOS,introduced=11.0)));
1095	#pragma clang attribute pop
1096
1097	The compiler is also able to apply implicitly inferred attributes from a pragma
1098	as well. For example, when targeting ``tvOS``, the function below will receive
1099	a ``tvOS`` availability attribute that is implicitly inferred from the ``iOS``
1100	availability attribute applied by the pragma:
1101
1102	.. code-block:: c
1103
1104	#pragma clang attribute push (__attribute__((availability(iOS, introduced=12.0))), apply_to=function)
1105	void infersTVOSAvailabilityFromPragma(void);
1106	#pragma clang attribute pop
1107
1108	The implicit attributes that are inferred from explicitly specified attributes
1109	whose platform corresponds to the target platform are applied to the declaration
1110	even if there is an availability attribute that can be inferred from a pragma.
1111	For example, the function below will receive the ``tvOS, introduced=11.0``
1112	availability that is inferred from the attribute on the declaration rather than
1113	inferring availability from the pragma:
1114
1115	.. code-block:: c
1116
1117	#pragma clang attribute push (__attribute__((availability(iOS, unavailable))), apply_to=function)
1118	void infersTVOSAvailabilityFromAttributeNextToDeclaration(void)
1119	__attribute__((availability(iOS,introduced=11.0)));
1120	#pragma clang attribute pop
1121
1122	Also see the documentation for `@available
1123	<http://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available>`_)reST";
1124
1125	static const char AttrDoc_AvailableOnlyInDefaultEvalMethod[] = R"reST(No documentation.)reST";
1126
1127	static const char AttrDoc_BPFFastCall[] = R"reST(Functions annotated with this attribute are likely to be inlined by BPF JIT.
1128	It is assumed that inlined implementation uses less caller saved registers,
1129	than a regular function.
1130	Specifically, the following registers are likely to be preserved:
1131	- ``R0`` if function return value is ``void``;
1132	- ``R2-R5` if function takes 1 argument;
1133	- ``R3-R5` if function takes 2 arguments;
1134	- ``R4-R5` if function takes 3 arguments;
1135	- ``R5`` if function takes 4 arguments;
1136
1137	For such functions Clang generates code pattern that allows BPF JIT
1138	to recognize and remove unnecessary spills and fills of the preserved
1139	registers.)reST";
1140
1141	static const char AttrDoc_BPFPreserveAccessIndex[] = R"reST(Clang supports the ``__attribute__((preserve_access_index))``
1142	attribute for the BPF target. This attribute may be attached to a
1143	struct or union declaration, where if -g is specified, it enables
1144	preserving struct or union member access debuginfo indices of this
1145	struct or union, similar to clang ``__builtin_preserve_access_index()``.)reST";
1146
1147	static const char AttrDoc_BPFPreserveStaticOffset[] = R"reST(Clang supports the ``__attribute__((preserve_static_offset))``
1148	attribute for the BPF target. This attribute may be attached to a
1149	struct or union declaration. Reading or writing fields of types having
1150	such annotation is guaranteed to generate LDX/ST/STX instruction with
1151	offset corresponding to the field.
1152
1153	For example:
1154
1155	.. code-block:: c
1156
1157	struct foo {
1158	int a;
1159	int b;
1160	};
1161
1162	struct bar {
1163	int a;
1164	struct foo b;
1165	} __attribute__((preserve_static_offset));
1166
1167	void buz(struct bar *g) {
1168	g->b.a = 42;
1169	}
1170
1171	The assignment to ``g``'s field would produce an ST instruction with
1172	offset 8: ``*(u32)(r1 + 8) = 42;``.
1173
1174	Without this attribute generated instructions might be different,
1175	depending on optimizations behavior. E.g. the example above could be
1176	rewritten as ``r1 += 8; *(u32)(r1 + 0) = 42;``.)reST";
1177
1178	static const char AttrDoc_BTFDeclTag[] = R"reST(Clang supports the ``__attribute__((btf_decl_tag("ARGUMENT")))`` attribute for
1179	all targets. This attribute may be attached to a struct/union, struct/union
1180	field, function, function parameter, variable or typedef declaration. If -g is
1181	specified, the ``ARGUMENT`` info will be preserved in IR and be emitted to
1182	dwarf. For BPF targets, the ``ARGUMENT`` info will be emitted to .BTF ELF
1183	section too.)reST";
1184
1185	static const char AttrDoc_BTFTypeTag[] = R"reST(Clang supports the ``__attribute__((btf_type_tag("ARGUMENT")))`` attribute for
1186	all targets. It only has effect when ``-g`` is specified on the command line and
1187	is currently silently ignored when not applied to a pointer type (note: this
1188	scenario may be diagnosed in the future).
1189
1190	The ``ARGUMENT`` string will be preserved in IR and emitted to DWARF for the
1191	types used in variable declarations, function declarations, or typedef
1192	declarations.
1193
1194	For BPF targets, the ``ARGUMENT`` string will also be emitted to .BTF ELF
1195	section.)reST";
1196
1197	static const char AttrDoc_Blocking[] = R"reST(Declares that a function potentially blocks, and prevents any potential inference of ``nonblocking``
1198	by the compiler.)reST";
1199
1200	static const char AttrDoc_Blocks[] = R"reST(No documentation.)reST";
1201
1202	static const char AttrDoc_Builtin[] = R"reST()reST";
1203
1204	static const char AttrDoc_BuiltinAlias[] = R"reST(This attribute is used in the implementation of the C intrinsics.
1205	It allows the C intrinsic functions to be declared using the names defined
1206	in target builtins, and still be recognized as clang builtins equivalent to the
1207	underlying name. For example, ``riscv_vector.h`` declares the function ``vadd``
1208	with ``__attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1)))``.
1209	This ensures that both functions are recognized as that clang builtin,
1210	and in the latter case, the choice of which builtin to identify the
1211	function as can be deferred until after overload resolution.
1212
1213	This attribute can only be used to set up the aliases for certain ARM/RISC-V
1214	C intrinsic functions; it is intended for use only inside ``arm_*.h`` and
1215	``riscv_*.h`` and is not a general mechanism for declaring arbitrary aliases
1216	for clang builtin functions.)reST";
1217
1218	static const char AttrDoc_C11NoReturn[] = R"reST(A function declared as ``_Noreturn`` shall not return to its caller. The
1219	compiler will generate a diagnostic for a function declared as ``_Noreturn``
1220	that appears to be capable of returning to its caller. Despite being a type
1221	specifier, the ``_Noreturn`` attribute cannot be specified on a function
1222	pointer type.)reST";
1223
1224	static const char AttrDoc_CDecl[] = R"reST(No documentation.)reST";
1225
1226	static const char AttrDoc_CFAuditedTransfer[] = R"reST(No documentation.)reST";
1227
1228	static const char AttrDoc_CFConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1229	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1230	convention (e.g. functions starting with "get" are assumed to return at
1231	``+0``).
1232
1233	It can be overridden using a family of the following attributes. In
1234	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1235	a function communicates that the object is returned at ``+1``, and the caller
1236	is responsible for freeing it.
1237	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1238	specifies that the object is returned at ``+0`` and the ownership remains with
1239	the callee.
1240	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1241	the Objective-C method call consumes the reference to ``self``, e.g. by
1242	attaching it to a supplied parameter.
1243	Additionally, parameters can have an annotation
1244	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1245	as that parameter effectively transfers the ownership, and the caller is no
1246	longer responsible for it.
1247	These attributes affect code generation when interacting with ARC code, and
1248	they are used by the Clang Static Analyzer.
1249
1250	In C programs using CoreFoundation, a similar set of attributes:
1251	``__attribute__((cf_returns_not_retained))``,
1252	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1253	have the same respective semantics when applied to CoreFoundation objects.
1254	These attributes affect code generation when interacting with ARC code, and
1255	they are used by the Clang Static Analyzer.
1256
1257	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1258	the same attribute family is present:
1259	``__attribute__((os_returns_not_retained))``,
1260	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1261	with the same respective semantics.
1262	Similar to ``__attribute__((ns_consumes_self))``,
1263	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1264	the reference to "this" (e.g., when attaching it to a different object supplied
1265	as a parameter).
1266	Out parameters (parameters the function is meant to write into,
1267	either via pointers-to-pointers or references-to-pointers)
1268	may be annotated with ``__attribute__((os_returns_retained))``
1269	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1270	written into the out parameter should (or respectively should not) be released
1271	after use.
1272	Since often out parameters may or may not be written depending on the exit
1273	code of the function,
1274	annotations ``__attribute__((os_returns_retained_on_zero))``
1275	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1276	an out parameter at ``+1`` is written if and only if the function returns a zero
1277	(respectively non-zero) error code.
1278	Observe that return-code-dependent out parameter annotations are only
1279	available for retained out parameters, as non-retained object do not have to be
1280	released by the callee.
1281	These attributes are only used by the Clang Static Analyzer.
1282
1283	The family of attributes ``X_returns_X_retained`` can be added to functions,
1284	C++ methods, and Objective-C methods and properties.
1285	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1286	and Objective-C methods.)reST";
1287
1288	static const char AttrDoc_CFGuard[] = R"reST(Code can indicate CFG checks are not wanted with the ``__declspec(guard(nocf))``
1289	attribute. This directs the compiler to not insert any CFG checks for the entire
1290	function. This approach is typically used only sparingly in specific situations
1291	where the programmer has manually inserted "CFG-equivalent" protection. The
1292	programmer knows that they are calling through some read-only function table
1293	whose address is obtained through read-only memory references and for which the
1294	index is masked to the function table limit. This approach may also be applied
1295	to small wrapper functions that are not inlined and that do nothing more than
1296	make a call through a function pointer. Since incorrect usage of this directive
1297	can compromise the security of CFG, the programmer must be very careful using
1298	the directive. Typically, this usage is limited to very small functions that
1299	only call one function.
1300
1301	`Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`)reST";
1302
1303	static const char AttrDoc_CFICanonicalJumpTable[] = R"reST(Use ``__attribute__((cfi_canonical_jump_table))`` on a function declaration to
1304	make the function's CFI jump table canonical. See :ref:`the CFI documentation
1305	<cfi-canonical-jump-tables>` for more details.)reST";
1306
1307	static const char AttrDoc_CFISalt[] = R"reST(The ``cfi_salt`` attribute specifies a string literal that is used as a salt
1308	for Control-Flow Integrity (CFI) checks to distinguish between functions with
1309	the same type signature. This attribute can be applied to function declarations,
1310	function definitions, and function pointer typedefs.
1311
1312	The attribute prevents function pointers from being replaced with pointers to
1313	functions that have a compatible type, which can be a CFI bypass vector.
1314
1315	Syntax:
1316
1317	* GNU-style: ``__attribute__((cfi_salt("<salt_string>")))``
1318	* C++11-style: ``[[clang::cfi_salt("<salt_string>")]]``
1319
1320	Usage:
1321
1322	The attribute takes a single string literal argument that serves as the salt.
1323	Functions or function types with different salt values will have different CFI
1324	hashes, even if they have identical type signatures.
1325
1326	Motivation:
1327
1328	In large codebases like the Linux kernel, there are often hundreds of functions
1329	with identical type signatures that are called indirectly:
1330
1331	.. code-block::
1332
1333	1662 functions with void (*)(void)
1334	1179 functions with int (*)(void)
1335	...
1336
1337	By salting the CFI hashes, you can make CFI more robust by ensuring that
1338	functions intended for different purposes have distinct CFI identities.
1339
1340	Type Compatibility:
1341
1342	* Functions with different salt values are considered to have incompatible types
1343	* Function pointers with different salt values cannot be assigned to each other
1344	* All declarations of the same function must use the same salt value
1345
1346	Example:
1347
1348	.. code-block:: c
1349
1350	// Header file - define convenience macros
1351	#define __cfi_salt(s) __attribute__((cfi_salt(s)))
1352
1353	// Typedef for regular function pointers
1354	typedef int (*fptr_t)(void);
1355
1356	// Typedef for salted function pointers
1357	typedef int (*fptr_salted_t)(void) __cfi_salt("pepper");
1358
1359	struct widget_ops {
1360	fptr_t init; // Regular CFI
1361	fptr_salted_t exec; // Salted CFI
1362	fptr_t cleanup; // Regular CFI
1363	};
1364
1365	// Function implementations
1366	static int widget_init(void) { return 0; }
1367	static int widget_exec(void) __cfi_salt("pepper") { return 1; }
1368	static int widget_cleanup(void) { return 0; }
1369
1370	static struct widget_ops ops = {
1371	.init = widget_init, // OK - compatible types
1372	.exec = widget_exec, // OK - both use "pepper" salt
1373	.cleanup = widget_cleanup // OK - compatible types
1374	};
1375
1376	// Using C++11 attribute syntax
1377	void secure_callback(void) [[clang::cfi_salt("secure")]];
1378
1379	// This would cause a compilation error:
1380	// fptr_t bad_ptr = widget_exec; // Error: incompatible types
1381
1382	Notes:
1383
1384	* The salt string can contain non-NULL ASCII characters, including spaces and
1385	quotes
1386	* This attribute only applies to function types; using it on non-function
1387	types will generate a warning
1388	* All declarations and definitions of the same function must use identical
1389	salt values
1390	* The attribute affects type compatibility during compilation and CFI hash
1391	generation during code generation)reST";
1392
1393	static const char AttrDoc_CFIUncheckedCallee[] = R"reST(``cfi_unchecked_callee`` is a function type attribute which prevents the compiler from instrumenting
1394	`Control Flow Integrity <https://clang.llvm.org/docs/ControlFlowIntegrity.html>`_ checks on indirect
1395	function calls. This also includes control flow checks added by
1396	`-fsanitize=function <https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks>`.
1397	Specifically, the attribute has the following semantics:
1398
1399	1. Indirect calls to a function type with this attribute will not be instrumented with CFI. That is,
1400	the indirect call will not be checked. Note that this only changes the behavior for indirect calls
1401	on pointers to function types having this attribute. It does not prevent all indirect function calls
1402	for a given type from being checked.
1403	2. All direct references to a function whose type has this attribute will always reference the
1404	function definition rather than an entry in the CFI jump table.
1405	3. When a pointer to a function with this attribute is implicitly cast to a pointer to a function
1406	without this attribute, the compiler will give a warning saying this attribute is discarded. This
1407	warning can be silenced with an explicit cast. Note an explicit cast just disables the warning, so
1408	direct references to a function with a ``cfi_unchecked_callee`` attribute will still reference the
1409	function definition rather than the CFI jump table.
1410
1411	.. code-block:: c
1412
1413	#define CFI_UNCHECKED_CALLEE __attribute__((cfi_unchecked_callee))
1414
1415	void no_cfi() CFI_UNCHECKED_CALLEE {}
1416
1417	void (*with_cfi)() = no_cfi; // warning: implicit conversion discards `cfi_unchecked_callee` attribute.
1418	// `with_cfi` also points to the actual definition of `no_cfi` rather than
1419	// its jump table entry.
1420
1421	void invoke(void (CFI_UNCHECKED_CALLEE *func)()) {
1422	func(); // CFI will not instrument this indirect call.
1423
1424	void (*func2)() = func; // warning: implicit conversion discards `cfi_unchecked_callee` attribute.
1425
1426	func2(); // CFI will instrument this indirect call. Users should be careful however because if this
1427	// references a function with type `cfi_unchecked_callee`, then the CFI check may incorrectly
1428	// fail because the reference will be to the function definition rather than the CFI jump
1429	// table entry.
1430	}
1431
1432	This attribute can only be applied on functions or member functions. This attribute can be a good
1433	alternative to ``no_sanitize("cfi")`` if you only want to disable innstrumentation for specific indirect
1434	calls rather than applying ``no_sanitize("cfi")`` on the whole function containing indirect call. Note
1435	that ``cfi_unchecked_attribute`` is a type attribute doesn't disable CFI instrumentation on a function
1436	body.)reST";
1437
1438	static const char AttrDoc_CFReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1439	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1440	convention (e.g. functions starting with "get" are assumed to return at
1441	``+0``).
1442
1443	It can be overridden using a family of the following attributes. In
1444	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1445	a function communicates that the object is returned at ``+1``, and the caller
1446	is responsible for freeing it.
1447	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1448	specifies that the object is returned at ``+0`` and the ownership remains with
1449	the callee.
1450	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1451	the Objective-C method call consumes the reference to ``self``, e.g. by
1452	attaching it to a supplied parameter.
1453	Additionally, parameters can have an annotation
1454	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1455	as that parameter effectively transfers the ownership, and the caller is no
1456	longer responsible for it.
1457	These attributes affect code generation when interacting with ARC code, and
1458	they are used by the Clang Static Analyzer.
1459
1460	In C programs using CoreFoundation, a similar set of attributes:
1461	``__attribute__((cf_returns_not_retained))``,
1462	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1463	have the same respective semantics when applied to CoreFoundation objects.
1464	These attributes affect code generation when interacting with ARC code, and
1465	they are used by the Clang Static Analyzer.
1466
1467	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1468	the same attribute family is present:
1469	``__attribute__((os_returns_not_retained))``,
1470	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1471	with the same respective semantics.
1472	Similar to ``__attribute__((ns_consumes_self))``,
1473	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1474	the reference to "this" (e.g., when attaching it to a different object supplied
1475	as a parameter).
1476	Out parameters (parameters the function is meant to write into,
1477	either via pointers-to-pointers or references-to-pointers)
1478	may be annotated with ``__attribute__((os_returns_retained))``
1479	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1480	written into the out parameter should (or respectively should not) be released
1481	after use.
1482	Since often out parameters may or may not be written depending on the exit
1483	code of the function,
1484	annotations ``__attribute__((os_returns_retained_on_zero))``
1485	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1486	an out parameter at ``+1`` is written if and only if the function returns a zero
1487	(respectively non-zero) error code.
1488	Observe that return-code-dependent out parameter annotations are only
1489	available for retained out parameters, as non-retained object do not have to be
1490	released by the callee.
1491	These attributes are only used by the Clang Static Analyzer.
1492
1493	The family of attributes ``X_returns_X_retained`` can be added to functions,
1494	C++ methods, and Objective-C methods and properties.
1495	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1496	and Objective-C methods.)reST";
1497
1498	static const char AttrDoc_CFReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1499	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1500	convention (e.g. functions starting with "get" are assumed to return at
1501	``+0``).
1502
1503	It can be overridden using a family of the following attributes. In
1504	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1505	a function communicates that the object is returned at ``+1``, and the caller
1506	is responsible for freeing it.
1507	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1508	specifies that the object is returned at ``+0`` and the ownership remains with
1509	the callee.
1510	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1511	the Objective-C method call consumes the reference to ``self``, e.g. by
1512	attaching it to a supplied parameter.
1513	Additionally, parameters can have an annotation
1514	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1515	as that parameter effectively transfers the ownership, and the caller is no
1516	longer responsible for it.
1517	These attributes affect code generation when interacting with ARC code, and
1518	they are used by the Clang Static Analyzer.
1519
1520	In C programs using CoreFoundation, a similar set of attributes:
1521	``__attribute__((cf_returns_not_retained))``,
1522	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1523	have the same respective semantics when applied to CoreFoundation objects.
1524	These attributes affect code generation when interacting with ARC code, and
1525	they are used by the Clang Static Analyzer.
1526
1527	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1528	the same attribute family is present:
1529	``__attribute__((os_returns_not_retained))``,
1530	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1531	with the same respective semantics.
1532	Similar to ``__attribute__((ns_consumes_self))``,
1533	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1534	the reference to "this" (e.g., when attaching it to a different object supplied
1535	as a parameter).
1536	Out parameters (parameters the function is meant to write into,
1537	either via pointers-to-pointers or references-to-pointers)
1538	may be annotated with ``__attribute__((os_returns_retained))``
1539	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1540	written into the out parameter should (or respectively should not) be released
1541	after use.
1542	Since often out parameters may or may not be written depending on the exit
1543	code of the function,
1544	annotations ``__attribute__((os_returns_retained_on_zero))``
1545	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1546	an out parameter at ``+1`` is written if and only if the function returns a zero
1547	(respectively non-zero) error code.
1548	Observe that return-code-dependent out parameter annotations are only
1549	available for retained out parameters, as non-retained object do not have to be
1550	released by the callee.
1551	These attributes are only used by the Clang Static Analyzer.
1552
1553	The family of attributes ``X_returns_X_retained`` can be added to functions,
1554	C++ methods, and Objective-C methods and properties.
1555	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1556	and Objective-C methods.)reST";
1557
1558	static const char AttrDoc_CFUnknownTransfer[] = R"reST(No documentation.)reST";
1559
1560	static const char AttrDoc_CPUDispatch[] = R"reST(The ``cpu_specific`` and ``cpu_dispatch`` attributes are used to define and
1561	resolve multiversioned functions. This form of multiversioning provides a
1562	mechanism for declaring versions across translation units and manually
1563	specifying the resolved function list. A specified CPU defines a set of minimum
1564	features that are required for the function to be called. The result of this is
1565	that future processors execute the most restrictive version of the function the
1566	new processor can execute.
1567
1568	In addition, unlike the ICC implementation of this feature, the selection of the
1569	version does not consider the manufacturer or microarchitecture of the processor.
1570	It tests solely the list of features that are both supported by the specified
1571	processor and present in the compiler-rt library. This can be surprising at times,
1572	as the runtime processor may be from a completely different manufacturer, as long
1573	as it supports the same feature set.
1574
1575	This can additionally be surprising, as some processors are indistringuishable from
1576	others based on the list of testable features. When this happens, the variant
1577	is selected in an unspecified manner.
1578
1579	Function versions are defined with ``cpu_specific``, which takes one or more CPU
1580	names as a parameter. For example:
1581
1582	.. code-block:: c
1583
1584	// Declares and defines the ivybridge version of single_cpu.
1585	__attribute__((cpu_specific(ivybridge)))
1586	void single_cpu(void){}
1587
1588	// Declares and defines the atom version of single_cpu.
1589	__attribute__((cpu_specific(atom)))
1590	void single_cpu(void){}
1591
1592	// Declares and defines both the ivybridge and atom version of multi_cpu.
1593	__attribute__((cpu_specific(ivybridge, atom)))
1594	void multi_cpu(void){}
1595
1596	A dispatching (or resolving) function can be declared anywhere in a project's
1597	source code with ``cpu_dispatch``. This attribute takes one or more CPU names
1598	as a parameter (like ``cpu_specific``). Functions marked with ``cpu_dispatch``
1599	are not expected to be defined, only declared. If such a marked function has a
1600	definition, any side effects of the function are ignored; trivial function
1601	bodies are permissible for ICC compatibility.
1602
1603	.. code-block:: c
1604
1605	// Creates a resolver for single_cpu above.
1606	__attribute__((cpu_dispatch(ivybridge, atom)))
1607	void single_cpu(void){}
1608
1609	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1610	// translation unit.
1611	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1612	void multi_cpu(void){}
1613
1614	Note that it is possible to have a resolving function that dispatches based on
1615	more or fewer options than are present in the program. Specifying fewer will
1616	result in the omitted options not being considered during resolution. Specifying
1617	a version for resolution that isn't defined in the program will result in a
1618	linking failure.
1619
1620	It is also possible to specify a CPU name of ``generic`` which will be resolved
1621	if the executing processor doesn't satisfy the features required in the CPU
1622	name. The behavior of a program executing on a processor that doesn't satisfy
1623	any option of a multiversioned function is undefined.)reST";
1624
1625	static const char AttrDoc_CPUSpecific[] = R"reST(The ``cpu_specific`` and ``cpu_dispatch`` attributes are used to define and
1626	resolve multiversioned functions. This form of multiversioning provides a
1627	mechanism for declaring versions across translation units and manually
1628	specifying the resolved function list. A specified CPU defines a set of minimum
1629	features that are required for the function to be called. The result of this is
1630	that future processors execute the most restrictive version of the function the
1631	new processor can execute.
1632
1633	In addition, unlike the ICC implementation of this feature, the selection of the
1634	version does not consider the manufacturer or microarchitecture of the processor.
1635	It tests solely the list of features that are both supported by the specified
1636	processor and present in the compiler-rt library. This can be surprising at times,
1637	as the runtime processor may be from a completely different manufacturer, as long
1638	as it supports the same feature set.
1639
1640	This can additionally be surprising, as some processors are indistringuishable from
1641	others based on the list of testable features. When this happens, the variant
1642	is selected in an unspecified manner.
1643
1644	Function versions are defined with ``cpu_specific``, which takes one or more CPU
1645	names as a parameter. For example:
1646
1647	.. code-block:: c
1648
1649	// Declares and defines the ivybridge version of single_cpu.
1650	__attribute__((cpu_specific(ivybridge)))
1651	void single_cpu(void){}
1652
1653	// Declares and defines the atom version of single_cpu.
1654	__attribute__((cpu_specific(atom)))
1655	void single_cpu(void){}
1656
1657	// Declares and defines both the ivybridge and atom version of multi_cpu.
1658	__attribute__((cpu_specific(ivybridge, atom)))
1659	void multi_cpu(void){}
1660
1661	A dispatching (or resolving) function can be declared anywhere in a project's
1662	source code with ``cpu_dispatch``. This attribute takes one or more CPU names
1663	as a parameter (like ``cpu_specific``). Functions marked with ``cpu_dispatch``
1664	are not expected to be defined, only declared. If such a marked function has a
1665	definition, any side effects of the function are ignored; trivial function
1666	bodies are permissible for ICC compatibility.
1667
1668	.. code-block:: c
1669
1670	// Creates a resolver for single_cpu above.
1671	__attribute__((cpu_dispatch(ivybridge, atom)))
1672	void single_cpu(void){}
1673
1674	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1675	// translation unit.
1676	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1677	void multi_cpu(void){}
1678
1679	Note that it is possible to have a resolving function that dispatches based on
1680	more or fewer options than are present in the program. Specifying fewer will
1681	result in the omitted options not being considered during resolution. Specifying
1682	a version for resolution that isn't defined in the program will result in a
1683	linking failure.
1684
1685	It is also possible to specify a CPU name of ``generic`` which will be resolved
1686	if the executing processor doesn't satisfy the features required in the CPU
1687	name. The behavior of a program executing on a processor that doesn't satisfy
1688	any option of a multiversioned function is undefined.)reST";
1689
1690	static const char AttrDoc_CUDAClusterDims[] = R"reST(In CUDA/HIP programming, the ``cluster_dims`` attribute, conventionally exposed as the
1691	``__cluster_dims__`` macro, can be applied to a kernel function to set the dimensions of a
1692	thread block cluster, which is an optional level of hierarchy and made up of thread blocks.
1693	``__cluster_dims__`` defines the cluster size as ``(X, Y, Z)``, where each value is the number
1694	of thread blocks in that dimension. The ``cluster_dims`` and `no_cluster`` attributes are
1695	mutually exclusive.
1696
1697	.. code::
1698
1699	__global__ __cluster_dims__(2, 1, 1) void kernel(...) {
1700	...
1701	})reST";
1702
1703	static const char AttrDoc_CUDAConstant[] = R"reST(No documentation.)reST";
1704
1705	static const char AttrDoc_CUDADevice[] = R"reST(No documentation.)reST";
1706
1707	static const char AttrDoc_CUDADeviceBuiltinSurfaceType[] = R"reST(The ``device_builtin_surface_type`` attribute can be applied to a class
1708	template when declaring the surface reference. A surface reference variable
1709	could be accessed on the host side and, on the device side, might be translated
1710	into an internal surface object, which is established through surface bind and
1711	unbind runtime APIs.)reST";
1712
1713	static const char AttrDoc_CUDADeviceBuiltinTextureType[] = R"reST(The ``device_builtin_texture_type`` attribute can be applied to a class
1714	template when declaring the texture reference. A texture reference variable
1715	could be accessed on the host side and, on the device side, might be translated
1716	into an internal texture object, which is established through texture bind and
1717	unbind runtime APIs.)reST";
1718
1719	static const char AttrDoc_CUDAGlobal[] = R"reST(No documentation.)reST";
1720
1721	static const char AttrDoc_CUDAGridConstant[] = R"reST(The ``__grid_constant__`` attribute can be applied to a ``const``-qualified kernel
1722	function argument and allows compiler to take the address of that argument without
1723	making a copy. The argument applies to sm_70 or newer GPUs, during compilation
1724	with CUDA-11.7(PTX 7.7) or newer, and is ignored otherwise.)reST";
1725
1726	static const char AttrDoc_CUDAHost[] = R"reST(No documentation.)reST";
1727
1728	static const char AttrDoc_CUDAInvalidTarget[] = R"reST()reST";
1729
1730	static const char AttrDoc_CUDALaunchBounds[] = R"reST(No documentation.)reST";
1731
1732	static const char AttrDoc_CUDANoCluster[] = R"reST(In CUDA/HIP programming, a kernel function can still be launched with the cluster feature enabled
1733	at runtime, even without being annotated with ``__cluster_dims__``. The LLVM/Clang-exclusive
1734	``no_cluster`` attribute, conventionally exposed as the ``__no_cluster__`` macro, can be applied to
1735	a kernel function to explicitly indicate that the cluster feature will not be enabled either at
1736	compile time or at kernel launch time. This allows the compiler to apply certain optimizations
1737	without assuming that clustering could be enabled at runtime. It is undefined behavior to launch a
1738	kernel annotated with ``__no_cluster__`` if the cluster feature is enabled at runtime.
1739	The ``cluster_dims`` and ``no_cluster`` attributes are mutually exclusive.
1740
1741	.. code::
1742
1743	__global__ __no_cluster__ void kernel(...) {
1744	...
1745	})reST";
1746
1747	static const char AttrDoc_CUDAShared[] = R"reST(No documentation.)reST";
1748
1749	static const char AttrDoc_CXX11NoReturn[] = R"reST(A function declared as ``[[noreturn]]`` shall not return to its caller. The
1750	compiler will generate a diagnostic for a function declared as ``[[noreturn]]``
1751	that appears to be capable of returning to its caller.
1752
1753	The ``[[_Noreturn]]`` spelling is deprecated and only exists to ease code
1754	migration for code using ``[[noreturn]]`` after including ``<stdnoreturn.h>``.)reST";
1755
1756	static const char AttrDoc_CXXAssume[] = R"reST(The ``assume`` attribute is used to indicate to the optimizer that a
1757	certain condition is assumed to be true at a certain point in the
1758	program. If this condition is violated at runtime, the behavior is
1759	undefined. ``assume`` can only be applied to a null statement.
1760
1761	Different optimisers are likely to react differently to the presence of
1762	this attribute; in some cases, adding ``assume`` may affect performance
1763	negatively. It should be used with parsimony and care.
1764
1765	Example:
1766
1767	.. code-block:: c++
1768
1769	int f(int x, int y) {
1770	[[assume(x == 27)]];
1771	[[assume(x == y)]];
1772	return y + 1; // May be optimised to `return 28`.
1773	})reST";
1774
1775	static const char AttrDoc_CallableWhen[] = R"reST(Use ``__attribute__((callable_when(...)))`` to indicate what states a method
1776	may be called in. Valid states are unconsumed, consumed, or unknown. Each
1777	argument to this attribute must be a quoted string. E.g.:
1778
1779	``__attribute__((callable_when("unconsumed", "unknown")))``)reST";
1780
1781	static const char AttrDoc_Callback[] = R"reST(The ``callback`` attribute specifies that the annotated function may invoke the
1782	specified callback zero or more times. The callback, as well as the passed
1783	arguments, are identified by their parameter name or position (starting with
1784	1!) in the annotated function. The first position in the attribute identifies
1785	the callback callee, the following positions declare describe its arguments.
1786	The callback callee is required to be callable with the number, and order, of
1787	the specified arguments. The index ``0``, or the identifier ``this``, is used to
1788	represent an implicit "this" pointer in class methods. If there is no implicit
1789	"this" pointer it shall not be referenced. The index '-1', or the name "__",
1790	represents an unknown callback callee argument. This can be a value which is
1791	not present in the declared parameter list, or one that is, but is potentially
1792	inspected, captured, or modified. Parameter names and indices can be mixed in
1793	the callback attribute.
1794
1795	The ``callback`` attribute, which is directly translated to ``callback``
1796	metadata <http://llvm.org/docs/LangRef.html#callback-metadata>, make the
1797	connection between the call to the annotated function and the callback callee.
1798	This can enable interprocedural optimizations which were otherwise impossible.
1799	If a function parameter is mentioned in the ``callback`` attribute, through its
1800	position, it is undefined if that parameter is used for anything other than the
1801	actual callback. Inspected, captured, or modified parameters shall not be
1802	listed in the ``callback`` metadata.
1803
1804	Example encodings for the callback performed by ``pthread_create`` are shown
1805	below. The explicit attribute annotation indicates that the third parameter
1806	(``start_routine``) is called zero or more times by the ``pthread_create`` function,
1807	and that the fourth parameter (``arg``) is passed along. Note that the callback
1808	behavior of ``pthread_create`` is automatically recognized by Clang. In addition,
1809	the declarations of ``__kmpc_fork_teams`` and ``__kmpc_fork_call``, generated for
1810	``#pragma omp target teams`` and ``#pragma omp parallel``, respectively, are also
1811	automatically recognized as broker functions. Further functions might be added
1812	in the future.
1813
1814	.. code-block:: c
1815
1816	__attribute__((callback (start_routine, arg)))
1817	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1818	void (start_routine) (void ), void arg);
1819
1820	__attribute__((callback (3, 4)))
1821	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1822	void (start_routine) (void ), void arg);)reST";
1823
1824	static const char AttrDoc_CalledOnce[] = R"reST(The ``called_once`` attribute specifies that the annotated function or method
1825	parameter is invoked exactly once on all execution paths. It only applies
1826	to parameters with function-like types, i.e. function pointers or blocks. This
1827	concept is particularly useful for asynchronous programs.
1828
1829	Clang implements a check for ``called_once`` parameters,
1830	``-Wcalled-once-parameter``. It is on by default and finds the following
1831	violations:
1832
1833	* Parameter is not called at all.
1834
1835	* Parameter is called more than once.
1836
1837	* Parameter is not called on one of the execution paths.
1838
1839	In the latter case, Clang pinpoints the path where parameter is not invoked
1840	by showing the control-flow statement where the path diverges.
1841
1842	.. code-block:: objc
1843
1844	void fooWithCallback(void (^callback)(void) __attribute__((called_once))) {
1845	if (somePredicate()) {
1846	...
1847	callback();
1848	} else {
1849	callback(); // OK: callback is called on every path
1850	}
1851	}
1852
1853	void barWithCallback(void (^callback)(void) __attribute__((called_once))) {
1854	if (somePredicate()) {
1855	...
1856	callback(); // note: previous call is here
1857	}
1858	callback(); // warning: callback is called twice
1859	}
1860
1861	void foobarWithCallback(void (^callback)(void) __attribute__((called_once))) {
1862	if (somePredicate()) { // warning: callback is not called when condition is false
1863	...
1864	callback();
1865	}
1866	}
1867
1868	This attribute is useful for API developers who want to double-check if they
1869	implemented their method correctly.)reST";
1870
1871	static const char AttrDoc_Capability[] = R"reST(No documentation.)reST";
1872
1873	static const char AttrDoc_CapturedRecord[] = R"reST()reST";
1874
1875	static const char AttrDoc_CarriesDependency[] = R"reST(The ``carries_dependency`` attribute specifies dependency propagation into and
1876	out of functions.
1877
1878	When specified on a function or Objective-C method, the ``carries_dependency``
1879	attribute means that the return value carries a dependency out of the function,
1880	so that the implementation need not constrain ordering upon return from that
1881	function. Implementations of the function and its caller may choose to preserve
1882	dependencies instead of emitting memory ordering instructions such as fences.
1883
1884	Note, this attribute does not change the meaning of the program, but may result
1885	in generation of more efficient code.)reST";
1886
1887	static const char AttrDoc_Cleanup[] = R"reST(This attribute allows a function to be run when a local variable goes out of
1888	scope. The attribute takes the identifier of a function with a parameter type
1889	that is a pointer to the type with the attribute.
1890
1891	.. code-block:: c
1892
1893	static void foo (int *) { ... }
1894	static void bar (int *) { ... }
1895	void baz (void) {
1896	int x __attribute__((cleanup(foo)));
1897	{
1898	int y __attribute__((cleanup(bar)));
1899	}
1900	}
1901
1902	The above example will result in a call to ``bar`` being passed the address of
1903	``y`` when ``y`` goes out of scope, then a call to ``foo`` being passed the
1904	address of ``x`` when ``x`` goes out of scope. If two or more variables share
1905	the same scope, their ``cleanup`` callbacks are invoked in the reverse order
1906	the variables were declared in. It is not possible to check the return value
1907	(if any) of these ``cleanup`` callback functions.)reST";
1908
1909	static const char AttrDoc_ClspvLibclcBuiltin[] = R"reST(Attribute used by `clspv`_ (OpenCL-C to Vulkan SPIR-V compiler) to identify functions coming from `libclc`_ (OpenCL-C builtin library).
1910
1911	.. code-block:: c
1912
1913	void __attribute__((clspv_libclc_builtin)) libclc_builtin() {}
1914
1915	.. _`clspv`: https://github.com/google/clspv
1916	.. _`libclc`: https://libclc.llvm.org)reST";
1917
1918	static const char AttrDoc_CmseNSCall[] = R"reST(This attribute declares a non-secure function type. When compiling for secure
1919	state, a call to such a function would switch from secure to non-secure state.
1920	All non-secure function calls must happen only through a function pointer, and
1921	a non-secure function type should only be used as a base type of a pointer.
1922	See `ARMv8-M Security Extensions: Requirements on Development
1923	Tools - Engineering Specification Documentation
1924	<https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.)reST";
1925
1926	static const char AttrDoc_CmseNSEntry[] = R"reST(This attribute declares a function that can be called from non-secure state, or
1927	from secure state. Entering from and returning to non-secure state would switch
1928	to and from secure state, respectively, and prevent flow of information
1929	to non-secure state, except via return values. See `ARMv8-M Security Extensions:
1930	Requirements on Development Tools - Engineering Specification Documentation
1931	<https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.)reST";
1932
1933	static const char AttrDoc_CodeAlign[] = R"reST(The ``clang::code_align(N)`` attribute applies to a loop and specifies the byte
1934	alignment for a loop. The attribute accepts a positive integer constant
1935	initialization expression indicating the number of bytes for the minimum
1936	alignment boundary. Its value must be a power of 2, between 1 and 4096
1937	(inclusive).
1938
1939	.. code-block:: c++
1940
1941	void foo() {
1942	int var = 0;
1943	[[clang::code_align(16)]] for (int i = 0; i < 10; ++i) var++;
1944	}
1945
1946	void Array(int *array, size_t n) {
1947	[[clang::code_align(64)]] for (int i = 0; i < n; ++i) array[i] = 0;
1948	}
1949
1950	void count () {
1951	int a1[10], int i = 0;
1952	[[clang::code_align(32)]] while (i < 10) { a1[i] += 3; }
1953	}
1954
1955	void check() {
1956	int a = 10;
1957	[[clang::code_align(8)]] do {
1958	a = a + 1;
1959	} while (a < 20);
1960	}
1961
1962	template<int A>
1963	void func() {
1964	[[clang::code_align(A)]] for(;;) { }
1965	})reST";
1966
1967	static const char AttrDoc_CodeModel[] = R"reST(The ``model`` attribute allows overriding the translation unit's
1968	code model (specified by ``-mcmodel``) for a specific global variable.
1969
1970	On LoongArch, allowed values are "normal", "medium", "extreme".
1971
1972	On x86-64, allowed values are ``"small"`` and ``"large"``. ``"small"`` is
1973	roughly equivalent to ``-mcmodel=small``, meaning the global is considered
1974	"small" placed closer to the ``.text`` section relative to "large" globals, and
1975	to prefer using 32-bit relocations to access the global. ``"large"`` is roughly
1976	equivalent to ``-mcmodel=large``, meaning the global is considered "large" and
1977	placed further from the ``.text`` section relative to "small" globals, and
1978	64-bit relocations must be used to access the global.)reST";
1979
1980	static const char AttrDoc_CodeSeg[] = R"reST(The ``__declspec(code_seg)`` attribute enables the placement of code into separate
1981	named segments that can be paged or locked in memory individually. This attribute
1982	is used to control the placement of instantiated templates and compiler-generated
1983	code. See the documentation for `__declspec(code_seg)`_ on MSDN.
1984
1985	.. _`__declspec(code_seg)`: http://msdn.microsoft.com/en-us/library/dn636922.aspx)reST";
1986
1987	static const char AttrDoc_Cold[] = R"reST(``__attribute__((cold))`` marks a function as cold, as a manual alternative to PGO hotness data.
1988	If PGO data is available, the profile count based hotness overrides the ``__attribute__((cold))`` annotation (unlike ``__attribute__((hot))``).)reST";
1989
1990	static const char AttrDoc_Common[] = R"reST(No documentation.)reST";
1991
1992	static const char AttrDoc_Const[] = R"reST(No documentation.)reST";
1993
1994	static const char AttrDoc_ConstInit[] = R"reST(This attribute specifies that the variable to which it is attached is intended
1995	to have a `constant initializer <http://en.cppreference.com/w/cpp/language/constant_initialization>`_
1996	according to the rules of [basic.start.static]. The variable is required to
1997	have static or thread storage duration. If the initialization of the variable
1998	is not a constant initializer an error will be produced. This attribute may
1999	only be used in C++; the ``constinit`` spelling is only accepted in C++20
2000	onwards.
2001
2002	Note that in C++03 strict constant expression checking is not done. Instead
2003	the attribute reports if Clang can emit the variable as a constant, even if it's
2004	not technically a 'constant initializer'. This behavior is non-portable.
2005
2006	Static storage duration variables with constant initializers avoid hard-to-find
2007	bugs caused by the indeterminate order of dynamic initialization. They can also
2008	be safely used during dynamic initialization across translation units.
2009
2010	This attribute acts as a compile time assertion that the requirements
2011	for constant initialization have been met. Since these requirements change
2012	between dialects and have subtle pitfalls it's important to fail fast instead
2013	of silently falling back on dynamic initialization.
2014
2015	The first use of the attribute on a variable must be part of, or precede, the
2016	initializing declaration of the variable. C++20 requires the ``constinit``
2017	spelling of the attribute to be present on the initializing declaration if it
2018	is used anywhere. The other spellings can be specified on a forward declaration
2019	and omitted on a later initializing declaration.
2020
2021	.. code-block:: c++
2022
2023	// -std=c++14
2024	#define SAFE_STATIC [[clang::require_constant_initialization]]
2025	struct T {
2026	constexpr T(int) {}
2027	~T(); // non-trivial
2028	};
2029	SAFE_STATIC T x = {42}; // Initialization OK. Doesn't check destructor.
2030	SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
2031	// copy initialization is not a constant expression on a non-literal type.)reST";
2032
2033	static const char AttrDoc_Constructor[] = R"reST(The ``constructor`` attribute causes the function to be called before entering
2034	``main()``, and the ``destructor`` attribute causes the function to be called
2035	after returning from ``main()`` or when the ``exit()`` function has been
2036	called. Note, ``quick_exit()``, ``_Exit()``, and ``abort()`` prevent a function
2037	marked ``destructor`` from being called.
2038
2039	The constructor or destructor function should not accept any arguments and its
2040	return type should be ``void``.
2041
2042	The attributes accept an optional argument used to specify the priority order
2043	in which to execute constructor and destructor functions. The priority is
2044	given as an integer constant expression between 101 and 65535 (inclusive).
2045	Priorities outside of that range are reserved for use by the implementation. A
2046	lower value indicates a higher priority of initialization. Note that only the
2047	relative ordering of values is important. For example:
2048
2049	.. code-block:: c++
2050
2051	__attribute__((constructor(200))) void foo(void);
2052	__attribute__((constructor(101))) void bar(void);
2053
2054	``bar()`` will be called before ``foo()``, and both will be called before
2055	``main()``. If no argument is given to the ``constructor`` or ``destructor``
2056	attribute, they default to the value ``65535``.)reST";
2057
2058	static const char AttrDoc_Consumable[] = R"reST(Each ``class`` that uses any of the typestate annotations must first be marked
2059	using the ``consumable`` attribute. Failure to do so will result in a warning.
2060
2061	This attribute accepts a single parameter that must be one of the following:
2062	``unknown``, ``consumed``, or ``unconsumed``.)reST";
2063
2064	static const char AttrDoc_ConsumableAutoCast[] = R"reST(No documentation.)reST";
2065
2066	static const char AttrDoc_ConsumableSetOnRead[] = R"reST(No documentation.)reST";
2067
2068	static const char AttrDoc_Convergent[] = R"reST(The ``convergent`` attribute can be placed on a function declaration. It is
2069	translated into the LLVM ``convergent`` attribute, which indicates that the call
2070	instructions of a function with this attribute cannot be made control-dependent
2071	on any additional values.
2072
2073	This attribute is different from ``noduplicate`` because it allows duplicating
2074	function calls if it can be proved that the duplicated function calls are
2075	not made control-dependent on any additional values, e.g., unrolling a loop
2076	executed by all work items.
2077
2078	Sample usage:
2079
2080	.. code-block:: c
2081
2082	void convfunc(void) __attribute__((convergent));
2083	// Setting it as a C++11 attribute is also valid in a C++ program.
2084	// void convfunc(void) [[clang::convergent]];)reST";
2085
2086	static const char AttrDoc_CoroAwaitElidable[] = R"reST(The ``[[clang::coro_await_elidable]]`` is a class attribute which can be
2087	applied to a coroutine return type. It provides a hint to the compiler to apply
2088	Heap Allocation Elision more aggressively.
2089
2090	When a coroutine function returns such a type, a direct call expression therein
2091	that returns a prvalue of a type attributed ``[[clang::coro_await_elidable]]``
2092	is said to be under a safe elide context if one of the following is true:
2093	- it is the immediate right-hand side operand to a co_await expression.
2094	- it is an argument to a ``[[clang::coro_await_elidable_argument]]`` parameter
2095	or parameter pack of another direct call expression under a safe elide context.
2096
2097	Do note that the safe elide context applies only to the call expression itself,
2098	and the context does not transitively include any of its subexpressions unless
2099	exceptional rules of ``[[clang::coro_await_elidable_argument]]`` apply.
2100
2101	The compiler performs heap allocation elision on call expressions under a safe
2102	elide context, if the callee is a coroutine.
2103
2104	Example:
2105
2106	.. code-block:: c++
2107
2108	class [[clang::coro_await_elidable]] Task { ... };
2109
2110	Task foo();
2111	Task bar() {
2112	co_await foo(); // foo()'s coroutine frame on this line is elidable
2113	auto t = foo(); // foo()'s coroutine frame on this line is NOT elidable
2114	co_await t;
2115	}
2116
2117	Such elision replaces the heap allocated activation frame of the callee coroutine
2118	with a local variable within the enclosing braces in the caller's stack frame.
2119	The local variable, like other variables in coroutines, may be collected into the
2120	coroutine frame, which may be allocated on the heap. The behavior is undefined
2121	if the caller coroutine is destroyed earlier than the callee coroutine.)reST";
2122
2123	static const char AttrDoc_CoroAwaitElidableArgument[] = R"reST(The ``[[clang::coro_await_elidable_argument]]`` is a function parameter attribute.
2124	It works in conjunction with ``[[clang::coro_await_elidable]]`` to propagate a
2125	safe elide context to a parameter or parameter pack if the function is called
2126	under a safe elide context.
2127
2128	This is sometimes necessary on utility functions used to compose or modify the
2129	behavior of a callee coroutine.
2130
2131	Example:
2132
2133	.. code-block:: c++
2134
2135	template <typename T>
2136	class [[clang::coro_await_elidable]] Task { ... };
2137
2138	template <typename... T>
2139	class [[clang::coro_await_elidable]] WhenAll { ... };
2140
2141	// `when_all` is a utility function that composes coroutines. It does not
2142	// need to be a coroutine to propagate.
2143	template <typename... T>
2144	WhenAll<T...> when_all([[clang::coro_await_elidable_argument]] Task<T> tasks...);
2145
2146	Task<int> foo();
2147	Task<int> bar();
2148	Task<void> example1() {
2149	// `when_all``, `foo``, and `bar` are all elide safe because `when_all` is
2150	// under a safe elide context and, thanks to the [[clang::coro_await_elidable_argument]]
2151	// attribute, such context is propagated to foo and bar.
2152	co_await when_all(foo(), bar());
2153	}
2154
2155	Task<void> example2() {
2156	// `when_all` and `bar` are elide safe. `foo` is not elide safe.
2157	auto f = foo();
2158	co_await when_all(f, bar());
2159	}
2160
2161
2162	Task<void> example3() {
2163	// None of the calls are elide safe.
2164	auto t = when_all(foo(), bar());
2165	co_await t;
2166	})reST";
2167
2168	static const char AttrDoc_CoroDisableLifetimeBound[] = R"reST(The ``[[clang::coro_lifetimebound]]`` is a class attribute which can be applied
2169	to a coroutine return type (`coro_return_type, coro_wrapper`_) (i.e.
2170	it should also be annotated with ``[[clang::coro_return_type]]``).
2171
2172	All parameters of a function are considered to be lifetime bound if the function returns a
2173	coroutine return type (CRT) annotated with ``[[clang::coro_lifetimebound]]``.
2174	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
2175	with ``[[clang::coro_disable_lifetimebound]]`` function attribute .
2176	See documentation of `lifetimebound`_ for details about lifetime bound analysis.
2177
2178
2179	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
2180
2181	For example,
2182
2183	.. code-block:: c++
2184
2185	task<int> coro(const int& a) { co_return a + 1; }
2186	task<int> dangling_refs(int a) {
2187	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
2188	auto foo = coro(1);
2189	// `coro` captures reference to local variable `a` which is destroyed after the return.
2190	return coro(a);
2191	}
2192
2193	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
2194	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
2195	``[[clang::coro_lifetimebound]]``, then lifetime bound analysis would detect capturing reference to
2196	temporaries or return address of a local variable.
2197
2198	Both coroutines and coroutine wrappers are part of this analysis.
2199
2200	.. code-block:: c++
2201
2202	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
2203	using promise_type = some_promise_type;
2204	};
2205
2206	Task<int> coro(const int& a) { co_return a + 1; }
2207	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
2208	return a > b ? coro(a) : coro(b);
2209	}
2210	Task<int> temporary_reference() {
2211	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
2212
2213	int a = 1;
2214	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
2215
2216	co_return co_await coro(1); // fine.
2217	}
2218	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
2219	return coro(a); // warning: returning address of stack variable `a`.
2220	}
2221
2222	This analysis can be disabled for all calls to a particular function by annotating the function
2223	with function attribute ``[[clang::coro_disable_lifetimebound]]``.
2224	For example, this could be useful for coroutine wrappers which accept reference parameters
2225	but do not pass them to the underlying coroutine or pass them by value.
2226
2227	.. code-block:: c++
2228
2229	Task<int> coro(int a) { co_return a + 1; }
2230	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
2231	return coro(a + 1);
2232	}
2233	void use() {
2234	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
2235	})reST";
2236
2237	static const char AttrDoc_CoroLifetimeBound[] = R"reST(The ``[[clang::coro_lifetimebound]]`` is a class attribute which can be applied
2238	to a coroutine return type (`coro_return_type, coro_wrapper`_) (i.e.
2239	it should also be annotated with ``[[clang::coro_return_type]]``).
2240
2241	All parameters of a function are considered to be lifetime bound if the function returns a
2242	coroutine return type (CRT) annotated with ``[[clang::coro_lifetimebound]]``.
2243	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
2244	with ``[[clang::coro_disable_lifetimebound]]`` function attribute .
2245	See documentation of `lifetimebound`_ for details about lifetime bound analysis.
2246
2247
2248	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
2249
2250	For example,
2251
2252	.. code-block:: c++
2253
2254	task<int> coro(const int& a) { co_return a + 1; }
2255	task<int> dangling_refs(int a) {
2256	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
2257	auto foo = coro(1);
2258	// `coro` captures reference to local variable `a` which is destroyed after the return.
2259	return coro(a);
2260	}
2261
2262	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
2263	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
2264	``[[clang::coro_lifetimebound]]``, then lifetime bound analysis would detect capturing reference to
2265	temporaries or return address of a local variable.
2266
2267	Both coroutines and coroutine wrappers are part of this analysis.
2268
2269	.. code-block:: c++
2270
2271	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
2272	using promise_type = some_promise_type;
2273	};
2274
2275	Task<int> coro(const int& a) { co_return a + 1; }
2276	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
2277	return a > b ? coro(a) : coro(b);
2278	}
2279	Task<int> temporary_reference() {
2280	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
2281
2282	int a = 1;
2283	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
2284
2285	co_return co_await coro(1); // fine.
2286	}
2287	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
2288	return coro(a); // warning: returning address of stack variable `a`.
2289	}
2290
2291	This analysis can be disabled for all calls to a particular function by annotating the function
2292	with function attribute ``[[clang::coro_disable_lifetimebound]]``.
2293	For example, this could be useful for coroutine wrappers which accept reference parameters
2294	but do not pass them to the underlying coroutine or pass them by value.
2295
2296	.. code-block:: c++
2297
2298	Task<int> coro(int a) { co_return a + 1; }
2299	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
2300	return coro(a + 1);
2301	}
2302	void use() {
2303	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
2304	})reST";
2305
2306	static const char AttrDoc_CoroOnlyDestroyWhenComplete[] = R"reST(The `coro_only_destroy_when_complete` attribute should be marked on a C++ class. The coroutines
2307	whose return type is marked with the attribute are assumed to be destroyed only after the coroutine has
2308	reached the final suspend point.
2309
2310	This is helpful for the optimizers to reduce the size of the destroy function for the coroutines.
2311
2312	For example,
2313
2314	.. code-block:: c++
2315
2316	A foo() {
2317	dtor d;
2318	co_await something();
2319	dtor d1;
2320	co_await something();
2321	dtor d2;
2322	co_return 43;
2323	}
2324
2325	The compiler may generate the following pseudocode:
2326
2327	.. code-block:: c++
2328
2329	void foo.destroy(foo.Frame *frame) {
2330	switch(frame->suspend_index()) {
2331	case 1:
2332	frame->d.~dtor();
2333	break;
2334	case 2:
2335	frame->d.~dtor();
2336	frame->d1.~dtor();
2337	break;
2338	case 3:
2339	frame->d.~dtor();
2340	frame->d1.~dtor();
2341	frame->d2.~dtor();
2342	break;
2343	default: // coroutine completed or haven't started
2344	break;
2345	}
2346
2347	frame->promise.~promise_type();
2348	delete frame;
2349	}
2350
2351	The `foo.destroy()` function's purpose is to release all of the resources
2352	initialized for the coroutine when it is destroyed in a suspended state.
2353	However, if the coroutine is only ever destroyed at the final suspend state,
2354	the rest of the conditions are superfluous.
2355
2356	The user can use the `coro_only_destroy_when_complete` attributo suppress
2357	generation of the other destruction cases, optimizing the above `foo.destroy` to:
2358
2359	.. code-block:: c++
2360
2361	void foo.destroy(foo.Frame *frame) {
2362	frame->promise.~promise_type();
2363	delete frame;
2364	})reST";
2365
2366	static const char AttrDoc_CoroReturnType[] = R"reST(The ``[[clang::coro_return_type]]`` attribute is used to help static analyzers to recognize
2367	coroutines from the function signatures.
2368
2369	The ``coro_return_type`` attribute should be marked on a C++ class to mark it as
2370	a coroutine return type (CRT).
2371
2372	A function ``R func(P1, .., PN)`` has a coroutine return type (CRT) ``R`` if ``R``
2373	is marked by ``[[clang::coro_return_type]]`` and ``R`` has a promise type associated to it
2374	(i.e., std::coroutine_traits<R, P1, .., PN>::promise_type is a valid promise type).
2375
2376	If the return type of a function is a ``CRT`` then the function must be a coroutine.
2377	Otherwise the program is invalid. It is allowed for a non-coroutine to return a ``CRT``
2378	if the function is marked with ``[[clang::coro_wrapper]]``.
2379
2380	The ``[[clang::coro_wrapper]]`` attribute should be marked on a C++ function to mark it as
2381	a coroutine wrapper. A coroutine wrapper is a function which returns a ``CRT``,
2382	is not a coroutine itself and is marked with ``[[clang::coro_wrapper]]``.
2383
2384	Clang will enforce that all functions that return a ``CRT`` are either coroutines or marked
2385	with ``[[clang::coro_wrapper]]``. Clang will enforce this with an error.
2386
2387	From a language perspective, it is not possible to differentiate between a coroutine and a
2388	function returning a CRT by merely looking at the function signature.
2389
2390	Coroutine wrappers, in particular, are susceptible to capturing
2391	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2392	issues with coroutine wrappers.
2393
2394	For example,
2395
2396	.. code-block:: c++
2397
2398	// This is a CRT.
2399	template <typename T> struct [[clang::coro_return_type]] Task {
2400	using promise_type = some_promise_type;
2401	};
2402
2403	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2404	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2405
2406	// Fine for a coroutine wrapper to return a CRT.
2407	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2408
2409	void bar() {
2410	// Invalid. This intantiates a function which returns a CRT but is not marked as
2411	// a coroutine wrapper.
2412	std::function<Task<int>(int)> f = increment;
2413	}
2414
2415	Note: ``a_promise_type::get_return_object`` is exempted from this analysis as it is a necessary
2416	implementation detail of any coroutine library.)reST";
2417
2418	static const char AttrDoc_CoroWrapper[] = R"reST(The ``[[clang::coro_return_type]]`` attribute is used to help static analyzers to recognize
2419	coroutines from the function signatures.
2420
2421	The ``coro_return_type`` attribute should be marked on a C++ class to mark it as
2422	a coroutine return type (CRT).
2423
2424	A function ``R func(P1, .., PN)`` has a coroutine return type (CRT) ``R`` if ``R``
2425	is marked by ``[[clang::coro_return_type]]`` and ``R`` has a promise type associated to it
2426	(i.e., std::coroutine_traits<R, P1, .., PN>::promise_type is a valid promise type).
2427
2428	If the return type of a function is a ``CRT`` then the function must be a coroutine.
2429	Otherwise the program is invalid. It is allowed for a non-coroutine to return a ``CRT``
2430	if the function is marked with ``[[clang::coro_wrapper]]``.
2431
2432	The ``[[clang::coro_wrapper]]`` attribute should be marked on a C++ function to mark it as
2433	a coroutine wrapper. A coroutine wrapper is a function which returns a ``CRT``,
2434	is not a coroutine itself and is marked with ``[[clang::coro_wrapper]]``.
2435
2436	Clang will enforce that all functions that return a ``CRT`` are either coroutines or marked
2437	with ``[[clang::coro_wrapper]]``. Clang will enforce this with an error.
2438
2439	From a language perspective, it is not possible to differentiate between a coroutine and a
2440	function returning a CRT by merely looking at the function signature.
2441
2442	Coroutine wrappers, in particular, are susceptible to capturing
2443	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2444	issues with coroutine wrappers.
2445
2446	For example,
2447
2448	.. code-block:: c++
2449
2450	// This is a CRT.
2451	template <typename T> struct [[clang::coro_return_type]] Task {
2452	using promise_type = some_promise_type;
2453	};
2454
2455	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2456	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2457
2458	// Fine for a coroutine wrapper to return a CRT.
2459	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2460
2461	void bar() {
2462	// Invalid. This intantiates a function which returns a CRT but is not marked as
2463	// a coroutine wrapper.
2464	std::function<Task<int>(int)> f = increment;
2465	}
2466
2467	Note: ``a_promise_type::get_return_object`` is exempted from this analysis as it is a necessary
2468	implementation detail of any coroutine library.)reST";
2469
2470	static const char AttrDoc_CountedBy[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
2471	structure in C. The argument for the attribute is the name of a field member
2472	holding the count of elements in the flexible array. This information can be
2473	used to improve the results of the array bound sanitizer and the
2474	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
2475	within the same non-anonymous, enclosing struct as the flexible array member.
2476
2477	This example specifies that the flexible array member ``array`` has the number
2478	of elements allocated for it in ``count``:
2479
2480	.. code-block:: c
2481
2482	struct bar;
2483
2484	struct foo {
2485	size_t count;
2486	char other;
2487	struct bar *array[] __attribute__((counted_by(count)));
2488	};
2489
2490	This establishes a relationship between ``array`` and ``count``. Specifically,
2491	``array`` must have at least ``count`` number of elements available. It's the
2492	user's responsibility to ensure that this relationship is maintained through
2493	changes to the structure.
2494
2495	In the following example, the allocated array erroneously has fewer elements
2496	than what's specified by ``p->count``. This would result in an out-of-bounds
2497	access not being detected.
2498
2499	.. code-block:: c
2500
2501	#define SIZE_INCR 42
2502
2503	struct foo *p;
2504
2505	void foo_alloc(size_t count) {
2506	p = malloc(MAX(sizeof(struct foo),
2507	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2508	p->count = count + SIZE_INCR;
2509	}
2510
2511	The next example updates ``p->count``, but breaks the relationship requirement
2512	that ``p->array`` must have at least ``p->count`` number of elements available:
2513
2514	.. code-block:: c
2515
2516	#define SIZE_INCR 42
2517
2518	struct foo *p;
2519
2520	void foo_alloc(size_t count) {
2521	p = malloc(MAX(sizeof(struct foo),
2522	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2523	p->count = count;
2524	}
2525
2526	void use_foo(int index, int val) {
2527	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
2528	p->array[index] = val; /* The sanitizer can't properly check this access. */
2529	}
2530
2531	In this example, an update to ``p->count`` maintains the relationship
2532	requirement:
2533
2534	.. code-block:: c
2535
2536	void use_foo(int index, int val) {
2537	if (p->count == 0)
2538	return;
2539	--p->count;
2540	p->array[index] = val;
2541	})reST";
2542
2543	static const char AttrDoc_CountedByOrNull[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
2544	structure in C. The argument for the attribute is the name of a field member
2545	holding the count of elements in the flexible array. This information can be
2546	used to improve the results of the array bound sanitizer and the
2547	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
2548	within the same non-anonymous, enclosing struct as the flexible array member.
2549
2550	This example specifies that the flexible array member ``array`` has the number
2551	of elements allocated for it in ``count``:
2552
2553	.. code-block:: c
2554
2555	struct bar;
2556
2557	struct foo {
2558	size_t count;
2559	char other;
2560	struct bar *array[] __attribute__((counted_by(count)));
2561	};
2562
2563	This establishes a relationship between ``array`` and ``count``. Specifically,
2564	``array`` must have at least ``count`` number of elements available. It's the
2565	user's responsibility to ensure that this relationship is maintained through
2566	changes to the structure.
2567
2568	In the following example, the allocated array erroneously has fewer elements
2569	than what's specified by ``p->count``. This would result in an out-of-bounds
2570	access not being detected.
2571
2572	.. code-block:: c
2573
2574	#define SIZE_INCR 42
2575
2576	struct foo *p;
2577
2578	void foo_alloc(size_t count) {
2579	p = malloc(MAX(sizeof(struct foo),
2580	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2581	p->count = count + SIZE_INCR;
2582	}
2583
2584	The next example updates ``p->count``, but breaks the relationship requirement
2585	that ``p->array`` must have at least ``p->count`` number of elements available:
2586
2587	.. code-block:: c
2588
2589	#define SIZE_INCR 42
2590
2591	struct foo *p;
2592
2593	void foo_alloc(size_t count) {
2594	p = malloc(MAX(sizeof(struct foo),
2595	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2596	p->count = count;
2597	}
2598
2599	void use_foo(int index, int val) {
2600	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
2601	p->array[index] = val; /* The sanitizer can't properly check this access. */
2602	}
2603
2604	In this example, an update to ``p->count`` maintains the relationship
2605	requirement:
2606
2607	.. code-block:: c
2608
2609	void use_foo(int index, int val) {
2610	if (p->count == 0)
2611	return;
2612	--p->count;
2613	p->array[index] = val;
2614	})reST";
2615
2616	static const char AttrDoc_DLLExport[] = R"reST(The ``__declspec(dllexport)`` attribute declares a variable, function, or
2617	Objective-C interface to be exported from the module. It is available under the
2618	``-fdeclspec`` flag for compatibility with various compilers. The primary use
2619	is for COFF object files which explicitly specify what interfaces are available
2620	for external use. See the dllexport_ documentation on MSDN for more
2621	information.
2622
2623	.. _dllexport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2624
2625	static const char AttrDoc_DLLExportOnDecl[] = R"reST()reST";
2626
2627	static const char AttrDoc_DLLExportStaticLocal[] = R"reST()reST";
2628
2629	static const char AttrDoc_DLLImport[] = R"reST(The ``__declspec(dllimport)`` attribute declares a variable, function, or
2630	Objective-C interface to be imported from an external module. It is available
2631	under the ``-fdeclspec`` flag for compatibility with various compilers. The
2632	primary use is for COFF object files which explicitly specify what interfaces
2633	are imported from external modules. See the dllimport_ documentation on MSDN
2634	for more information.
2635
2636	Note that a dllimport function may still be inlined, if its definition is
2637	available and it doesn't reference any non-dllimport functions or global
2638	variables.
2639
2640	.. _dllimport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2641
2642	static const char AttrDoc_DLLImportStaticLocal[] = R"reST()reST";
2643
2644	static const char AttrDoc_Deprecated[] = R"reST(The ``deprecated`` attribute can be applied to a function, a variable, or a
2645	type. This is useful when identifying functions, variables, or types that are
2646	expected to be removed in a future version of a program.
2647
2648	Consider the function declaration for a hypothetical function ``f``:
2649
2650	.. code-block:: c++
2651
2652	void f(void) __attribute__((deprecated("message", "replacement")));
2653
2654	When spelled as ``__attribute__((deprecated))``, the deprecated attribute can have
2655	two optional string arguments. The first one is the message to display when
2656	emitting the warning; the second one enables the compiler to provide a Fix-It
2657	to replace the deprecated name with a new name. Otherwise, when spelled as
2658	``[[gnu::deprecated]]`` or ``[[deprecated]]``, the attribute can have one optional
2659	string argument which is the message to display when emitting the warning.)reST";
2660
2661	static const char AttrDoc_Destructor[] = R"reST(The ``constructor`` attribute causes the function to be called before entering
2662	``main()``, and the ``destructor`` attribute causes the function to be called
2663	after returning from ``main()`` or when the ``exit()`` function has been
2664	called. Note, ``quick_exit()``, ``_Exit()``, and ``abort()`` prevent a function
2665	marked ``destructor`` from being called.
2666
2667	The constructor or destructor function should not accept any arguments and its
2668	return type should be ``void``.
2669
2670	The attributes accept an optional argument used to specify the priority order
2671	in which to execute constructor and destructor functions. The priority is
2672	given as an integer constant expression between 101 and 65535 (inclusive).
2673	Priorities outside of that range are reserved for use by the implementation. A
2674	lower value indicates a higher priority of initialization. Note that only the
2675	relative ordering of values is important. For example:
2676
2677	.. code-block:: c++
2678
2679	__attribute__((constructor(200))) void foo(void);
2680	__attribute__((constructor(101))) void bar(void);
2681
2682	``bar()`` will be called before ``foo()``, and both will be called before
2683	``main()``. If no argument is given to the ``constructor`` or ``destructor``
2684	attribute, they default to the value ``65535``.)reST";
2685
2686	static const char AttrDoc_DeviceKernel[] = R"reST(These attributes specify that the function represents a kernel for device offloading.
2687	The specific semantics depend on the offloading language, target, and attribute spelling.
2688	Here is a code example using the attribute to mark a function as a kernel:
2689
2690	.. code-block:: c++
2691
2692	[[clang::device_kernel]] int foo(int x) { return ++x; })reST";
2693
2694	static const char AttrDoc_DiagnoseAsBuiltin[] = R"reST(The ``diagnose_as_builtin`` attribute indicates that Fortify diagnostics are to
2695	be applied to the declared function as if it were the function specified by the
2696	attribute. The builtin function whose diagnostics are to be mimicked should be
2697	given. In addition, the order in which arguments should be applied must also
2698	be given.
2699
2700	For example, the attribute can be used as follows.
2701
2702	.. code-block:: c
2703
2704	__attribute__((diagnose_as_builtin(__builtin_memset, 3, 2, 1)))
2705	void mymemset(int n, int c, void s) {
2706	// ...
2707	}
2708
2709	This indicates that calls to ``mymemset`` should be diagnosed as if they were
2710	calls to ``__builtin_memset``. The arguments ``3, 2, 1`` indicate by index the
2711	order in which arguments of ``mymemset`` should be applied to
2712	``__builtin_memset``. The third argument should be applied first, then the
2713	second, and then the first. Thus (when Fortify warnings are enabled) the call
2714	``mymemset(n, c, s)`` will diagnose overflows as if it were the call
2715	``__builtin_memset(s, c, n)``.
2716
2717	For variadic functions, the variadic arguments must come in the same order as
2718	they would to the builtin function, after all normal arguments. For instance,
2719	to diagnose a new function as if it were `sscanf`, we can use the attribute as
2720	follows.
2721
2722	.. code-block:: c
2723
2724	__attribute__((diagnose_as_builtin(sscanf, 1, 2)))
2725	int mysscanf(const char str, const char format, ...) {
2726	// ...
2727	}
2728
2729	Then the call `mysscanf("abc def", "%4s %4s", buf1, buf2)` will be diagnosed as
2730	if it were the call `sscanf("abc def", "%4s %4s", buf1, buf2)`.
2731
2732	This attribute cannot be applied to non-static member functions.)reST";
2733
2734	static const char AttrDoc_DiagnoseIf[] = R"reST(The ``diagnose_if`` attribute can be placed on function declarations to emit
2735	warnings or errors at compile-time if calls to the attributed function meet
2736	certain user-defined criteria. For example:
2737
2738	.. code-block:: c
2739
2740	int abs(int a)
2741	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "warning")));
2742	int must_abs(int a)
2743	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "error")));
2744
2745	int val = abs(1); // warning: Redundant abs call
2746	int val2 = must_abs(1); // error: Redundant abs call
2747	int val3 = abs(val);
2748	int val4 = must_abs(val); // Because run-time checks are not emitted for
2749	// diagnose_if attributes, this executes without
2750	// issue.
2751
2752
2753	``diagnose_if`` is closely related to ``enable_if``, with a few key differences:
2754
2755	* Overload resolution is not aware of ``diagnose_if`` attributes: they're
2756	considered only after we select the best candidate from a given candidate set.
2757	* Function declarations that differ only in their ``diagnose_if`` attributes are
2758	considered to be redeclarations of the same function (not overloads).
2759	* If the condition provided to ``diagnose_if`` cannot be evaluated, no
2760	diagnostic will be emitted.
2761
2762	Otherwise, ``diagnose_if`` is essentially the logical negation of ``enable_if``.
2763
2764	As a result of bullet number two, ``diagnose_if`` attributes will stack on the
2765	same function. For example:
2766
2767	.. code-block:: c
2768
2769	int foo() __attribute__((diagnose_if(1, "diag1", "warning")));
2770	int foo() __attribute__((diagnose_if(1, "diag2", "warning")));
2771
2772	int bar = foo(); // warning: diag1
2773	// warning: diag2
2774	int (*fooptr)(void) = foo; // warning: diag1
2775	// warning: diag2
2776
2777	constexpr int supportsAPILevel(int N) { return N < 5; }
2778	int baz(int a)
2779	__attribute__((diagnose_if(!supportsAPILevel(10),
2780	"Upgrade to API level 10 to use baz", "error")));
2781	int baz(int a)
2782	__attribute__((diagnose_if(!a, "0 is not recommended.", "warning")));
2783
2784	int (*bazptr)(int) = baz; // error: Upgrade to API level 10 to use baz
2785	int v = baz(0); // error: Upgrade to API level 10 to use baz
2786
2787	Query for this feature with ``__has_attribute(diagnose_if)``.)reST";
2788
2789	static const char AttrDoc_DisableSanitizerInstrumentation[] = R"reST(Use the ``disable_sanitizer_instrumentation`` attribute on a function,
2790	Objective-C method, or global variable, to specify that no sanitizer
2791	instrumentation should be applied.
2792
2793	This is not the same as ``__attribute__((no_sanitize(...)))``, which depending
2794	on the tool may still insert instrumentation to prevent false positive reports.)reST";
2795
2796	static const char AttrDoc_DisableTailCalls[] = R"reST(The ``disable_tail_calls`` attribute instructs the backend to not perform tail
2797	call optimization inside the marked function.
2798
2799	For example:
2800
2801	.. code-block:: c
2802
2803	int callee(int);
2804
2805	int foo(int a) __attribute__((disable_tail_calls)) {
2806	return callee(a); // This call is not tail-call optimized.
2807	}
2808
2809	Marking virtual functions as ``disable_tail_calls`` is legal.
2810
2811	.. code-block:: c++
2812
2813	int callee(int);
2814
2815	class Base {
2816	public:
2817	[[clang::disable_tail_calls]] virtual int foo1() {
2818	return callee(); // This call is not tail-call optimized.
2819	}
2820	};
2821
2822	class Derived1 : public Base {
2823	public:
2824	int foo1() override {
2825	return callee(); // This call is tail-call optimized.
2826	}
2827	};)reST";
2828
2829	static const char AttrDoc_EmptyBases[] = R"reST(The empty_bases attribute permits the compiler to utilize the
2830	empty-base-optimization more frequently.
2831	This attribute only applies to struct, class, and union types.
2832	It is only supported when using the Microsoft C++ ABI.)reST";
2833
2834	static const char AttrDoc_EnableIf[] = R"reST(.. Note:: Some features of this attribute are experimental. The meaning of
2835	multiple enable_if attributes on a single declaration is subject to change in
2836	a future version of clang. Also, the ABI is not standardized and the name
2837	mangling may change in future versions. To avoid that, use asm labels.
2838
2839	The ``enable_if`` attribute can be placed on function declarations to control
2840	which overload is selected based on the values of the function's arguments.
2841	When combined with the ``overloadable`` attribute, this feature is also
2842	available in C.
2843
2844	.. code-block:: c++
2845
2846	int isdigit(int c);
2847	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")));
2848
2849	void foo(char c) {
2850	isdigit(c);
2851	isdigit(10);
2852	isdigit(-10); // results in a compile-time error.
2853	}
2854
2855	The enable_if attribute takes two arguments, the first is an expression written
2856	in terms of the function parameters, the second is a string explaining why this
2857	overload candidate could not be selected to be displayed in diagnostics. The
2858	expression is part of the function signature for the purposes of determining
2859	whether it is a redeclaration (following the rules used when determining
2860	whether a C++ template specialization is ODR-equivalent), but is not part of
2861	the type.
2862
2863	The enable_if expression is evaluated as if it were the body of a
2864	bool-returning constexpr function declared with the arguments of the function
2865	it is being applied to, then called with the parameters at the call site. If the
2866	result is false or could not be determined through constant expression
2867	evaluation, then this overload will not be chosen and the provided string may
2868	be used in a diagnostic if the compile fails as a result.
2869
2870	Because the enable_if expression is an unevaluated context, there are no global
2871	state changes, nor the ability to pass information from the enable_if
2872	expression to the function body. For example, suppose we want calls to
2873	strnlen(strbuf, maxlen) to resolve to strnlen_chk(strbuf, maxlen, size of
2874	strbuf) only if the size of strbuf can be determined:
2875
2876	.. code-block:: c++
2877
2878	__attribute__((always_inline))
2879	static inline size_t strnlen(const char *s, size_t maxlen)
2880	__attribute__((overloadable))
2881	__attribute__((enable_if(__builtin_object_size(s, 0) != -1))),
2882	"chosen when the buffer size is known but 'maxlen' is not")))
2883	{
2884	return strnlen_chk(s, maxlen, __builtin_object_size(s, 0));
2885	}
2886
2887	Multiple enable_if attributes may be applied to a single declaration. In this
2888	case, the enable_if expressions are evaluated from left to right in the
2889	following manner. First, the candidates whose enable_if expressions evaluate to
2890	false or cannot be evaluated are discarded. If the remaining candidates do not
2891	share ODR-equivalent enable_if expressions, the overload resolution is
2892	ambiguous. Otherwise, enable_if overload resolution continues with the next
2893	enable_if attribute on the candidates that have not been discarded and have
2894	remaining enable_if attributes. In this way, we pick the most specific
2895	overload out of a number of viable overloads using enable_if.
2896
2897	.. code-block:: c++
2898
2899	void f() __attribute__((enable_if(true, ""))); // #1
2900	void f() __attribute__((enable_if(true, ""))) __attribute__((enable_if(true, ""))); // #2
2901
2902	void g(int i, int j) __attribute__((enable_if(i, ""))); // #1
2903	void g(int i, int j) __attribute__((enable_if(j, ""))) __attribute__((enable_if(true))); // #2
2904
2905	In this example, a call to f() is always resolved to #2, as the first enable_if
2906	expression is ODR-equivalent for both declarations, but #1 does not have another
2907	enable_if expression to continue evaluating, so the next round of evaluation has
2908	only a single candidate. In a call to g(1, 1), the call is ambiguous even though
2909	#2 has more enable_if attributes, because the first enable_if expressions are
2910	not ODR-equivalent.
2911
2912	Query for this feature with ``__has_attribute(enable_if)``.
2913
2914	Note that functions with one or more ``enable_if`` attributes may not have
2915	their address taken, unless all of the conditions specified by said
2916	``enable_if`` are constants that evaluate to ``true``. For example:
2917
2918	.. code-block:: c
2919
2920	const int TrueConstant = 1;
2921	const int FalseConstant = 0;
2922	int f(int a) __attribute__((enable_if(a > 0, "")));
2923	int g(int a) __attribute__((enable_if(a == 0 \|\| a != 0, "")));
2924	int h(int a) __attribute__((enable_if(1, "")));
2925	int i(int a) __attribute__((enable_if(TrueConstant, "")));
2926	int j(int a) __attribute__((enable_if(FalseConstant, "")));
2927
2928	void fn() {
2929	int (*ptr)(int);
2930	ptr = &f; // error: 'a > 0' is not always true
2931	ptr = &g; // error: 'a == 0 \|\| a != 0' is not a truthy constant
2932	ptr = &h; // OK: 1 is a truthy constant
2933	ptr = &i; // OK: 'TrueConstant' is a truthy constant
2934	ptr = &j; // error: 'FalseConstant' is a constant, but not truthy
2935	}
2936
2937	Because ``enable_if`` evaluation happens during overload resolution,
2938	``enable_if`` may give unintuitive results when used with templates, depending
2939	on when overloads are resolved. In the example below, clang will emit a
2940	diagnostic about no viable overloads for ``foo`` in ``bar``, but not in ``baz``:
2941
2942	.. code-block:: c++
2943
2944	double foo(int i) __attribute__((enable_if(i > 0, "")));
2945	void *foo(int i) __attribute__((enable_if(i <= 0, "")));
2946	template <int I>
2947	auto bar() { return foo(I); }
2948
2949	template <typename T>
2950	auto baz() { return foo(T::number); }
2951
2952	struct WithNumber { constexpr static int number = 1; };
2953	void callThem() {
2954	bar<sizeof(WithNumber)>();
2955	baz<WithNumber>();
2956	}
2957
2958	This is because, in ``bar``, ``foo`` is resolved prior to template
2959	instantiation, so the value for ``I`` isn't known (thus, both ``enable_if``
2960	conditions for ``foo`` fail). However, in ``baz``, ``foo`` is resolved during
2961	template instantiation, so the value for ``T::number`` is known.)reST";
2962
2963	static const char AttrDoc_EnforceTCB[] = R"reST(The ``enforce_tcb`` attribute can be placed on functions to enforce that a
2964	trusted compute base (TCB) does not call out of the TCB. This generates a
2965	warning every time a function not marked with an ``enforce_tcb`` attribute is
2966	called from a function with the ``enforce_tcb`` attribute. A function may be a
2967	part of multiple TCBs. Invocations through function pointers are currently
2968	not checked. Builtins are considered to a part of every TCB.
2969
2970	- ``enforce_tcb(Name)`` indicates that this function is a part of the TCB named ``Name``)reST";
2971
2972	static const char AttrDoc_EnforceTCBLeaf[] = R"reST(The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
2973	``enforce_tcb`` for the marked function to be in the named TCB but does not
2974	continue to check the functions called from within the leaf function.
2975
2976	- ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the TCB named ``Name``)reST";
2977
2978	static const char AttrDoc_EnumExtensibility[] = R"reST(Attribute ``enum_extensibility`` is used to distinguish between enum definitions
2979	that are extensible and those that are not. The attribute can take either
2980	``closed`` or ``open`` as an argument. ``closed`` indicates a variable of the
2981	enum type takes a value that corresponds to one of the enumerators listed in the
2982	enum definition or, when the enum is annotated with ``flag_enum``, a value that
2983	can be constructed using values corresponding to the enumerators. ``open``
2984	indicates a variable of the enum type can take any values allowed by the
2985	standard and instructs clang to be more lenient when issuing warnings.
2986
2987	.. code-block:: c
2988
2989	enum __attribute__((enum_extensibility(closed))) ClosedEnum {
2990	A0, A1
2991	};
2992
2993	enum __attribute__((enum_extensibility(open))) OpenEnum {
2994	B0, B1
2995	};
2996
2997	enum __attribute__((enum_extensibility(closed),flag_enum)) ClosedFlagEnum {
2998	C0 = 1 << 0, C1 = 1 << 1
2999	};
3000
3001	enum __attribute__((enum_extensibility(open),flag_enum)) OpenFlagEnum {
3002	D0 = 1 << 0, D1 = 1 << 1
3003	};
3004
3005	void foo1() {
3006	enum ClosedEnum ce;
3007	enum OpenEnum oe;
3008	enum ClosedFlagEnum cfe;
3009	enum OpenFlagEnum ofe;
3010
3011	ce = A1; // no warnings
3012	ce = 100; // warning issued
3013	oe = B1; // no warnings
3014	oe = 100; // no warnings
3015	cfe = C0 \| C1; // no warnings
3016	cfe = C0 \| C1 \| 4; // warning issued
3017	ofe = D0 \| D1; // no warnings
3018	ofe = D0 \| D1 \| 4; // no warnings
3019	})reST";
3020
3021	static const char AttrDoc_Error[] = R"reST(The ``error`` and ``warning`` function attributes can be used to specify a
3022	custom diagnostic to be emitted when a call to such a function is not
3023	eliminated via optimizations. This can be used to create compile time
3024	assertions that depend on optimizations, while providing diagnostics
3025	pointing to precise locations of the call site in the source.
3026
3027	.. code-block:: c++
3028
3029	__attribute__((warning("oh no"))) void dontcall();
3030	void foo() {
3031	if (someCompileTimeAssertionThatsTrue)
3032	dontcall(); // Warning
3033
3034	dontcall(); // Warning
3035
3036	if (someCompileTimeAssertionThatsFalse)
3037	dontcall(); // No Warning
3038	sizeof(dontcall()); // No Warning
3039	})reST";
3040
3041	static const char AttrDoc_ExcludeFromExplicitInstantiation[] = R"reST(The ``exclude_from_explicit_instantiation`` attribute opts-out a member of a
3042	class template from being part of explicit template instantiations of that
3043	class template. This means that an explicit instantiation will not instantiate
3044	members of the class template marked with the attribute, but also that code
3045	where an extern template declaration of the enclosing class template is visible
3046	will not take for granted that an external instantiation of the class template
3047	would provide those members (which would otherwise be a link error, since the
3048	explicit instantiation won't provide those members). For example, let's say we
3049	don't want the ``data()`` method to be part of libc++'s ABI. To make sure it
3050	is not exported from the dylib, we give it hidden visibility:
3051
3052	.. code-block:: c++
3053
3054	// in <string>
3055	template <class CharT>
3056	class basic_string {
3057	public:
3058	__attribute__((__visibility__("hidden")))
3059	const value_type* data() const noexcept { ... }
3060	};
3061
3062	template class basic_string<char>;
3063
3064	Since an explicit template instantiation declaration for ``basic_string<char>``
3065	is provided, the compiler is free to assume that ``basic_string<char>::data()``
3066	will be provided by another translation unit, and it is free to produce an
3067	external call to this function. However, since ``data()`` has hidden visibility
3068	and the explicit template instantiation is provided in a shared library (as
3069	opposed to simply another translation unit), ``basic_string<char>::data()``
3070	won't be found and a link error will ensue. This happens because the compiler
3071	assumes that ``basic_string<char>::data()`` is part of the explicit template
3072	instantiation declaration, when it really isn't. To tell the compiler that
3073	``data()`` is not part of the explicit template instantiation declaration, the
3074	``exclude_from_explicit_instantiation`` attribute can be used:
3075
3076	.. code-block:: c++
3077
3078	// in <string>
3079	template <class CharT>
3080	class basic_string {
3081	public:
3082	__attribute__((__visibility__("hidden")))
3083	__attribute__((exclude_from_explicit_instantiation))
3084	const value_type* data() const noexcept { ... }
3085	};
3086
3087	template class basic_string<char>;
3088
3089	Now, the compiler won't assume that ``basic_string<char>::data()`` is provided
3090	externally despite there being an explicit template instantiation declaration:
3091	the compiler will implicitly instantiate ``basic_string<char>::data()`` in the
3092	TUs where it is used.
3093
3094	This attribute can be used on static and non-static member functions of class
3095	templates, static data members of class templates and member classes of class
3096	templates.)reST";
3097
3098	static const char AttrDoc_ExplicitInit[] = R"reST(The ``clang::require_explicit_initialization`` attribute indicates that a
3099	field of an aggregate must be initialized explicitly by the user when an object
3100	of the aggregate type is constructed. The attribute supports both C and C++,
3101	but its usage is invalid on non-aggregates.
3102
3103	Note that this attribute is not a memory safety feature, and is not intended
3104	to guard against use of uninitialized memory.
3105
3106	Rather, it is intended for use in "parameter-objects", used to simulate,
3107	for example, the passing of named parameters.
3108	Except inside unevaluated contexts, the attribute generates a warning when
3109	explicit initializers for such variables are not provided (this occurs
3110	regardless of whether any in-class field initializers exist):
3111
3112	.. code-block:: c++
3113
3114	struct Buffer {
3115	void *address [[clang::require_explicit_initialization]];
3116	size_t length [[clang::require_explicit_initialization]] = 0;
3117	};
3118
3119	struct ArrayIOParams {
3120	size_t count [[clang::require_explicit_initialization]];
3121	size_t element_size [[clang::require_explicit_initialization]];
3122	int flags = 0;
3123	};
3124
3125	size_t ReadArray(FILE *file, struct Buffer buffer,
3126	struct ArrayIOParams params);
3127
3128	int main() {
3129	unsigned int buf[512];
3130	ReadArray(stdin, {
3131	buf
3132	// warning: field 'length' is not explicitly initialized
3133	}, {
3134	.count = sizeof(buf) / sizeof(*buf),
3135	// warning: field 'element_size' is not explicitly initialized
3136	// (Note that a missing initializer for 'flags' is not diagnosed, because
3137	// the field is not marked as requiring explicit initialization.)
3138	});
3139	})reST";
3140
3141	static const char AttrDoc_ExtVectorType[] = R"reST(The ``ext_vector_type(N)`` attribute specifies that a type is a vector with N
3142	elements, directly mapping to an LLVM vector type. Originally from OpenCL, it
3143	allows element access the array subscript operator ``[]``, ``sN`` where N is
3144	a hexadecimal value, or ``x, y, z, w`` for graphics-style indexing.
3145	This attribute enables efficient SIMD operations and is usable in
3146	general-purpose code.
3147
3148	.. code-block:: c++
3149
3150	template <typename T, uint32_t N>
3151	constexpr T simd_reduce(T [[clang::ext_vector_type(N)]] v) {
3152	static_assert((N & (N - 1)) == 0, "N must be a power of two");
3153	if constexpr (N == 1)
3154	return v[0];
3155	else
3156	return simd_reduce<T, N / 2>(v.hi + v.lo);
3157	}
3158
3159	The vector type also supports swizzling up to sixteen elements. This can be done
3160	using the object accessors. The OpenCL documentation lists all of the accepted
3161	values.
3162
3163	.. code-block:: c++
3164
3165	using f16_x16 = _Float16 __attribute__((ext_vector_type(16)));
3166
3167	f16_x16 reverse(f16_x16 v) { return v.sfedcba9876543210; }
3168
3169	See the OpenCL documentation for some more complete examples.)reST";
3170
3171	static const char AttrDoc_ExternalSourceSymbol[] = R"reST(The ``external_source_symbol`` attribute specifies that a declaration originates
3172	from an external source and describes the nature of that source.
3173
3174	The fact that Clang is capable of recognizing declarations that were defined
3175	externally can be used to provide better tooling support for mixed-language
3176	projects or projects that rely on auto-generated code. For instance, an IDE that
3177	uses Clang and that supports mixed-language projects can use this attribute to
3178	provide a correct 'jump-to-definition' feature. For a concrete example,
3179	consider a protocol that's defined in a Swift file:
3180
3181	.. code-block:: swift
3182
3183	@objc public protocol SwiftProtocol {
3184	func method()
3185	}
3186
3187	This protocol can be used from Objective-C code by including a header file that
3188	was generated by the Swift compiler. The declarations in that header can use
3189	the ``external_source_symbol`` attribute to make Clang aware of the fact
3190	that ``SwiftProtocol`` actually originates from a Swift module:
3191
3192	.. code-block:: objc
3193
3194	__attribute__((external_source_symbol(language="Swift",defined_in="module")))
3195	@protocol SwiftProtocol
3196	@required
3197	- (void) method;
3198	@end
3199
3200	Consequently, when 'jump-to-definition' is performed at a location that
3201	references ``SwiftProtocol``, the IDE can jump to the original definition in
3202	the Swift source file rather than jumping to the Objective-C declaration in the
3203	auto-generated header file.
3204
3205	The ``external_source_symbol`` attribute is a comma-separated list that includes
3206	clauses that describe the origin and the nature of the particular declaration.
3207	Those clauses can be:
3208
3209	language=\ string-literal
3210	The name of the source language in which this declaration was defined.
3211
3212	defined_in=\ string-literal
3213	The name of the source container in which the declaration was defined. The
3214	exact definition of source container is language-specific, e.g. Swift's
3215	source containers are modules, so ``defined_in`` should specify the Swift
3216	module name.
3217
3218	USR=\ string-literal
3219	String that specifies a unified symbol resolution (USR) value for this
3220	declaration. USR string uniquely identifies this particular declaration, and
3221	is typically used when constructing an index of a codebase.
3222	The USR value in this attribute is expected to be generated by an external
3223	compiler that compiled the native declaration using its original source
3224	language. The exact format of the USR string and its other attributes
3225	are determined by the specification of this declaration's source language.
3226	When not specified, Clang's indexer will use the Clang USR for this symbol.
3227	User can query to see if Clang supports the use of the ``USR`` clause in
3228	the ``external_source_symbol`` attribute with
3229	``__has_attribute(external_source_symbol) >= 20230206``.
3230
3231	generated_declaration
3232	This declaration was automatically generated by some tool.
3233
3234	The clauses can be specified in any order. The clauses that are listed above are
3235	all optional, but the attribute has to have at least one clause.)reST";
3236
3237	static const char AttrDoc_FallThrough[] = R"reST(The ``fallthrough`` (or ``clang::fallthrough``) attribute is used
3238	to annotate intentional fall-through
3239	between switch labels. It can only be applied to a null statement placed at a
3240	point of execution between any statement and the next switch label. It is
3241	common to mark these places with a specific comment, but this attribute is
3242	meant to replace comments with a more strict annotation, which can be checked
3243	by the compiler. This attribute doesn't change semantics of the code and can
3244	be used wherever an intended fall-through occurs. It is designed to mimic
3245	control-flow statements like ``break;``, so it can be placed in most places
3246	where ``break;`` can, but only if there are no statements on the execution path
3247	between it and the next switch label.
3248
3249	By default, Clang does not warn on unannotated fallthrough from one ``switch``
3250	case to another. Diagnostics on fallthrough without a corresponding annotation
3251	can be enabled with the ``-Wimplicit-fallthrough`` argument.
3252
3253	Here is an example:
3254
3255	.. code-block:: c++
3256
3257	// compile with -Wimplicit-fallthrough
3258	switch (n) {
3259	case 22:
3260	case 33: // no warning: no statements between case labels
3261	f();
3262	case 44: // warning: unannotated fall-through
3263	g();
3264	[[clang::fallthrough]];
3265	case 55: // no warning
3266	if (x) {
3267	h();
3268	break;
3269	}
3270	else {
3271	i();
3272	[[clang::fallthrough]];
3273	}
3274	case 66: // no warning
3275	p();
3276	[[clang::fallthrough]]; // warning: fallthrough annotation does not
3277	// directly precede case label
3278	q();
3279	case 77: // warning: unannotated fall-through
3280	r();
3281	})reST";
3282
3283	static const char AttrDoc_FastCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
3284	function to use ECX and EDX as register parameters and clear parameters off of
3285	the stack on return. This convention does not support variadic calls or
3286	unprototyped functions in C, and has no effect on x86_64 targets. This calling
3287	convention is supported primarily for compatibility with existing code. Users
3288	seeking register parameters should use the ``regparm`` attribute, which does
3289	not require callee-cleanup. See the documentation for `__fastcall`_ on MSDN.
3290
3291	.. _`__fastcall`: http://msdn.microsoft.com/en-us/library/6xa169sk.aspx)reST";
3292
3293	static const char AttrDoc_Final[] = R"reST()reST";
3294
3295	static const char AttrDoc_FlagEnum[] = R"reST(This attribute can be added to an enumerator to signal to the compiler that it
3296	is intended to be used as a flag type. This will cause the compiler to assume
3297	that the range of the type includes all of the values that you can get by
3298	manipulating bits of the enumerator when issuing warnings.)reST";
3299
3300	static const char AttrDoc_Flatten[] = R"reST(The ``flatten`` attribute causes calls within the attributed function to
3301	be inlined unless it is impossible to do so, for example if the body of the
3302	callee is unavailable or if the callee has the ``noinline`` attribute.)reST";
3303
3304	static const char AttrDoc_Format[] = R"reST(Clang supports the ``format`` attribute, which indicates that the function
3305	accepts (among other possibilities) a ``printf`` or ``scanf``-like format string
3306	and corresponding arguments or a ``va_list`` that contains these arguments.
3307
3308	Please see `GCC documentation about format attribute
3309	<http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>`_ to find details
3310	about attribute syntax.
3311
3312	Clang implements two kinds of checks with this attribute.
3313
3314	#. Clang checks that the function with the ``format`` attribute is called with
3315	a format string that uses format specifiers that are allowed, and that
3316	arguments match the format string. This is the ``-Wformat`` warning, it is
3317	on by default.
3318
3319	#. Clang checks that the format string argument is a literal string. This is
3320	the ``-Wformat-nonliteral`` warning, it is off by default.
3321
3322	Clang implements this mostly the same way as GCC, but there is a difference
3323	for functions that accept a ``va_list`` argument (for example, ``vprintf``).
3324	GCC does not emit ``-Wformat-nonliteral`` warning for calls to such
3325	functions. Clang does not warn if the format string comes from a function
3326	parameter, where the function is annotated with a compatible attribute,
3327	otherwise it warns. For example:
3328
3329	.. code-block:: c
3330
3331	__attribute__((__format__ (__scanf__, 1, 3)))
3332	void foo(const char* s, char *buf, ...) {
3333	va_list ap;
3334	va_start(ap, buf);
3335
3336	vprintf(s, ap); // warning: format string is not a string literal
3337	}
3338
3339	In this case we warn because ``s`` contains a format string for a
3340	``scanf``-like function, but it is passed to a ``printf``-like function.
3341
3342	If the attribute is removed, clang still warns, because the format string is
3343	not a string literal.
3344
3345	Another example:
3346
3347	.. code-block:: c
3348
3349	__attribute__((__format__ (__printf__, 1, 3)))
3350	void foo(const char* s, char *buf, ...) {
3351	va_list ap;
3352	va_start(ap, buf);
3353
3354	vprintf(s, ap); // warning
3355	}
3356
3357	In this case Clang does not warn because the format string ``s`` and
3358	the corresponding arguments are annotated. If the arguments are
3359	incorrect, the caller of ``foo`` will receive a warning.
3360
3361	As an extension to GCC's behavior, Clang accepts the ``format`` attribute on
3362	non-variadic functions. Clang checks non-variadic format functions for the same
3363	classes of issues that can be found on variadic functions, as controlled by the
3364	same warning flags, except that the types of formatted arguments is forced by
3365	the function signature. For example:
3366
3367	.. code-block:: c
3368
3369	__attribute__((__format__(__printf__, 1, 2)))
3370	void fmt(const char s, const char a, int b);
3371
3372	void bar(void) {
3373	fmt("%s %i", "hello", 123); // OK
3374	fmt("%i %g", "hello", 123); // warning: arguments don't match format
3375	extern const char *fmt;
3376	fmt(fmt, "hello", 123); // warning: format string is not a string literal
3377	}
3378
3379	When using the format attribute on a variadic function, the first data parameter
3380	_must_ be the index of the ellipsis in the parameter list. Clang will generate
3381	a diagnostic otherwise, as it wouldn't be possible to forward that argument list
3382	to `printf`-family functions. For instance, this is an error:
3383
3384	.. code-block:: c
3385
3386	__attribute__((__format__(__printf__, 1, 2)))
3387	void fmt(const char *s, int b, ...);
3388	// ^ error: format attribute parameter 3 is out of bounds
3389	// (must be __printf__, 1, 3)
3390
3391	Using the ``format`` attribute on a non-variadic function emits a GCC
3392	compatibility diagnostic.)reST";
3393
3394	static const char AttrDoc_FormatArg[] = R"reST(No documentation.)reST";
3395
3396	static const char AttrDoc_FormatMatches[] = R"reST(The ``format`` attribute is the basis for the enforcement of diagnostics in the
3397	``-Wformat`` family, but it only handles the case where the format string is
3398	passed along with the arguments it is going to format. It cannot handle the case
3399	where the format string and the format arguments are passed separately from each
3400	other. For instance:
3401
3402	.. code-block:: c
3403
3404	static const char *first_name;
3405	static double todays_temperature;
3406	static int wind_speed;
3407
3408	void say_hi(const char *fmt) {
3409	printf(fmt, first_name, todays_temperature);
3410	// ^ warning: format string is not a string literal
3411	printf(fmt, first_name, wind_speed);
3412	// ^ warning: format string is not a string literal
3413	}
3414
3415	int main() {
3416	say_hi("hello %s, it is %g degrees outside");
3417	say_hi("hello %s, it is %d degrees outside!");
3418	// ^ no diagnostic, but %d cannot format doubles
3419	}
3420
3421	In this example, ``fmt`` is expected to format a ``const char *`` and a
3422	``double``, but these values are not passed to ``say_hi``. Without the
3423	``format`` attribute (which cannot apply in this case), the -Wformat-nonliteral
3424	diagnostic unnecessarily triggers in the body of ``say_hi``, and incorrect
3425	``say_hi`` call sites do not trigger a diagnostic.
3426
3427	To complement the ``format`` attribute, Clang also defines the
3428	``format_matches`` attribute. Its syntax is similar to the ``format``
3429	attribute's, but instead of taking the index of the first formatted value
3430	argument, it takes a C string literal with the expected specifiers:
3431
3432	.. code-block:: c
3433
3434	static const char *first_name;
3435	static double todays_temperature;
3436	static int wind_speed;
3437
3438	__attribute__((__format_matches__(printf, 1, "%s %g")))
3439	void say_hi(const char *fmt) {
3440	printf(fmt, first_name, todays_temperature); // no dignostic
3441	printf(fmt, first_name, wind_speed); // warning: format specifies type 'int' but the argument has type 'double'
3442	}
3443
3444	int main() {
3445	say_hi("hello %s, it is %g degrees outside");
3446	say_hi("it is %g degrees outside, have a good day %s!");
3447	// warning: format specifies 'double' where 'const char *' is required
3448	// warning: format specifies 'const char *' where 'double' is required
3449	}
3450
3451	The third argument to ``format_matches`` is expected to evaluate to a **C string
3452	literal** even when the format string would normally be a different type for the
3453	given flavor, like a ``CFStringRef`` or a ``NSString *``.
3454
3455	The only requirement on the format string literal is that it has specifiers
3456	that are compatible with the arguments that will be used. It can contain
3457	arbitrary non-format characters. For instance, for the purposes of compile-time
3458	validation, ``"%s scored %g%% on her test"`` and ``"%s%g"`` are interchangeable
3459	as the format string argument. As a means of self-documentation, users may
3460	prefer the former when it provides a useful example of an expected format
3461	string.
3462
3463	In the implementation of a function with the ``format_matches`` attribute,
3464	format verification works as if the format string was identical to the one
3465	specified in the attribute.
3466
3467	.. code-block:: c
3468
3469	__attribute__((__format_matches__(printf, 1, "%s %g")))
3470	void say_hi(const char *fmt) {
3471	printf(fmt, "person", 546);
3472	// ^ warning: format specifies type 'double' but the
3473	// argument has type 'int'
3474	// note: format string is defined here:
3475	// __attribute__((__format_matches__(printf, 1, "%s %g")))
3476	// ^~
3477	}
3478
3479
3480	At the call sites of functions with the ``format_matches`` attribute, format
3481	verification instead compares the two format strings to evaluate their
3482	equivalence. Each format flavor defines equivalence between format specifiers.
3483	Generally speaking, two specifiers are equivalent if they format the same type.
3484	For instance, in the ``printf`` flavor, ``%2i`` and ``%-0.5d`` are compatible.
3485	When ``-Wformat-signedness`` is disabled, ``%d`` and ``%u`` are compatible. For
3486	a negative example, ``%ld`` is incompatible with ``%d``.
3487
3488	Do note the following un-obvious cases:
3489
3490	* Passing ``NULL`` as the format string does not trigger format diagnostics.
3491	* When the format string is not NULL, it cannot _miss_ specifiers, even in
3492	trailing positions. For instance, ``%d`` is not accepted when the required
3493	format is ``%d %d %d``.
3494	* While checks for the ``format`` attribute tolerate sone size mismatches
3495	that standard argument promotion renders immaterial (such as formatting an
3496	``int`` with ``%hhd``, which specifies a ``char``-sized integer), checks for
3497	``format_matches`` require specified argument sizes to match exactly.
3498	* Format strings expecting a variable modifier (such as ``%*s``) are
3499	incompatible with format strings that would itemize the variable modifiers
3500	(such as ``%i %s``), even if the two specify ABI-compatible argument lists.
3501	* All pointer specifiers, modifiers aside, are mutually incompatible. For
3502	instance, ``%s`` is not compatible with ``%p``, and ``%p`` is not compatible
3503	with ``%n``, and ``%hhn`` is incompatible with ``%s``, even if the pointers
3504	are ABI-compatible or identical on the selected platform. However, ``%0.5s``
3505	is compatible with ``%s``, since the difference only exists in modifier flags.
3506	This is not overridable with ``-Wformat-pedantic`` or its inverse, which
3507	control similar behavior in ``-Wformat``.
3508
3509	At this time, clang implements ``format_matches`` only for format types in the
3510	``printf`` family. This includes variants such as Apple's NSString format and
3511	the FreeBSD ``kprintf``, but excludes ``scanf``. Using a known but unsupported
3512	format silently fails in order to be compatible with other implementations that
3513	would support these formats.)reST";
3514
3515	static const char AttrDoc_FunctionReturnThunks[] = R"reST(The attribute ``function_return`` can replace return instructions with jumps to
3516	target-specific symbols. This attribute supports 2 possible values,
3517	corresponding to the values supported by the ``-mfunction-return=`` command
3518	line flag:
3519
3520	* ``__attribute__((function_return("keep")))`` to disable related transforms.
3521	This is useful for undoing global setting from ``-mfunction-return=`` locally
3522	for individual functions.
3523	* ``__attribute__((function_return("thunk-extern")))`` to replace returns with
3524	jumps, while NOT emitting the thunk.
3525
3526	The values ``thunk`` and ``thunk-inline`` from GCC are not supported.
3527
3528	The symbol used for ``thunk-extern`` is target specific:
3529	* X86: ``__x86_return_thunk``
3530
3531	As such, this function attribute is currently only supported on X86 targets.)reST";
3532
3533	static const char AttrDoc_GCCStruct[] = R"reST(The ``ms_struct`` and ``gcc_struct`` attributes request the compiler to enter a
3534	special record layout compatibility mode which mimics the layout of Microsoft or
3535	Itanium C++ ABI respectively. Obviously, if the current C++ ABI matches the
3536	requested ABI, the attribute does nothing. However, if it does not, annotated
3537	structure or class is laid out in a special compatibility mode, which slightly
3538	changes offsets for fields and bit-fields. The intention is to match the layout
3539	of the requested ABI for structures which only use C features.
3540
3541	Note that the default behavior can be controlled by ``-mms-bitfields`` and
3542	``-mno-ms-bitfields`` switches and via ``#pragma ms_struct``.
3543
3544	The primary difference is for bitfields, where the MS variant only packs
3545	adjacent fields into the same allocation unit if they have integral types
3546	of the same size, while the GCC/Itanium variant packs all fields in a bitfield
3547	tightly.)reST";
3548
3549	static const char AttrDoc_GNUInline[] = R"reST(The ``gnu_inline`` changes the meaning of ``extern inline`` to use GNU inline
3550	semantics, meaning:
3551
3552	* If any declaration that is declared ``inline`` is not declared ``extern``,
3553	then the ``inline`` keyword is just a hint. In particular, an out-of-line
3554	definition is still emitted for a function with external linkage, even if all
3555	call sites are inlined, unlike in C99 and C++ inline semantics.
3556
3557	* If all declarations that are declared ``inline`` are also declared
3558	``extern``, then the function body is present only for inlining and no
3559	out-of-line version is emitted.
3560
3561	Some important consequences: ``static inline`` emits an out-of-line
3562	version if needed, a plain ``inline`` definition emits an out-of-line version
3563	always, and an ``extern inline`` definition (in a header) followed by a
3564	(non-``extern``) ``inline`` declaration in a source file emits an out-of-line
3565	version of the function in that source file but provides the function body for
3566	inlining to all includers of the header.
3567
3568	Either ``__GNUC_GNU_INLINE__`` (GNU inline semantics) or
3569	``__GNUC_STDC_INLINE__`` (C99 semantics) will be defined (they are mutually
3570	exclusive). If ``__GNUC_STDC_INLINE__`` is defined, then the ``gnu_inline``
3571	function attribute can be used to get GNU inline semantics on a per function
3572	basis. If ``__GNUC_GNU_INLINE__`` is defined, then the translation unit is
3573	already being compiled with GNU inline semantics as the implied default. It is
3574	unspecified which macro is defined in a C++ compilation.
3575
3576	GNU inline semantics are the default behavior with ``-std=gnu89``,
3577	``-std=c89``, ``-std=c94``, or ``-fgnu89-inline``.)reST";
3578
3579	static const char AttrDoc_GuardedBy[] = R"reST(No documentation.)reST";
3580
3581	static const char AttrDoc_GuardedVar[] = R"reST(No documentation.)reST";
3582
3583	static const char AttrDoc_HIPManaged[] = R"reST(The ``__managed__`` attribute can be applied to a global variable declaration in HIP.
3584	A managed variable is emitted as an undefined global symbol in the device binary and is
3585	registered by ``__hipRegisterManagedVariable`` in init functions. The HIP runtime allocates
3586	managed memory and uses it to define the symbol when loading the device binary.
3587	A managed variable can be accessed in both device and host code.)reST";
3588
3589	static const char AttrDoc_HLSLAppliedSemantic[] = R"reST()reST";
3590
3591	static const char AttrDoc_HLSLContainedType[] = R"reST()reST";
3592
3593	static const char AttrDoc_HLSLControlFlowHint[] = R"reST()reST";
3594
3595	static const char AttrDoc_HLSLGroupSharedAddressSpace[] = R"reST(HLSL enables threads of a compute shader to exchange values via shared memory.
3596	HLSL provides barrier primitives such as GroupMemoryBarrierWithGroupSync,
3597	and so on to ensure the correct ordering of reads and writes to shared memory
3598	in the shader and to avoid data races.
3599	Here's an example to declare a groupshared variable.
3600	.. code-block:: c++
3601
3602	groupshared GSData data[551];
3603
3604	The full documentation is available here: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-syntax#group-shared)reST";
3605
3606	static const char AttrDoc_HLSLIsCounter[] = R"reST()reST";
3607
3608	static const char AttrDoc_HLSLLoopHint[] = R"reST(The ``[loop]`` directive allows loop optimization hints to be
3609	specified for the subsequent loop. The directive allows unrolling to
3610	be disabled and is not compatible with [unroll(x)].
3611
3612	Specifying the parameter, ``[loop]``, directs the
3613	unroller to not unroll the loop.
3614
3615	.. code-block:: hlsl
3616
3617	[loop]
3618	for (...) {
3619	...
3620	}
3621
3622	.. code-block:: hlsl
3623
3624	[loop]
3625	while (...) {
3626	...
3627	}
3628
3629	.. code-block:: hlsl
3630
3631	[loop]
3632	do {
3633	...
3634	} while (...)
3635
3636	See `hlsl loop extensions <https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-for>`_
3637	for details.)reST";
3638
3639	static const char AttrDoc_HLSLNumThreads[] = R"reST(The ``numthreads`` attribute applies to HLSL shaders where explcit thread counts
3640	are required. The ``X``, ``Y``, and ``Z`` values provided to the attribute
3641	dictate the thread id. Total number of threads executed is ``X * Y * Z``.
3642
3643	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sm5-attributes-numthreads)reST";
3644
3645	static const char AttrDoc_HLSLPackOffset[] = R"reST(The packoffset attribute is used to change the layout of a cbuffer.
3646	Attribute spelling in HLSL is: ``packoffset( c[Subcomponent][.component] )``.
3647	A subcomponent is a register number, which is an integer. A component is in the form of [.xyzw].
3648
3649	Examples:
3650
3651	.. code-block:: hlsl
3652
3653	cbuffer A {
3654	float3 a : packoffset(c0.y);
3655	float4 b : packoffset(c4);
3656	}
3657
3658	The full documentation is available here: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-packoffset)reST";
3659
3660	static const char AttrDoc_HLSLParamModifier[] = R"reST(HLSL function parameters are passed by value. Parameter declarations support
3661	three qualifiers to denote parameter passing behavior. The three qualifiers are
3662	`in`, `out` and `inout`.
3663
3664	Parameters annotated with `in` or with no annotation are passed by value from
3665	the caller to the callee.
3666
3667	Parameters annotated with `out` are written to the argument after the callee
3668	returns (Note: arguments values passed into `out` parameters are not copied
3669	into the callee).
3670
3671	Parameters annotated with `inout` are copied into the callee via a temporary,
3672	and copied back to the argument after the callee returns.)reST";
3673
3674	static const char AttrDoc_HLSLParsedSemantic[] = R"reST()reST";
3675
3676	static const char AttrDoc_HLSLROV[] = R"reST()reST";
3677
3678	static const char AttrDoc_HLSLRawBuffer[] = R"reST()reST";
3679
3680	static const char AttrDoc_HLSLResourceBinding[] = R"reST(The resource binding attribute sets the virtual register and logical register space for a resource.
3681	Attribute spelling in HLSL is: ``register(slot [, space])``.
3682	``slot`` takes the format ``[type][number]``,
3683	where ``type`` is a single character specifying the resource type and ``number`` is the virtual register number.
3684
3685	Register types are:
3686	t for shader resource views (SRV),
3687	s for samplers,
3688	u for unordered access views (UAV),
3689	b for constant buffer views (CBV).
3690
3691	Register space is specified in the format ``space[number]`` and defaults to ``space0`` if omitted.
3692	Here're resource binding examples with and without space:
3693
3694	.. code-block:: hlsl
3695
3696	RWBuffer<float> Uav : register(u3, space1);
3697	Buffer<float> Buf : register(t1);
3698
3699	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl)reST";
3700
3701	static const char AttrDoc_HLSLResourceClass[] = R"reST()reST";
3702
3703	static const char AttrDoc_HLSLResourceDimension[] = R"reST()reST";
3704
3705	static const char AttrDoc_HLSLShader[] = R"reST(The ``shader`` type attribute applies to HLSL shader entry functions to
3706	identify the shader type for the entry function.
3707	The syntax is:
3708
3709	.. code-block:: text
3710
3711	``[shader(string-literal)]``
3712
3713	where the string literal is one of: "pixel", "vertex", "geometry", "hull",
3714	"domain", "compute", "raygeneration", "intersection", "anyhit", "closesthit",
3715	"miss", "callable", "mesh", "amplification". Normally the shader type is set
3716	by shader target with the ``-T`` option like ``-Tps_6_1``. When compiling to a
3717	library target like ``lib_6_3``, the shader type attribute can help the
3718	compiler to identify the shader type. It is mostly used by Raytracing shaders
3719	where shaders must be compiled into a library and linked at runtime.)reST";
3720
3721	static const char AttrDoc_HLSLUnparsedSemantic[] = R"reST()reST";
3722
3723	static const char AttrDoc_HLSLVkBinding[] = R"reST(The ``[[vk::binding]]`` attribute allows you to explicitly specify the descriptor
3724	set and binding for a resource when targeting SPIR-V. This is particularly
3725	useful when you need different bindings for SPIR-V and DXIL, as the ``register``
3726	attribute can be used for DXIL-specific bindings.
3727
3728	The attribute takes two integer arguments: the binding and the descriptor set.
3729	The descriptor set is optional and defaults to 0 if not provided.
3730
3731	.. code-block:: c++
3732
3733	// A structured buffer with binding 23 in descriptor set 102.
3734	[[vk::binding(23, 102)]] StructuredBuffer<float> Buf;
3735
3736	// A structured buffer with binding 14 in descriptor set 0.
3737	[[vk::binding(14)]] StructuredBuffer<float> Buf2;
3738
3739	// A cbuffer with binding 1 in descriptor set 2.
3740	[[vk::binding(1, 2)]] cbuffer MyCBuffer {
3741	float4x4 worldViewProj;
3742	};)reST";
3743
3744	static const char AttrDoc_HLSLVkConstantId[] = R"reST(The ``vk::constant_id`` attribute specifies the id for a SPIR-V specialization
3745	constant. The attribute applies to const global scalar variables. The variable must be initialized with a C++11 constexpr.
3746	In SPIR-V, the
3747	variable will be replaced with an `OpSpecConstant` with the given id.
3748	The syntax is:
3749
3750	.. code-block:: text
3751
3752	``[[vk::constant_id(<Id>)]] const T Name = <Init>``)reST";
3753
3754	static const char AttrDoc_HLSLVkExtBuiltinInput[] = R"reST(Vulkan shaders have `Input` builtins. Those variables are externally
3755	initialized by the driver/pipeline, but each copy is private to the current
3756	lane.
3757
3758	Those builtins can be declared using the `[[vk::ext_builtin_input]]` attribute
3759	like follows:
3760
3761	.. code-block:: c++
3762
3763	[[vk::ext_builtin_input(/* WorkgroupId */ 26)]]
3764	static const uint3 groupid;
3765
3766	This variable will be lowered into a module-level variable, with the `Input`
3767	storage class, and the `BuiltIn 26` decoration.
3768
3769	The full documentation for this inline SPIR-V attribute can be found here:
3770	https://github.com/microsoft/hlsl-specs/blob/main/proposals/0011-inline-spirv.md)reST";
3771
3772	static const char AttrDoc_HLSLVkLocation[] = R"reST(Attribute used for specifying the location number for the stage input/output
3773	variables. Allowed on function parameters, function returns, and struct
3774	fields. This parameter has no effect when used outside of an entrypoint
3775	parameter/parameter field/return value.
3776
3777	This attribute maps to the 'Location' SPIR-V decoration.)reST";
3778
3779	static const char AttrDoc_HLSLVkPushConstant[] = R"reST(Vulkan shaders have `PushConstants`
3780
3781	The ``[[vk::push_constant]]`` attribute allows you to declare this
3782	global variable as a push constant when targeting Vulkan.
3783	This attribute is ignored otherwise.
3784
3785	This attribute must be applied to the variable, not underlying type.
3786	The variable type must be a struct, per the requirements of Vulkan, "there
3787	must be no more than one push constant block statically used per shader entry
3788	point.")reST";
3789
3790	static const char AttrDoc_HLSLWaveSize[] = R"reST(The ``WaveSize`` attribute specify a wave size on a shader entry point in order
3791	to indicate either that a shader depends on or strongly prefers a specific wave
3792	size.
3793	There're 2 versions of the attribute: ``WaveSize`` and ``RangedWaveSize``.
3794	The syntax for ``WaveSize`` is:
3795
3796	.. code-block:: text
3797
3798	``[WaveSize(<numLanes>)]``
3799
3800	The allowed wave sizes that an HLSL shader may specify are the powers of 2
3801	between 4 and 128, inclusive.
3802	In other words, the set: [4, 8, 16, 32, 64, 128].
3803
3804	The syntax for ``RangedWaveSize`` is:
3805
3806	.. code-block:: text
3807
3808	``[WaveSize(<minWaveSize>, <maxWaveSize>, [prefWaveSize])]``
3809
3810	Where minWaveSize is the minimum wave size supported by the shader representing
3811	the beginning of the allowed range, maxWaveSize is the maximum wave size
3812	supported by the shader representing the end of the allowed range, and
3813	prefWaveSize is the optional preferred wave size representing the size expected
3814	to be the most optimal for this shader.
3815
3816	``WaveSize`` is available for HLSL shader model 6.6 and later.
3817	``RangedWaveSize`` available for HLSL shader model 6.8 and later.
3818
3819	The full documentation is available here: https://microsoft.github.io/DirectX-Specs/d3d/HLSL_SM_6_6_WaveSize.html
3820	and https://microsoft.github.io/hlsl-specs/proposals/0013-wave-size-range.html)reST";
3821
3822	static const char AttrDoc_Hot[] = R"reST(``__attribute__((hot))`` marks a function as hot, as a manual alternative to PGO hotness data.
3823	If PGO data is available, the annotation ``__attribute__((hot))`` overrides the profile count based hotness (unlike ``__attribute__((cold))``).)reST";
3824
3825	static const char AttrDoc_HybridPatchable[] = R"reST(The ``hybrid_patchable`` attribute declares an ARM64EC function with an additional
3826	x86-64 thunk, which may be patched at runtime.
3827
3828	For more information see
3829	`ARM64EC ABI documentation <https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi>`_.)reST";
3830
3831	static const char AttrDoc_IBAction[] = R"reST(No documentation.)reST";
3832
3833	static const char AttrDoc_IBOutlet[] = R"reST(No documentation.)reST";
3834
3835	static const char AttrDoc_IBOutletCollection[] = R"reST(No documentation.)reST";
3836
3837	static const char AttrDoc_IFunc[] = R"reST(``__attribute__((ifunc("resolver")))`` is used to mark that the address of a
3838	declaration should be resolved at runtime by calling a resolver function.
3839
3840	The symbol name of the resolver function is given in quotes. A function with
3841	this name (after mangling) must be defined in the current translation unit; it
3842	may be ``static``. The resolver function should return a pointer.
3843
3844	The ``ifunc`` attribute may only be used on a function declaration. A function
3845	declaration with an ``ifunc`` attribute is considered to be a definition of the
3846	declared entity. The entity must not have weak linkage; for example, in C++,
3847	it cannot be applied to a declaration if a definition at that location would be
3848	considered inline.
3849
3850	Not all targets support this attribute:
3851
3852	- ELF target support depends on both the linker and runtime linker, and is
3853	available in at least lld 4.0 and later, binutils 2.20.1 and later, glibc
3854	v2.11.1 and later, and FreeBSD 9.1 and later.
3855	- Mach-O targets support it, but with slightly different semantics: the resolver
3856	is run at first call, instead of at load time by the runtime linker.
3857	- Windows target supports it on AArch64, but with different semantics: the
3858	``ifunc`` is replaced with a global function pointer, and the call is replaced
3859	with an indirect call. The function pointer is initialized by a constructor
3860	that calls the resolver.
3861	- Baremetal target supports it on AVR.
3862	- AIX/XCOFF supports it via a compiler-only solution. An ifunc appears as a
3863	regular function (has an entry point ``.foo[PR]`` and a function descriptor
3864	``foo[DS]``). The entry point is a stub that branches to the function address
3865	in the descriptor, and the descriptor is initialized via a constructor
3866	function (``__init_ifuncs``) that is linked into every shared object and
3867	executable. ``__init_ifuncs`` calls the resolver of each ifunc and stores the
3868	result in the corresponding descriptor.
3869	- Other targets currently do not support this attribute.)reST";
3870
3871	static const char AttrDoc_InferredNoReturn[] = R"reST()reST";
3872
3873	static const char AttrDoc_InitPriority[] = R"reST(In C++, the order in which global variables are initialized across translation
3874	units is unspecified, unlike the ordering within a single translation unit. The
3875	``init_priority`` attribute allows you to specify a relative ordering for the
3876	initialization of objects declared at namespace scope in C++ within a single
3877	linked image on supported platforms. The priority is given as an integer constant
3878	expression between 101 and 65535 (inclusive). Priorities outside of that range are
3879	reserved for use by the implementation. A lower value indicates a higher priority
3880	of initialization. Note that only the relative ordering of values is important.
3881	For example:
3882
3883	.. code-block:: c++
3884
3885	struct SomeType { SomeType(); };
3886	__attribute__((init_priority(200))) SomeType Obj1;
3887	__attribute__((init_priority(101))) SomeType Obj2;
3888
3889	``Obj2`` will be initialized before ``Obj1`` despite the usual order of
3890	initialization being the opposite.
3891
3892	Note that this attribute does not control the initialization order of objects
3893	across final linked image boundaries like shared objects and executables.
3894
3895	On Windows, ``init_seg(compiler)`` is represented with a priority of 200 and
3896	``init_seg(library)`` is represented with a priority of 400. ``init_seg(user)``
3897	uses the default 65535 priority.
3898
3899	On MachO platforms, this attribute also does not control the order of initialization
3900	across translation units, where it only affects the order within a single TU.
3901
3902	This attribute is only supported for C++ and Objective-C++ and is ignored in
3903	other language modes. Currently, this attribute is not implemented on z/OS.)reST";
3904
3905	static const char AttrDoc_InitSeg[] = R"reST(The attribute applied by ``pragma init_seg()`` controls the section into
3906	which global initialization function pointers are emitted. It is only
3907	available with ``-fms-extensions``. Typically, this function pointer is
3908	emitted into ``.CRT$XCU`` on Windows. The user can change the order of
3909	initialization by using a different section name with the same
3910	``.CRT$XC`` prefix and a suffix that sorts lexicographically before or
3911	after the standard ``.CRT$XCU`` sections. See the init_seg_
3912	documentation on MSDN for more information.
3913
3914	.. _init_seg: http://msdn.microsoft.com/en-us/library/7977wcck(v=vs.110).aspx)reST";
3915
3916	static const char AttrDoc_IntelOclBicc[] = R"reST(No documentation.)reST";
3917
3918	static const char AttrDoc_InternalLinkage[] = R"reST(The ``internal_linkage`` attribute changes the linkage type of the declaration
3919	to internal. This is similar to C-style ``static``, but can be used on classes
3920	and class methods. When applied to a class definition, this attribute affects
3921	all methods and static data members of that class. This can be used to contain
3922	the ABI of a C++ library by excluding unwanted class methods from the export
3923	tables.)reST";
3924
3925	static const char AttrDoc_LTOVisibilityPublic[] = R"reST(See :doc:`LTOVisibility`.)reST";
3926
3927	static const char AttrDoc_LayoutVersion[] = R"reST(The layout_version attribute requests that the compiler utilize the class
3928	layout rules of a particular compiler version.
3929	This attribute only applies to struct, class, and union types.
3930	It is only supported when using the Microsoft C++ ABI.)reST";
3931
3932	static const char AttrDoc_Leaf[] = R"reST(The ``leaf`` attribute is used as a compiler hint to improve dataflow analysis
3933	in library functions. Functions marked with the ``leaf`` attribute are not allowed
3934	to jump back into the caller's translation unit, whether through invoking a
3935	callback function, an external function call, use of ``longjmp``, or other means.
3936	Therefore, they cannot use or modify any data that does not escape the caller function's
3937	compilation unit.
3938
3939	For more information see
3940	`gcc documentation <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html>`)reST";
3941
3942	static const char AttrDoc_LifetimeBound[] = R"reST(The ``lifetimebound`` attribute on a function parameter or implicit object
3943	parameter indicates that objects that are referred to by that parameter may
3944	also be referred to by the return value of the annotated function (or, for a
3945	parameter of a constructor, by the value of the constructed object).
3946
3947	By default, a reference is considered to refer to its referenced object, a
3948	pointer is considered to refer to its pointee, a ``std::initializer_list<T>``
3949	is considered to refer to its underlying array, and aggregates (arrays and
3950	simple ``struct``\s) are considered to refer to all objects that their
3951	transitive subobjects refer to.
3952
3953	Clang warns if it is able to detect that an object or reference refers to
3954	another object with a shorter lifetime. For example, Clang will warn if a
3955	function returns a reference to a local variable, or if a reference is bound to
3956	a temporary object whose lifetime is not extended. By using the
3957	``lifetimebound`` attribute, this determination can be extended to look through
3958	user-declared functions. For example:
3959
3960	.. code-block:: c++
3961
3962	#include <map>
3963	#include <string>
3964
3965	using namespace std::literals;
3966
3967	// Returns m[key] if key is present, or default_value if not.
3968	template<typename T, typename U>
3969	const U &get_or_default(const std::map<T, U> &m [[clang::lifetimebound]],
3970	const T &key, /* note, not lifetimebound */
3971	const U &default_value [[clang::lifetimebound]]) {
3972	if (auto iter = m.find(key); iter != m.end()) return iter->second;
3973	else return default_value;
3974	}
3975
3976	int main() {
3977	std::map<std::string, std::string> m;
3978	// warning: temporary bound to local reference 'val1' will be destroyed
3979	// at the end of the full-expression
3980	const std::string &val1 = get_or_default(m, "foo"s, "bar"s);
3981
3982	// No warning in this case.
3983	std::string def_val = "bar"s;
3984	const std::string &val2 = get_or_default(m, "foo"s, def_val);
3985
3986	return 0;
3987	}
3988
3989	The attribute can be applied to the implicit ``this`` parameter of a member
3990	function by writing the attribute after the function type:
3991
3992	.. code-block:: c++
3993
3994	struct string {
3995	// The returned pointer should not outlive ``*this``.
3996	const char *data() const [[clang::lifetimebound]];
3997	};
3998
3999	This attribute is inspired by the C++ committee paper `P0936R0
4000	<http://wg21.link/p0936r0>`_, but does not affect whether temporary objects
4001	have their lifetimes extended.)reST";
4002
4003	static const char AttrDoc_LifetimeCaptureBy[] = R"reST(Similar to `lifetimebound`_, the ``lifetime_capture_by(X)`` attribute on a
4004	function parameter or implicit object parameter indicates that the capturing
4005	entity ``X`` may refer to the object referred by that parameter.
4006
4007	Below is a list of types of the parameters and what they're considered to refer to:
4008
4009	- A reference param (of non-view type) is considered to refer to its referenced object.
4010	- A pointer param (of non-view type) is considered to refer to its pointee.
4011	- View type param (type annotated with ``[[gsl::Pointer()]]``) is considered to refer
4012	to its pointee (gsl owner). This holds true even if the view type appears as a reference
4013	in the parameter. For example, both ``std::string_view`` and
4014	``const std::string_view &`` are considered to refer to a ``std::string``.
4015	- A ``std::initializer_list<T>`` is considered to refer to its underlying array.
4016	- Aggregates (arrays and simple ``struct``\s) are considered to refer to all
4017	objects that their transitive subobjects refer to.
4018
4019	Clang would diagnose when a temporary object is used as an argument to such an
4020	annotated parameter.
4021	In this case, the capturing entity ``X`` could capture a dangling reference to this
4022	temporary object.
4023
4024	.. code-block:: c++
4025
4026	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s) {
4027	s.insert(a);
4028	}
4029	void use() {
4030	std::set<std::string_view> s;
4031	addToSet(std::string(), s); // Warning: object whose reference is captured by 's' will be destroyed at the end of the full-expression.
4032	// ^^^^^^^^^^^^^
4033	std::string local;
4034	addToSet(local, s); // Ok.
4035	}
4036
4037	The capturing entity ``X`` can be one of the following:
4038
4039	- Another (named) function parameter.
4040
4041	.. code-block:: c++
4042
4043	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s) {
4044	s.insert(a);
4045	}
4046
4047	- ``this`` (in case of member functions).
4048
4049	.. code-block:: c++
4050
4051	class S {
4052	void addToSet(std::string_view a [[clang::lifetime_capture_by(this)]]) {
4053	s.insert(a);
4054	}
4055	std::set<std::string_view> s;
4056	};
4057
4058	Note: When applied to a constructor parameter, `[[clang::lifetime_capture_by(this)]]` is just an alias of `[[clang::lifetimebound]]`.
4059
4060	- `global`, `unknown`.
4061
4062	.. code-block:: c++
4063
4064	std::set<std::string_view> s;
4065	void addToSet(std::string_view a [[clang::lifetime_capture_by(global)]]) {
4066	s.insert(a);
4067	}
4068	void addSomewhere(std::string_view a [[clang::lifetime_capture_by(unknown)]]);
4069
4070	The attribute can be applied to the implicit ``this`` parameter of a member
4071	function by writing the attribute after the function type:
4072
4073	.. code-block:: c++
4074
4075	struct S {
4076	const char data(std::set<S>& s) [[clang::lifetime_capture_by(s)]] {
4077	s.insert(this);
4078	}
4079	};
4080
4081	The attribute supports specifying more than one capturing entities:
4082
4083	.. code-block:: c++
4084
4085	void addToSets(std::string_view a [[clang::lifetime_capture_by(s1, s2)]],
4086	std::set<std::string_view>& s1,
4087	std::set<std::string_view>& s2) {
4088	s1.insert(a);
4089	s2.insert(a);
4090	}
4091
4092	Limitation: The capturing entity ``X`` is not used by the analysis and is
4093	used for documentation purposes only. This is because the analysis is
4094	statement-local and only detects use of a temporary as an argument to the
4095	annotated parameter.
4096
4097	.. code-block:: c++
4098
4099	void addToSet(std::string_view a [[clang::lifetime_capture_by(s)]], std::set<std::string_view>& s);
4100	void use() {
4101	std::set<std::string_view> s;
4102	if (foo()) {
4103	std::string str;
4104	addToSet(str, s); // Not detected.
4105	}
4106	})reST";
4107
4108	static const char AttrDoc_Likely[] = R"reST(The ``likely`` and ``unlikely`` attributes are used as compiler hints.
4109	The attributes are used to aid the compiler to determine which branch is
4110	likely or unlikely to be taken. This is done by marking the branch substatement
4111	with one of the two attributes.
4112
4113	It isn't allowed to annotate a single statement with both ``likely`` and
4114	``unlikely``. Annotating the ``true`` and ``false`` branch of an ``if``
4115	statement with the same likelihood attribute will result in a diagnostic and
4116	the attributes are ignored on both branches.
4117
4118	In a ``switch`` statement it's allowed to annotate multiple ``case`` labels
4119	or the ``default`` label with the same likelihood attribute. This makes
4120	* all labels without an attribute have a neutral likelihood,
4121	* all labels marked ``[[likely]]`` have an equally positive likelihood, and
4122	* all labels marked ``[[unlikely]]`` have an equally negative likelihood.
4123	The neutral likelihood is the more likely of path execution than the negative
4124	likelihood. The positive likelihood is the more likely of path of execution
4125	than the neutral likelihood.
4126
4127	These attributes have no effect on the generated code when using
4128	PGO (Profile-Guided Optimization) or at optimization level 0.
4129
4130	In Clang, the attributes will be ignored if they're not placed on
4131	* the ``case`` or ``default`` label of a ``switch`` statement,
4132	* or on the substatement of an ``if`` or ``else`` statement,
4133	* or on the substatement of an ``for`` or ``while`` statement.
4134	The C++ Standard recommends to honor them on every statement in the
4135	path of execution, but that can be confusing:
4136
4137	.. code-block:: c++
4138
4139	if (b) {
4140	[[unlikely]] --b; // In the path of execution,
4141	// this branch is considered unlikely.
4142	}
4143
4144	if (b) {
4145	--b;
4146	if(b)
4147	return;
4148	[[unlikely]] --b; // Not in the path of execution,
4149	} // the branch has no likelihood information.
4150
4151	if (b) {
4152	--b;
4153	foo(b);
4154	// Whether or not the next statement is in the path of execution depends
4155	// on the declaration of foo():
4156	// In the path of execution: void foo(int);
4157	// Not in the path of execution: [[noreturn]] void foo(int);
4158	// This means the likelihood of the branch depends on the declaration
4159	// of foo().
4160	[[unlikely]] --b;
4161	}
4162
4163
4164	Below are some example usages of the likelihood attributes and their effects:
4165
4166	.. code-block:: c++
4167
4168	if (b) [[likely]] { // Placement on the first statement in the branch.
4169	// The compiler will optimize to execute the code here.
4170	} else {
4171	}
4172
4173	if (b)
4174	[[unlikely]] b++; // Placement on the first statement in the branch.
4175	else {
4176	// The compiler will optimize to execute the code here.
4177	}
4178
4179	if (b) {
4180	[[unlikely]] b++; // Placement on the second statement in the branch.
4181	} // The attribute will be ignored.
4182
4183	if (b) [[likely]] {
4184	[[unlikely]] b++; // No contradiction since the second attribute
4185	} // is ignored.
4186
4187	if (b)
4188	;
4189	else [[likely]] {
4190	// The compiler will optimize to execute the code here.
4191	}
4192
4193	if (b)
4194	;
4195	else
4196	// The compiler will optimize to execute the next statement.
4197	[[likely]] b = f();
4198
4199	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
4200	else [[likely]]; // and the attributes are ignored.
4201
4202	if (b)
4203	[[likely]] int i = 5; // Issues a diagnostic since the attribute
4204	// isn't allowed on a declaration.
4205
4206	switch (i) {
4207	[[likely]] case 1: // This value is likely
4208	...
4209	break;
4210
4211	[[unlikely]] case 2: // This value is unlikely
4212	...
4213	[[fallthrough]];
4214
4215	case 3: // No likelihood attribute
4216	...
4217	[[likely]] break; // No effect
4218
4219	case 4: [[likely]] { // attribute on substatement has no effect
4220	...
4221	break;
4222	}
4223
4224	[[unlikely]] default: // All other values are unlikely
4225	...
4226	break;
4227	}
4228
4229	switch (i) {
4230	[[likely]] case 0: // This value and code path is likely
4231	...
4232	[[fallthrough]];
4233
4234	case 1: // No likelihood attribute, code path is neutral
4235	break; // falling through has no effect on the likelihood
4236
4237	case 2: // No likelihood attribute, code path is neutral
4238	[[fallthrough]];
4239
4240	[[unlikely]] default: // This value and code path are both unlikely
4241	break;
4242	}
4243
4244	for(int i = 0; i != size; ++i) [[likely]] {
4245	... // The loop is the likely path of execution
4246	}
4247
4248	for(const auto &E : Elements) [[likely]] {
4249	... // The loop is the likely path of execution
4250	}
4251
4252	while(i != size) [[unlikely]] {
4253	... // The loop is the unlikely path of execution
4254	} // The generated code will optimize to skip the loop body
4255
4256	while(true) [[unlikely]] {
4257	... // The attribute has no effect
4258	} // Clang elides the comparison and generates an infinite
4259	// loop)reST";
4260
4261	static const char AttrDoc_LoaderUninitialized[] = R"reST(The ``loader_uninitialized`` attribute can be placed on global variables to
4262	indicate that the variable does not need to be zero initialized by the loader.
4263	On most targets, zero-initialization does not incur any additional cost.
4264	For example, most general purpose operating systems deliberately ensure
4265	that all memory is properly initialized in order to avoid leaking privileged
4266	information from the kernel or other programs. However, some targets
4267	do not make this guarantee, and on these targets, avoiding an unnecessary
4268	zero-initialization can have a significant impact on load times and/or code
4269	size.
4270
4271	A declaration with this attribute is a non-tentative definition just as if it
4272	provided an initializer. Variables with this attribute are considered to be
4273	uninitialized in the same sense as a local variable, and the programs must
4274	write to them before reading from them. If the variable's type is a C++ class
4275	type with a non-trivial default constructor, or an array thereof, this attribute
4276	only suppresses the static zero-initialization of the variable, not the dynamic
4277	initialization provided by executing the default constructor.)reST";
4278
4279	static const char AttrDoc_LockReturned[] = R"reST(No documentation.)reST";
4280
4281	static const char AttrDoc_LocksExcluded[] = R"reST(No documentation.)reST";
4282
4283	static const char AttrDoc_LoopHint[] = R"reST(The ``#pragma clang loop`` directive allows loop optimization hints to be
4284	specified for the subsequent loop. The directive allows pipelining to be
4285	disabled, or vectorization, vector predication, interleaving, and unrolling to
4286	be enabled or disabled. Vector width, vector predication, interleave count,
4287	unrolling count, and the initiation interval for pipelining can be explicitly
4288	specified. See `language extensions
4289	<http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>`_
4290	for details.)reST";
4291
4292	static const char AttrDoc_M68kInterrupt[] = R"reST(No documentation.)reST";
4293
4294	static const char AttrDoc_M68kRTD[] = R"reST(On M68k targets, this attribute changes the calling convention of a function
4295	to clear parameters off the stack on return. In other words, callee is
4296	responsible for cleaning out the stack space allocated for incoming paramters.
4297	This convention does not support variadic calls or unprototyped functions in C.
4298	When targeting M68010 or newer CPUs, this calling convention is implemented
4299	using the `rtd` instruction.)reST";
4300
4301	static const char AttrDoc_MIGServerRoutine[] = R"reST(The Mach Interface Generator release-on-success convention dictates
4302	functions that follow it to only release arguments passed to them when they
4303	return "success" (a ``kern_return_t`` error code that indicates that
4304	no errors have occurred). Otherwise the release is performed by the MIG client
4305	that called the function. The annotation ``__attribute__((mig_server_routine))``
4306	is applied in order to specify which functions are expected to follow the
4307	convention. This allows the Static Analyzer to find bugs caused by violations of
4308	that convention. The attribute would normally appear on the forward declaration
4309	of the actual server routine in the MIG server header, but it may also be
4310	added to arbitrary functions that need to follow the same convention - for
4311	example, a user can add them to auxiliary functions called by the server routine
4312	that have their return value of type ``kern_return_t`` unconditionally returned
4313	from the routine. The attribute can be applied to C++ methods, and in this case
4314	it will be automatically applied to overrides if the method is virtual. The
4315	attribute can also be written using C++11 syntax: ``[[mig::server_routine]]``.)reST";
4316
4317	static const char AttrDoc_MSABI[] = R"reST(On non-Windows x86_64 and aarch64 targets, this attribute changes the calling convention of
4318	a function to match the default convention used on Windows. This
4319	attribute has no effect on Windows targets or non-x86_64, non-aarch64 targets.)reST";
4320
4321	static const char AttrDoc_MSAllocator[] = R"reST(The ``__declspec(allocator)`` attribute is applied to functions that allocate
4322	memory, such as operator new in C++. When CodeView debug information is emitted
4323	(enabled by ``clang -gcodeview`` or ``clang-cl /Z7``), Clang will attempt to
4324	record the code offset of heap allocation call sites in the debug info. It will
4325	also record the type being allocated using some local heuristics. The Visual
4326	Studio debugger uses this information to `profile memory usage`_.
4327
4328	.. _profile memory usage: https://docs.microsoft.com/en-us/visualstudio/profiling/memory-usage
4329
4330	This attribute does not affect optimizations in any way, unlike GCC's
4331	``__attribute__((malloc))``.)reST";
4332
4333	static const char AttrDoc_MSConstexpr[] = R"reST(The ``[[msvc::constexpr]]`` attribute can be applied only to a function
4334	definition or a ``return`` statement. It does not impact function declarations.
4335	A ``[[msvc::constexpr]]`` function cannot be ``constexpr`` or ``consteval``.
4336	A ``[[msvc::constexpr]]`` function is treated as if it were a ``constexpr`` function
4337	when it is evaluated in a constant context of ``[[msvc::constexpr]] return`` statement.
4338	Otherwise, it is treated as a regular function.
4339
4340	Semantics of this attribute are enabled only under MSVC compatibility
4341	(``-fms-compatibility-version``) 19.33 and later.)reST";
4342
4343	static const char AttrDoc_MSInheritance[] = R"reST(This collection of keywords is enabled under ``-fms-extensions`` and controls
4344	the pointer-to-member representation used on ``--win32`` targets.
4345
4346	The ``--win32`` targets utilize a pointer-to-member representation which
4347	varies in size and alignment depending on the definition of the underlying
4348	class.
4349
4350	However, this is problematic when a forward declaration is only available and
4351	no definition has been made yet. In such cases, Clang is forced to utilize the
4352	most general representation that is available to it.
4353
4354	These keywords make it possible to use a pointer-to-member representation other
4355	than the most general one regardless of whether or not the definition will ever
4356	be present in the current translation unit.
4357
4358	This family of keywords belong between the ``class-key`` and ``class-name``:
4359
4360	.. code-block:: c++
4361
4362	struct __single_inheritance S;
4363	int S::*i;
4364	struct S {};
4365
4366	This keyword can be applied to class templates but only has an effect when used
4367	on full specializations:
4368
4369	.. code-block:: c++
4370
4371	template <typename T, typename U> struct __single_inheritance A; // warning: inheritance model ignored on primary template
4372	template <typename T> struct __multiple_inheritance A<T, T>; // warning: inheritance model ignored on partial specialization
4373	template <> struct __single_inheritance A<int, float>;
4374
4375	Note that choosing an inheritance model less general than strictly necessary is
4376	an error:
4377
4378	.. code-block:: c++
4379
4380	struct __multiple_inheritance S; // error: inheritance model does not match definition
4381	int S::*i;
4382	struct S {};)reST";
4383
4384	static const char AttrDoc_MSNoVTable[] = R"reST(This attribute can be added to a class declaration or definition to signal to
4385	the compiler that constructors and destructors will not reference the virtual
4386	function table. It is only supported when using the Microsoft C++ ABI.)reST";
4387
4388	static const char AttrDoc_MSP430Interrupt[] = R"reST(No documentation.)reST";
4389
4390	static const char AttrDoc_MSStruct[] = R"reST(The ``ms_struct`` and ``gcc_struct`` attributes request the compiler to enter a
4391	special record layout compatibility mode which mimics the layout of Microsoft or
4392	Itanium C++ ABI respectively. Obviously, if the current C++ ABI matches the
4393	requested ABI, the attribute does nothing. However, if it does not, annotated
4394	structure or class is laid out in a special compatibility mode, which slightly
4395	changes offsets for fields and bit-fields. The intention is to match the layout
4396	of the requested ABI for structures which only use C features.
4397
4398	Note that the default behavior can be controlled by ``-mms-bitfields`` and
4399	``-mno-ms-bitfields`` switches and via ``#pragma ms_struct``.
4400
4401	The primary difference is for bitfields, where the MS variant only packs
4402	adjacent fields into the same allocation unit if they have integral types
4403	of the same size, while the GCC/Itanium variant packs all fields in a bitfield
4404	tightly.)reST";
4405
4406	static const char AttrDoc_MSVtorDisp[] = R"reST()reST";
4407
4408	static const char AttrDoc_MallocSpan[] = R"reST(The ``malloc_span`` attribute can be used to mark that a function which acts
4409	like a system memory allocation function and returns a span-like structure,
4410	where the returned memory range does not alias storage from any other object
4411	accessible to the caller.
4412
4413	In this context, a span-like structure is assumed to have two non-static data
4414	members, one of which is a pointer to the start of the allocated memory and
4415	the other one is either an integer type containing the size of the actually
4416	allocated memory or a pointer to the end of the allocated region. Note, static
4417	data members do not impact whether a type is span-like or not.)reST";
4418
4419	static const char AttrDoc_MaxFieldAlignment[] = R"reST()reST";
4420
4421	static const char AttrDoc_MayAlias[] = R"reST(No documentation.)reST";
4422
4423	static const char AttrDoc_MaybeUndef[] = R"reST(The ``maybe_undef`` attribute can be placed on a function parameter. It indicates
4424	that the parameter is allowed to use undef values. It informs the compiler
4425	to insert a freeze LLVM IR instruction on the function parameter.
4426	Please note that this is an attribute that is used as an internal
4427	implementation detail and not intended to be used by external users.
4428
4429	In languages HIP, CUDA etc., some functions have multi-threaded semantics and
4430	it is enough for only one or some threads to provide defined arguments.
4431	Depending on semantics, undef arguments in some threads don't produce
4432	undefined results in the function call. Since, these functions accept undefined
4433	arguments, ``maybe_undef`` attribute can be placed.
4434
4435	Sample usage:
4436	.. code-block:: c
4437
4438	void maybeundeffunc(int __attribute__((maybe_undef))param);)reST";
4439
4440	static const char AttrDoc_MicroMips[] = R"reST(Clang supports the GNU style ``__attribute__((micromips))`` and
4441	``__attribute__((nomicromips))`` attributes on MIPS targets. These attributes
4442	may be attached to a function definition and instructs the backend to generate
4443	or not to generate microMIPS code for that function.
4444
4445	These attributes override the ``-mmicromips`` and ``-mno-micromips`` options
4446	on the command line.)reST";
4447
4448	static const char AttrDoc_MinSize[] = R"reST(This function attribute indicates that optimization passes and code generator passes
4449	make choices that keep the function code size as small as possible. Optimizations may
4450	also sacrifice runtime performance in order to minimize the size of the generated code.)reST";
4451
4452	static const char AttrDoc_MinVectorWidth[] = R"reST(Clang supports the ``__attribute__((min_vector_width(width)))`` attribute. This
4453	attribute may be attached to a function and informs the backend that this
4454	function desires vectors of at least this width to be generated. Target-specific
4455	maximum vector widths still apply. This means even if you ask for something
4456	larger than the target supports, you will only get what the target supports.
4457	This attribute is meant to be a hint to control target heuristics that may
4458	generate narrower vectors than what the target hardware supports.
4459
4460	This is currently used by the X86 target to allow some CPUs that support 512-bit
4461	vectors to be limited to using 256-bit vectors to avoid frequency penalties.
4462	This is currently enabled with the ``-prefer-vector-width=256`` command line
4463	option. The ``min_vector_width`` attribute can be used to prevent the backend
4464	from trying to split vector operations to match the ``prefer-vector-width``. All
4465	X86 vector intrinsics from x86intrin.h already set this attribute. Additionally,
4466	use of any of the X86-specific vector builtins will implicitly set this
4467	attribute on the calling function. The intent is that explicitly writing vector
4468	code using the X86 intrinsics will prevent ``prefer-vector-width`` from
4469	affecting the code.)reST";
4470
4471	static const char AttrDoc_Mips16[] = R"reST(No documentation.)reST";
4472
4473	static const char AttrDoc_MipsInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt("ARGUMENT")))`` attribute on
4474	MIPS targets. This attribute may be attached to a function definition and instructs
4475	the backend to generate appropriate function entry/exit code so that it can be used
4476	directly as an interrupt service routine.
4477
4478	By default, the compiler will produce a function prologue and epilogue suitable for
4479	an interrupt service routine that handles an External Interrupt Controller (eic)
4480	generated interrupt. This behavior can be explicitly requested with the "eic"
4481	argument.
4482
4483	Otherwise, for use with vectored interrupt mode, the argument passed should be
4484	of the form "vector=LEVEL" where LEVEL is one of the following values:
4485	"sw0", "sw1", "hw0", "hw1", "hw2", "hw3", "hw4", "hw5". The compiler will
4486	then set the interrupt mask to the corresponding level which will mask all
4487	interrupts up to and including the argument.
4488
4489	The semantics are as follows:
4490
4491	- The prologue is modified so that the Exception Program Counter (EPC) and
4492	Status coprocessor registers are saved to the stack. The interrupt mask is
4493	set so that the function can only be interrupted by a higher priority
4494	interrupt. The epilogue will restore the previous values of EPC and Status.
4495
4496	- The prologue and epilogue are modified to save and restore all non-kernel
4497	registers as necessary.
4498
4499	- The FPU is disabled in the prologue, as the floating pointer registers are not
4500	spilled to the stack.
4501
4502	- The function return sequence is changed to use an exception return instruction.
4503
4504	- The parameter sets the interrupt mask for the function corresponding to the
4505	interrupt level specified. If no mask is specified the interrupt mask
4506	defaults to "eic".)reST";
4507
4508	static const char AttrDoc_MipsLongCall[] = R"reST(Clang supports the ``__attribute__((long_call))``, ``__attribute__((far))``,
4509	and ``__attribute__((near))`` attributes on MIPS targets. These attributes may
4510	only be added to function declarations and change the code generated
4511	by the compiler when directly calling the function. The ``near`` attribute
4512	allows calls to the function to be made using the ``jal`` instruction, which
4513	requires the function to be located in the same naturally aligned 256MB
4514	segment as the caller. The ``long_call`` and ``far`` attributes are synonyms
4515	and require the use of a different call sequence that works regardless
4516	of the distance between the functions.
4517
4518	These attributes have no effect for position-independent code.
4519
4520	These attributes take priority over command line switches such
4521	as ``-mlong-calls`` and ``-mno-long-calls``.)reST";
4522
4523	static const char AttrDoc_MipsShortCall[] = R"reST(Clang supports the ``__attribute__((long_call))``, ``__attribute__((far))``,
4524	``__attribute__((short__call))``, and ``__attribute__((near))`` attributes
4525	on MIPS targets. These attributes may only be added to function declarations
4526	and change the code generated by the compiler when directly calling
4527	the function. The ``short_call`` and ``near`` attributes are synonyms and
4528	allow calls to the function to be made using the ``jal`` instruction, which
4529	requires the function to be located in the same naturally aligned 256MB segment
4530	as the caller. The ``long_call`` and ``far`` attributes are synonyms and
4531	require the use of a different call sequence that works regardless
4532	of the distance between the functions.
4533
4534	These attributes have no effect for position-independent code.
4535
4536	These attributes take priority over command line switches such
4537	as ``-mlong-calls`` and ``-mno-long-calls``.)reST";
4538
4539	static const char AttrDoc_Mode[] = R"reST(No documentation.)reST";
4540
4541	static const char AttrDoc_ModularFormat[] = R"reST(The ``modular_format`` attribute can be applied to a function that bears the
4542	``format`` attribute (or standard library functions) to indicate that the
4543	implementation is "modular", that is, that the implementation is logically
4544	divided into a number of named aspects. When the compiler can determine that
4545	not all aspects of the implementation are needed for a given call, the compiler
4546	may redirect the call to the identifier given as the first argument to the
4547	attribute (the modular implementation function).
4548
4549	The second argument is a implementation name, and the remaining arguments are
4550	aspects of the format string for the compiler to report. The implementation
4551	name is an unevaluated identifier be in the C namespace.
4552
4553	The compiler reports that a call requires an aspect by issuing a relocation for
4554	the symbol ``<impl_name>_<aspect>`` at the point of the call. This arranges for
4555	code and data needed to support the aspect of the implementation to be brought
4556	into the link to satisfy weak references in the modular implemenation function.
4557	If the compiler does not understand an aspect, it must summarily consider any
4558	call to require that aspect.
4559
4560	For example, say ``printf`` is annotated with
4561	``modular_format(__modular_printf, "__printf", "float")``. Then, a call to
4562	``printf(var, 42)`` would be untouched. A call to ``printf("%d", 42)`` would
4563	become a call to ``__modular_printf`` with the same arguments, as would
4564	``printf("%f", 42.0)``. The latter would be accompanied with a strong
4565	relocation against the symbol ``__printf_float``, which would bring floating
4566	point support for ``printf`` into the link.
4567
4568	If the attribute appears more than once on a declaration, or across a chain of
4569	redeclarations, it is an error for the attributes to have different arguments,
4570	excepting that the aspects may be in any order.
4571
4572	The following aspects are currently supported:
4573
4574	- ``float``: The call has a floating point argument)reST";
4575
4576	static const char AttrDoc_MustTail[] = R"reST(If a ``return`` statement is marked ``musttail``, this indicates that the
4577	compiler must generate a tail call for the program to be correct, even when
4578	optimizations are disabled. This guarantees that the call will not cause
4579	unbounded stack growth if it is part of a recursive cycle in the call graph.
4580
4581	If the callee is a virtual function that is implemented by a thunk, there is
4582	no guarantee in general that the thunk tail-calls the implementation of the
4583	virtual function, so such a call in a recursive cycle can still result in
4584	unbounded stack growth.
4585
4586	``clang::musttail`` can only be applied to a ``return`` statement whose value
4587	is the result of a function call (even functions returning void must use
4588	``return``, although no value is returned). The target function must have the
4589	same number of arguments as the caller. The types of the return value and all
4590	arguments must be similar according to C++ rules (differing only in cv
4591	qualifiers or array size), including the implicit "this" argument, if any.
4592	Any variables in scope, including all arguments to the function and the
4593	return value must be trivially destructible. The calling convention of the
4594	caller and callee must match, and they must not be variadic functions or have
4595	old style K&R C function declarations.
4596
4597	The lifetimes of all local variables and function parameters end immediately
4598	before the call to the function. This means that it is undefined behaviour to
4599	pass a pointer or reference to a local variable to the called function, which
4600	is not the case without the attribute. Clang will emit a warning in common
4601	cases where this happens.
4602
4603	``clang::musttail`` provides assurances that the tail call can be optimized on
4604	all targets, not just one.)reST";
4605
4606	static const char AttrDoc_NSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4607	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4608	convention (e.g. functions starting with "get" are assumed to return at
4609	``+0``).
4610
4611	It can be overridden using a family of the following attributes. In
4612	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4613	a function communicates that the object is returned at ``+1``, and the caller
4614	is responsible for freeing it.
4615	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4616	specifies that the object is returned at ``+0`` and the ownership remains with
4617	the callee.
4618	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4619	the Objective-C method call consumes the reference to ``self``, e.g. by
4620	attaching it to a supplied parameter.
4621	Additionally, parameters can have an annotation
4622	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4623	as that parameter effectively transfers the ownership, and the caller is no
4624	longer responsible for it.
4625	These attributes affect code generation when interacting with ARC code, and
4626	they are used by the Clang Static Analyzer.
4627
4628	In C programs using CoreFoundation, a similar set of attributes:
4629	``__attribute__((cf_returns_not_retained))``,
4630	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4631	have the same respective semantics when applied to CoreFoundation objects.
4632	These attributes affect code generation when interacting with ARC code, and
4633	they are used by the Clang Static Analyzer.
4634
4635	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4636	the same attribute family is present:
4637	``__attribute__((os_returns_not_retained))``,
4638	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4639	with the same respective semantics.
4640	Similar to ``__attribute__((ns_consumes_self))``,
4641	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4642	the reference to "this" (e.g., when attaching it to a different object supplied
4643	as a parameter).
4644	Out parameters (parameters the function is meant to write into,
4645	either via pointers-to-pointers or references-to-pointers)
4646	may be annotated with ``__attribute__((os_returns_retained))``
4647	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4648	written into the out parameter should (or respectively should not) be released
4649	after use.
4650	Since often out parameters may or may not be written depending on the exit
4651	code of the function,
4652	annotations ``__attribute__((os_returns_retained_on_zero))``
4653	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4654	an out parameter at ``+1`` is written if and only if the function returns a zero
4655	(respectively non-zero) error code.
4656	Observe that return-code-dependent out parameter annotations are only
4657	available for retained out parameters, as non-retained object do not have to be
4658	released by the callee.
4659	These attributes are only used by the Clang Static Analyzer.
4660
4661	The family of attributes ``X_returns_X_retained`` can be added to functions,
4662	C++ methods, and Objective-C methods and properties.
4663	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4664	and Objective-C methods.)reST";
4665
4666	static const char AttrDoc_NSConsumesSelf[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4667	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4668	convention (e.g. functions starting with "get" are assumed to return at
4669	``+0``).
4670
4671	It can be overridden using a family of the following attributes. In
4672	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4673	a function communicates that the object is returned at ``+1``, and the caller
4674	is responsible for freeing it.
4675	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4676	specifies that the object is returned at ``+0`` and the ownership remains with
4677	the callee.
4678	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4679	the Objective-C method call consumes the reference to ``self``, e.g. by
4680	attaching it to a supplied parameter.
4681	Additionally, parameters can have an annotation
4682	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4683	as that parameter effectively transfers the ownership, and the caller is no
4684	longer responsible for it.
4685	These attributes affect code generation when interacting with ARC code, and
4686	they are used by the Clang Static Analyzer.
4687
4688	In C programs using CoreFoundation, a similar set of attributes:
4689	``__attribute__((cf_returns_not_retained))``,
4690	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4691	have the same respective semantics when applied to CoreFoundation objects.
4692	These attributes affect code generation when interacting with ARC code, and
4693	they are used by the Clang Static Analyzer.
4694
4695	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4696	the same attribute family is present:
4697	``__attribute__((os_returns_not_retained))``,
4698	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4699	with the same respective semantics.
4700	Similar to ``__attribute__((ns_consumes_self))``,
4701	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4702	the reference to "this" (e.g., when attaching it to a different object supplied
4703	as a parameter).
4704	Out parameters (parameters the function is meant to write into,
4705	either via pointers-to-pointers or references-to-pointers)
4706	may be annotated with ``__attribute__((os_returns_retained))``
4707	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4708	written into the out parameter should (or respectively should not) be released
4709	after use.
4710	Since often out parameters may or may not be written depending on the exit
4711	code of the function,
4712	annotations ``__attribute__((os_returns_retained_on_zero))``
4713	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4714	an out parameter at ``+1`` is written if and only if the function returns a zero
4715	(respectively non-zero) error code.
4716	Observe that return-code-dependent out parameter annotations are only
4717	available for retained out parameters, as non-retained object do not have to be
4718	released by the callee.
4719	These attributes are only used by the Clang Static Analyzer.
4720
4721	The family of attributes ``X_returns_X_retained`` can be added to functions,
4722	C++ methods, and Objective-C methods and properties.
4723	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4724	and Objective-C methods.)reST";
4725
4726	static const char AttrDoc_NSErrorDomain[] = R"reST(In Cocoa frameworks in Objective-C, one can group related error codes in enums
4727	and categorize these enums with error domains.
4728
4729	The ``ns_error_domain`` attribute indicates a global ``NSString`` or
4730	``CFString`` constant representing the error domain that an error code belongs
4731	to. For pointer uniqueness and code size this is a constant symbol, not a
4732	literal.
4733
4734	The domain and error code need to be used together. The ``ns_error_domain``
4735	attribute links error codes to their domain at the source level.
4736
4737	This metadata is useful for documentation purposes, for static analysis, and for
4738	improving interoperability between Objective-C and Swift. It is not used for
4739	code generation in Objective-C.
4740
4741	For example:
4742
4743	.. code-block:: objc
4744
4745	#define NS_ERROR_ENUM(_type, _name, _domain) \
4746	enum _name : _type _name; enum __attribute__((ns_error_domain(_domain))) _name : _type
4747
4748	extern NSString *const MyErrorDomain;
4749	typedef NS_ERROR_ENUM(unsigned char, MyErrorEnum, MyErrorDomain) {
4750	MyErrFirst,
4751	MyErrSecond,
4752	};)reST";
4753
4754	static const char AttrDoc_NSReturnsAutoreleased[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4755	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4756	convention (e.g. functions starting with "get" are assumed to return at
4757	``+0``).
4758
4759	It can be overridden using a family of the following attributes. In
4760	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4761	a function communicates that the object is returned at ``+1``, and the caller
4762	is responsible for freeing it.
4763	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4764	specifies that the object is returned at ``+0`` and the ownership remains with
4765	the callee.
4766	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4767	the Objective-C method call consumes the reference to ``self``, e.g. by
4768	attaching it to a supplied parameter.
4769	Additionally, parameters can have an annotation
4770	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4771	as that parameter effectively transfers the ownership, and the caller is no
4772	longer responsible for it.
4773	These attributes affect code generation when interacting with ARC code, and
4774	they are used by the Clang Static Analyzer.
4775
4776	In C programs using CoreFoundation, a similar set of attributes:
4777	``__attribute__((cf_returns_not_retained))``,
4778	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4779	have the same respective semantics when applied to CoreFoundation objects.
4780	These attributes affect code generation when interacting with ARC code, and
4781	they are used by the Clang Static Analyzer.
4782
4783	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4784	the same attribute family is present:
4785	``__attribute__((os_returns_not_retained))``,
4786	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4787	with the same respective semantics.
4788	Similar to ``__attribute__((ns_consumes_self))``,
4789	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4790	the reference to "this" (e.g., when attaching it to a different object supplied
4791	as a parameter).
4792	Out parameters (parameters the function is meant to write into,
4793	either via pointers-to-pointers or references-to-pointers)
4794	may be annotated with ``__attribute__((os_returns_retained))``
4795	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4796	written into the out parameter should (or respectively should not) be released
4797	after use.
4798	Since often out parameters may or may not be written depending on the exit
4799	code of the function,
4800	annotations ``__attribute__((os_returns_retained_on_zero))``
4801	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4802	an out parameter at ``+1`` is written if and only if the function returns a zero
4803	(respectively non-zero) error code.
4804	Observe that return-code-dependent out parameter annotations are only
4805	available for retained out parameters, as non-retained object do not have to be
4806	released by the callee.
4807	These attributes are only used by the Clang Static Analyzer.
4808
4809	The family of attributes ``X_returns_X_retained`` can be added to functions,
4810	C++ methods, and Objective-C methods and properties.
4811	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4812	and Objective-C methods.)reST";
4813
4814	static const char AttrDoc_NSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4815	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4816	convention (e.g. functions starting with "get" are assumed to return at
4817	``+0``).
4818
4819	It can be overridden using a family of the following attributes. In
4820	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4821	a function communicates that the object is returned at ``+1``, and the caller
4822	is responsible for freeing it.
4823	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4824	specifies that the object is returned at ``+0`` and the ownership remains with
4825	the callee.
4826	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4827	the Objective-C method call consumes the reference to ``self``, e.g. by
4828	attaching it to a supplied parameter.
4829	Additionally, parameters can have an annotation
4830	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4831	as that parameter effectively transfers the ownership, and the caller is no
4832	longer responsible for it.
4833	These attributes affect code generation when interacting with ARC code, and
4834	they are used by the Clang Static Analyzer.
4835
4836	In C programs using CoreFoundation, a similar set of attributes:
4837	``__attribute__((cf_returns_not_retained))``,
4838	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4839	have the same respective semantics when applied to CoreFoundation objects.
4840	These attributes affect code generation when interacting with ARC code, and
4841	they are used by the Clang Static Analyzer.
4842
4843	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4844	the same attribute family is present:
4845	``__attribute__((os_returns_not_retained))``,
4846	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4847	with the same respective semantics.
4848	Similar to ``__attribute__((ns_consumes_self))``,
4849	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4850	the reference to "this" (e.g., when attaching it to a different object supplied
4851	as a parameter).
4852	Out parameters (parameters the function is meant to write into,
4853	either via pointers-to-pointers or references-to-pointers)
4854	may be annotated with ``__attribute__((os_returns_retained))``
4855	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4856	written into the out parameter should (or respectively should not) be released
4857	after use.
4858	Since often out parameters may or may not be written depending on the exit
4859	code of the function,
4860	annotations ``__attribute__((os_returns_retained_on_zero))``
4861	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4862	an out parameter at ``+1`` is written if and only if the function returns a zero
4863	(respectively non-zero) error code.
4864	Observe that return-code-dependent out parameter annotations are only
4865	available for retained out parameters, as non-retained object do not have to be
4866	released by the callee.
4867	These attributes are only used by the Clang Static Analyzer.
4868
4869	The family of attributes ``X_returns_X_retained`` can be added to functions,
4870	C++ methods, and Objective-C methods and properties.
4871	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4872	and Objective-C methods.)reST";
4873
4874	static const char AttrDoc_NSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4875	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4876	convention (e.g. functions starting with "get" are assumed to return at
4877	``+0``).
4878
4879	It can be overridden using a family of the following attributes. In
4880	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4881	a function communicates that the object is returned at ``+1``, and the caller
4882	is responsible for freeing it.
4883	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4884	specifies that the object is returned at ``+0`` and the ownership remains with
4885	the callee.
4886	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4887	the Objective-C method call consumes the reference to ``self``, e.g. by
4888	attaching it to a supplied parameter.
4889	Additionally, parameters can have an annotation
4890	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4891	as that parameter effectively transfers the ownership, and the caller is no
4892	longer responsible for it.
4893	These attributes affect code generation when interacting with ARC code, and
4894	they are used by the Clang Static Analyzer.
4895
4896	In C programs using CoreFoundation, a similar set of attributes:
4897	``__attribute__((cf_returns_not_retained))``,
4898	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4899	have the same respective semantics when applied to CoreFoundation objects.
4900	These attributes affect code generation when interacting with ARC code, and
4901	they are used by the Clang Static Analyzer.
4902
4903	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4904	the same attribute family is present:
4905	``__attribute__((os_returns_not_retained))``,
4906	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4907	with the same respective semantics.
4908	Similar to ``__attribute__((ns_consumes_self))``,
4909	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4910	the reference to "this" (e.g., when attaching it to a different object supplied
4911	as a parameter).
4912	Out parameters (parameters the function is meant to write into,
4913	either via pointers-to-pointers or references-to-pointers)
4914	may be annotated with ``__attribute__((os_returns_retained))``
4915	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4916	written into the out parameter should (or respectively should not) be released
4917	after use.
4918	Since often out parameters may or may not be written depending on the exit
4919	code of the function,
4920	annotations ``__attribute__((os_returns_retained_on_zero))``
4921	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4922	an out parameter at ``+1`` is written if and only if the function returns a zero
4923	(respectively non-zero) error code.
4924	Observe that return-code-dependent out parameter annotations are only
4925	available for retained out parameters, as non-retained object do not have to be
4926	released by the callee.
4927	These attributes are only used by the Clang Static Analyzer.
4928
4929	The family of attributes ``X_returns_X_retained`` can be added to functions,
4930	C++ methods, and Objective-C methods and properties.
4931	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4932	and Objective-C methods.)reST";
4933
4934	static const char AttrDoc_Naked[] = R"reST(No documentation.)reST";
4935
4936	static const char AttrDoc_NoAlias[] = R"reST(The ``noalias`` attribute indicates that the only memory accesses inside
4937	function are loads and stores from objects pointed to by its pointer-typed
4938	arguments, with arbitrary offsets.)reST";
4939
4940	static const char AttrDoc_NoBuiltin[] = R"reST(The ``__attribute__((no_builtin))`` is similar to the ``-fno-builtin`` flag
4941	except it is specific to the body of a function. The attribute may also be
4942	applied to a virtual function but has no effect on the behavior of overriding
4943	functions in a derived class.
4944
4945	It accepts one or more strings corresponding to the specific names of the
4946	builtins to disable (e.g. "memcpy", "memset").
4947	If the attribute is used without parameters it will disable all buitins at
4948	once.
4949
4950	.. code-block:: c++
4951
4952	// The compiler is not allowed to add any builtin to foo's body.
4953	void foo(char* data, size_t count) __attribute__((no_builtin)) {
4954	// The compiler is not allowed to convert the loop into
4955	// `__builtin_memset(data, 0xFE, count);`.
4956	for (size_t i = 0; i < count; ++i)
4957	data[i] = 0xFE;
4958	}
4959
4960	// The compiler is not allowed to add the `memcpy` builtin to bar's body.
4961	void bar(char* data, size_t count) __attribute__((no_builtin("memcpy"))) {
4962	// The compiler is allowed to convert the loop into
4963	// `__builtin_memset(data, 0xFE, count);` but cannot generate any
4964	// `__builtin_memcpy`
4965	for (size_t i = 0; i < count; ++i)
4966	data[i] = 0xFE;
4967	})reST";
4968
4969	static const char AttrDoc_NoCommon[] = R"reST(No documentation.)reST";
4970
4971	static const char AttrDoc_NoConvergent[] = R"reST(This attribute prevents a function from being treated as convergent; when a
4972	function is marked ``noconvergent``, calls to that function are not
4973	automatically assumed to be convergent, unless such calls are explicitly marked
4974	as ``convergent``. If a statement is marked as ``noconvergent``, any calls to
4975	inline ``asm`` in that statement are no longer treated as convergent.
4976
4977	In languages following SPMD/SIMT programming model, e.g., CUDA/HIP, function
4978	declarations and inline asm calls are treated as convergent by default for
4979	correctness. This ``noconvergent`` attribute is helpful for developers to
4980	prevent them from being treated as convergent when it's safe.
4981
4982	.. code-block:: c
4983
4984	__device__ float bar(float);
4985	__device__ float foo(float) __attribute__((noconvergent)) {}
4986
4987	__device__ int example(void) {
4988	float x;
4989	[[clang::noconvergent]] x = bar(x); // no effect on convergence
4990	[[clang::noconvergent]] { asm volatile ("nop"); } // the asm call is non-convergent
4991	})reST";
4992
4993	static const char AttrDoc_NoDebug[] = R"reST(The ``nodebug`` attribute allows you to suppress debugging information for a
4994	function or method, for a variable that is not a parameter or a non-static
4995	data member, or for a typedef or using declaration.)reST";
4996
4997	static const char AttrDoc_NoDeref[] = R"reST(The ``noderef`` attribute causes clang to diagnose dereferences of annotated pointer types.
4998	This is ideally used with pointers that point to special memory which cannot be read
4999	from or written to, but allowing for the pointer to be used in pointer arithmetic.
5000	The following are examples of valid expressions where dereferences are diagnosed:
5001
5002	.. code-block:: c
5003
5004	int __attribute__((noderef)) *p;
5005	int x = *p; // warning
5006
5007	int __attribute__((noderef)) **p2;
5008	x = **p2; // warning
5009
5010	int * __attribute__((noderef)) *p3;
5011	p = *p3; // warning
5012
5013	struct S {
5014	int a;
5015	};
5016	struct S __attribute__((noderef)) *s;
5017	x = s->a; // warning
5018	x = (*s).a; // warning
5019
5020	Not all dereferences may diagnose a warning if the value directed by the pointer may not be
5021	accessed. The following are examples of valid expressions where may not be diagnosed:
5022
5023	.. code-block:: c
5024
5025	int *q;
5026	int __attribute__((noderef)) *p;
5027	q = &*p;
5028	q = *&p;
5029
5030	struct S {
5031	int a;
5032	};
5033	struct S __attribute__((noderef)) *s;
5034	p = &s->a;
5035	p = &(*s).a;
5036
5037	``noderef`` is currently only supported for pointers and arrays and not usable
5038	for references or Objective-C object pointers.
5039
5040	.. code-block:: c++
5041
5042	int x = 2;
5043	int __attribute__((noderef)) &y = x; // warning: 'noderef' can only be used on an array or pointer type
5044
5045	.. code-block:: objc
5046
5047	id __attribute__((noderef)) obj = [NSObject new]; // warning: 'noderef' can only be used on an array or pointer type)reST";
5048
5049	static const char AttrDoc_NoDestroy[] = R"reST(The ``no_destroy`` attribute specifies that a variable with static or thread
5050	storage duration shouldn't have its exit-time destructor run. Annotating every
5051	static and thread duration variable with this attribute is equivalent to
5052	invoking clang with -fno-c++-static-destructors.
5053
5054	If a variable is declared with this attribute, clang doesn't access check or
5055	generate the type's destructor. If you have a type that you only want to be
5056	annotated with ``no_destroy``, you can therefore declare the destructor private:
5057
5058	.. code-block:: c++
5059
5060	struct only_no_destroy {
5061	only_no_destroy();
5062	private:
5063	~only_no_destroy();
5064	};
5065
5066	[[clang::no_destroy]] only_no_destroy global; // fine!
5067
5068	Note that destructors are still required for subobjects of aggregates annotated
5069	with this attribute. This is because previously constructed subobjects need to
5070	be destroyed if an exception gets thrown before the initialization of the
5071	complete object is complete. For instance:
5072
5073	.. code-block:: c++
5074
5075	void f() {
5076	try {
5077	[[clang::no_destroy]]
5078	static only_no_destroy array[10]; // error, only_no_destroy has a private destructor.
5079	} catch (...) {
5080	// Handle the error
5081	}
5082	}
5083
5084	Here, if the construction of ``array[9]`` fails with an exception, ``array[0..8]``
5085	will be destroyed, so the element's destructor needs to be accessible.)reST";
5086
5087	static const char AttrDoc_NoDuplicate[] = R"reST(The ``noduplicate`` attribute can be placed on function declarations to control
5088	whether function calls to this function can be duplicated or not as a result of
5089	optimizations. This is required for the implementation of functions with
5090	certain special requirements, like the OpenCL "barrier" function, that might
5091	need to be run concurrently by all the threads that are executing in lockstep
5092	on the hardware. For example this attribute applied on the function
5093	"nodupfunc" in the code below avoids that:
5094
5095	.. code-block:: c
5096
5097	void nodupfunc() __attribute__((noduplicate));
5098	// Setting it as a C++11 attribute is also valid
5099	// void nodupfunc() [[clang::noduplicate]];
5100	void foo();
5101	void bar();
5102
5103	nodupfunc();
5104	if (a > n) {
5105	foo();
5106	} else {
5107	bar();
5108	}
5109
5110	gets possibly modified by some optimizations into code similar to this:
5111
5112	.. code-block:: c
5113
5114	if (a > n) {
5115	nodupfunc();
5116	foo();
5117	} else {
5118	nodupfunc();
5119	bar();
5120	}
5121
5122	where the call to "nodupfunc" is duplicated and sunk into the two branches
5123	of the condition.)reST";
5124
5125	static const char AttrDoc_NoEscape[] = R"reST(``noescape`` placed on a function parameter of a pointer type is used to inform
5126	the compiler that the pointer cannot escape: that is, no reference to the object
5127	the pointer points to that is derived from the parameter value will survive
5128	after the function returns. Users are responsible for making sure parameters
5129	annotated with ``noescape`` do not actually escape. Calling ``free()`` on such
5130	a parameter does not constitute an escape.
5131
5132	For example:
5133
5134	.. code-block:: c
5135
5136	int *gp;
5137
5138	void nonescapingFunc(__attribute__((noescape)) int *p) {
5139	*p += 100; // OK.
5140	}
5141
5142	void escapingFunc(__attribute__((noescape)) int *p) {
5143	gp = p; // Not OK.
5144	}
5145
5146	Additionally, when the parameter is a `block pointer
5147	<https://clang.llvm.org/docs/BlockLanguageSpec.html>`, the same restriction
5148	applies to copies of the block. For example:
5149
5150	.. code-block:: c
5151
5152	typedef void (^BlockTy)();
5153	BlockTy g0, g1;
5154
5155	void nonescapingFunc(__attribute__((noescape)) BlockTy block) {
5156	block(); // OK.
5157	}
5158
5159	void escapingFunc(__attribute__((noescape)) BlockTy block) {
5160	g0 = block; // Not OK.
5161	g1 = Block_copy(block); // Not OK either.
5162	})reST";
5163
5164	static const char AttrDoc_NoFieldProtection[] = R"reST(No documentation.)reST";
5165
5166	static const char AttrDoc_NoInline[] = R"reST(This function attribute suppresses the inlining of a function at the call sites
5167	of the function.
5168
5169	``[[clang::noinline]]`` spelling can be used as a statement attribute; other
5170	spellings of the attribute are not supported on statements. If a statement is
5171	marked ``[[clang::noinline]]`` and contains calls, those calls inside the
5172	statement will not be inlined by the compiler.
5173
5174	``__noinline__`` can be used as a keyword in CUDA/HIP languages. This is to
5175	avoid diagnostics due to usage of ``__attribute__((__noinline__))``
5176	with ``__noinline__`` defined as a macro as ``__attribute__((noinline))``.
5177
5178	.. code-block:: c
5179
5180	int example(void) {
5181	int r;
5182	[[clang::noinline]] foo();
5183	[[clang::noinline]] r = bar();
5184	return r;
5185	})reST";
5186
5187	static const char AttrDoc_NoInstrumentFunction[] = R"reST(No documentation.)reST";
5188
5189	static const char AttrDoc_NoMerge[] = R"reST(If a statement is marked ``nomerge`` and contains call expressions, those call
5190	expressions inside the statement will not be merged during optimization. This
5191	attribute can be used to prevent the optimizer from obscuring the source
5192	location of certain calls. For example, it will prevent tail merging otherwise
5193	identical code sequences that raise an exception or terminate the program. Tail
5194	merging normally reduces the precision of source location information, making
5195	stack traces less useful for debugging. This attribute gives the user control
5196	over the tradeoff between code size and debug information precision.
5197
5198	``nomerge`` attribute can also be used as function attribute to prevent all
5199	calls to the specified function from merging. It has no effect on indirect
5200	calls to such functions. For example:
5201
5202	.. code-block:: c++
5203
5204	[[clang::nomerge]] void foo(int) {}
5205
5206	void bar(int x) {
5207	auto *ptr = foo;
5208	if (x) foo(1); else foo(2); // will not be merged
5209	if (x) ptr(1); else ptr(2); // indirect call, can be merged
5210	}
5211
5212	``nomerge`` attribute can also be used for pointers to functions to
5213	prevent calls through such pointer from merging. In such case the
5214	effect applies only to a specific function pointer. For example:
5215
5216	.. code-block:: c++
5217
5218	[[clang::nomerge]] void (*foo)(int);
5219
5220	void bar(int x) {
5221	auto *ptr = foo;
5222	if (x) foo(1); else foo(2); // will not be merged
5223	if (x) ptr(1); else ptr(2); // 'ptr' has no 'nomerge' attribute, can be merged
5224	})reST";
5225
5226	static const char AttrDoc_NoMicroMips[] = R"reST(Clang supports the GNU style ``__attribute__((micromips))`` and
5227	``__attribute__((nomicromips))`` attributes on MIPS targets. These attributes
5228	may be attached to a function definition and instructs the backend to generate
5229	or not to generate microMIPS code for that function.
5230
5231	These attributes override the ``-mmicromips`` and ``-mno-micromips`` options
5232	on the command line.)reST";
5233
5234	static const char AttrDoc_NoMips16[] = R"reST(No documentation.)reST";
5235
5236	static const char AttrDoc_NoOutline[] = R"reST(This function attribute suppresses outlining from the annotated function.
5237
5238	Outlining is the process where common parts of separate functions are extracted
5239	into a separate function (or assembly snippet), and calls to that function or
5240	snippet are inserted in the original functions. In this way, it can be seen as
5241	the opposite of inlining. It can help to reduce code size.)reST";
5242
5243	static const char AttrDoc_NoProfileFunction[] = R"reST(Use the ``no_profile_instrument_function`` attribute on a function declaration
5244	to denote that the compiler should not instrument the function with
5245	profile-related instrumentation, such as via the
5246	``-fprofile-generate`` / ``-fprofile-instr-generate`` /
5247	``-fcs-profile-generate`` / ``-fprofile-arcs`` flags.)reST";
5248
5249	static const char AttrDoc_NoRandomizeLayout[] = R"reST(The attribute ``randomize_layout``, when attached to a C structure, selects it
5250	for structure layout field randomization; a compile-time hardening technique. A
5251	"seed" value, is specified via the ``-frandomize-layout-seed=`` command line flag.
5252	For example:
5253
5254	.. code-block:: bash
5255
5256	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
5257	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
5258
5259	You can also supply the seed in a file with ``-frandomize-layout-seed-file=``.
5260	For example:
5261
5262	.. code-block:: bash
5263
5264	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
5265	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
5266
5267	The randomization is deterministic based for a given seed, so the entire
5268	program should be compiled with the same seed, but keep the seed safe
5269	otherwise.
5270
5271	The attribute ``no_randomize_layout``, when attached to a C structure,
5272	instructs the compiler that this structure should not have its field layout
5273	randomized.)reST";
5274
5275	static const char AttrDoc_NoReturn[] = R"reST(No documentation.)reST";
5276
5277	static const char AttrDoc_NoSanitize[] = R"reST(Use the ``no_sanitize`` attribute on a function or a global variable
5278	declaration to specify that a particular instrumentation or set of
5279	instrumentations should not be applied.
5280
5281	The attribute takes a list of string literals with the following accepted
5282	values:
5283
5284	* all values accepted by ``-fno-sanitize=``;
5285	* ``coverage``, to disable SanitizerCoverage instrumentation.
5286
5287	For example, ``__attribute__((no_sanitize("address", "thread")))`` specifies
5288	that AddressSanitizer and ThreadSanitizer should not be applied to the function
5289	or variable. Using ``__attribute__((no_sanitize("coverage")))`` specifies that
5290	SanitizerCoverage should not be applied to the function.
5291
5292	See :ref:`Controlling Code Generation <controlling-code-generation>` for a
5293	full list of supported sanitizer flags.)reST";
5294
5295	static const char AttrDoc_NoSpecializations[] = R"reST(``[[clang::no_specializations]]`` can be applied to function, class, or variable
5296	templates which should not be explicitly specialized by users. This is primarily
5297	used to diagnose user specializations of standard library type traits.)reST";
5298
5299	static const char AttrDoc_NoSpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
5300	that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
5301	is not needed for the function body. This can also be applied to a method
5302	in Objective C. This attribute will take precedence over the command line flag in
5303	the case where `-mspeculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
5304
5305	Warning: This attribute may not prevent Speculative Load Hardening from being
5306	enabled for a function which inlines a function that has the
5307	'speculative_load_hardening' attribute. This is intended to provide a
5308	maximally conservative model where the code that is marked with the
5309	'speculative_load_hardening' attribute will always (even when inlined)
5310	be hardened. A user of this attribute may want to mark functions called by
5311	a function they do not want to be hardened with the 'noinline' attribute.
5312
5313	For example:
5314
5315	.. code-block:: c
5316
5317	__attribute__((speculative_load_hardening))
5318	int foo(int i) {
5319	return i;
5320	}
5321
5322	// Note: bar() may still have speculative load hardening enabled if
5323	// foo() is inlined into bar(). Mark foo() with __attribute__((noinline))
5324	// to avoid this situation.
5325	__attribute__((no_speculative_load_hardening))
5326	int bar(int i) {
5327	return foo(i);
5328	})reST";
5329
5330	static const char AttrDoc_NoSplitStack[] = R"reST(The ``no_split_stack`` attribute disables the emission of the split stack
5331	preamble for a particular function. It has no effect if ``-fsplit-stack``
5332	is not specified.)reST";
5333
5334	static const char AttrDoc_NoStackProtector[] = R"reST(Clang supports the GNU style ``__attribute__((no_stack_protector))`` and Microsoft
5335	style ``__declspec(safebuffers)`` attribute which disables
5336	the stack protector on the specified function. This attribute is useful for
5337	selectively disabling the stack protector on some functions when building with
5338	``-fstack-protector`` compiler option.
5339
5340	For example, it disables the stack protector for the function ``foo`` but function
5341	``bar`` will still be built with the stack protector with the ``-fstack-protector``
5342	option.
5343
5344	.. code-block:: c
5345
5346	int __attribute__((no_stack_protector))
5347	foo (int x); // stack protection will be disabled for foo.
5348
5349	int bar(int y); // bar can be built with the stack protector.)reST";
5350
5351	static const char AttrDoc_NoThreadSafetyAnalysis[] = R"reST(No documentation.)reST";
5352
5353	static const char AttrDoc_NoThrow[] = R"reST(Clang supports the GNU style ``__attribute__((nothrow))`` and Microsoft style
5354	``__declspec(nothrow)`` attribute as an equivalent of ``noexcept`` on function
5355	declarations. This attribute informs the compiler that the annotated function
5356	does not throw an exception. This prevents exception-unwinding. This attribute
5357	is particularly useful on functions in the C Standard Library that are
5358	guaranteed to not throw an exception.)reST";
5359
5360	static const char AttrDoc_NoTrivialAutoVarInit[] = R"reST(The ``__declspec(no_init_all)`` attribute disables the automatic initialization that the
5361	`-ftrivial-auto-var-init`_ flag would have applied to locals in a marked function, or instances of
5362	a marked type. Note that this attribute has no effect for locals that are automatically initialized
5363	without the `-ftrivial-auto-var-init`_ flag.
5364
5365	.. _`-ftrivial-auto-var-init`: ClangCommandLineReference.html#cmdoption-clang-ftrivial-auto-var-init)reST";
5366
5367	static const char AttrDoc_NoUniqueAddress[] = R"reST(The ``no_unique_address`` attribute allows tail padding in a non-static data
5368	member to overlap other members of the enclosing class (and in the special
5369	case when the type is empty, permits it to fully overlap other members).
5370	The field is laid out as if a base class were encountered at the corresponding
5371	point within the class (except that it does not share a vptr with the enclosing
5372	object).
5373
5374	Example usage:
5375
5376	.. code-block:: c++
5377
5378	template<typename T, typename Alloc> struct my_vector {
5379	T *p;
5380	[[no_unique_address]] Alloc alloc;
5381	// ...
5382	};
5383	static_assert(sizeof(my_vector<int, std::allocator<int>>) == sizeof(int*));
5384
5385	``[[no_unique_address]]`` is a standard C++20 attribute. Clang supports its use
5386	in C++11 onwards.
5387
5388	On MSVC targets, ``[[no_unique_address]]`` is ignored; use
5389	``[[msvc::no_unique_address]]`` instead. Currently there is no guarantee of ABI
5390	compatibility or stability with MSVC.)reST";
5391
5392	static const char AttrDoc_NoUwtable[] = R"reST(Clang supports the ``nouwtable`` attribute which skips emitting
5393	the unwind table entry for the specified function. This attribute is useful for
5394	selectively emitting the unwind table entry on some functions when building with
5395	``-funwind-tables`` compiler option.)reST";
5396
5397	static const char AttrDoc_NonAllocating[] = R"reST(Declares that a function or function type either does or does not allocate heap memory, according
5398	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
5399	is false, the attribute is equivalent to ``allocating``.)reST";
5400
5401	static const char AttrDoc_NonBlocking[] = R"reST(Declares that a function or function type either does or does not block in any way, according
5402	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
5403	is false, the attribute is equivalent to ``blocking``.
5404
5405	For the purposes of diagnostics, ``nonblocking`` is considered to include the
5406	``nonallocating`` guarantee and is therefore a "stronger" constraint or attribute.)reST";
5407
5408	static const char AttrDoc_NonNull[] = R"reST(The ``nonnull`` attribute indicates that some function parameters must not be
5409	null, and can be used in several different ways. It's original usage
5410	(`from GCC <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes>`_)
5411	is as a function (or Objective-C method) attribute that specifies which
5412	parameters of the function are nonnull in a comma-separated list. For example:
5413
5414	.. code-block:: c
5415
5416	extern void * my_memcpy (void dest, const void src, size_t len)
5417	__attribute__((nonnull (1, 2)));
5418
5419	Here, the ``nonnull`` attribute indicates that parameters 1 and 2
5420	cannot have a null value. Omitting the parenthesized list of parameter indices
5421	means that all parameters of pointer type cannot be null:
5422
5423	.. code-block:: c
5424
5425	extern void * my_memcpy (void dest, const void src, size_t len)
5426	__attribute__((nonnull));
5427
5428	Clang also allows the ``nonnull`` attribute to be placed directly on a function
5429	(or Objective-C method) parameter, eliminating the need to specify the
5430	parameter index ahead of type. For example:
5431
5432	.. code-block:: c
5433
5434	extern void * my_memcpy (void *dest __attribute__((nonnull)),
5435	const void *src __attribute__((nonnull)), size_t len);
5436
5437	Note that the ``nonnull`` attribute indicates that passing null to a non-null
5438	parameter is undefined behavior, which the optimizer may take advantage of to,
5439	e.g., remove null checks. The ``_Nonnull`` type qualifier indicates that a
5440	pointer cannot be null in a more general manner (because it is part of the type
5441	system) and does not imply undefined behavior, making it more widely applicable.)reST";
5442
5443	static const char AttrDoc_NonString[] = R"reST(The ``nonstring`` attribute can be applied to the declaration of a variable or
5444	a field whose type is a character pointer or character array to specify that
5445	the buffer is not intended to behave like a null-terminated string. This will
5446	silence diagnostics with code like:
5447
5448	.. code-block:: c
5449
5450	char BadStr[3] = "foo"; // No space for the null terminator, diagnosed
5451	__attribute__((nonstring)) char NotAStr[3] = "foo"; // Not diagnosed)reST";
5452
5453	static const char AttrDoc_NotTailCalled[] = R"reST(The ``not_tail_called`` attribute prevents tail-call optimization on statically
5454	bound calls. Objective-c methods, and functions marked as ``always_inline``
5455	cannot be marked as ``not_tail_called``.
5456
5457	For example, it prevents tail-call optimization in the following case:
5458
5459	.. code-block:: c
5460
5461	int __attribute__((not_tail_called)) foo1(int);
5462
5463	int foo2(int a) {
5464	return foo1(a); // No tail-call optimization on direct calls.
5465	}
5466
5467	However, it doesn't prevent tail-call optimization in this case:
5468
5469	.. code-block:: c
5470
5471	int __attribute__((not_tail_called)) foo1(int);
5472
5473	int foo2(int a) {
5474	int (*fn)(int) = &foo1;
5475
5476	// not_tail_called has no effect on an indirect call even if the call can
5477	// be resolved at compile time.
5478	return (*fn)(a);
5479	}
5480
5481	Generally, marking an overriding virtual function as ``not_tail_called`` is
5482	not useful, because this attribute is a property of the static type. Calls
5483	made through a pointer or reference to the base class type will respect
5484	the ``not_tail_called`` attribute of the base class's member function,
5485	regardless of the runtime destination of the call:
5486
5487	.. code-block:: c++
5488
5489	struct Foo { virtual void f(); };
5490	struct Bar : Foo {
5491	[[clang::not_tail_called]] void f() override;
5492	};
5493	void callera(Bar& bar) {
5494	Foo& foo = bar;
5495	// not_tail_called has no effect on here, even though the
5496	// underlying method is f from Bar.
5497	foo.f();
5498	bar.f(); // No tail-call optimization on here.
5499	})reST";
5500
5501	static const char AttrDoc_OMPAllocateDecl[] = R"reST()reST";
5502
5503	static const char AttrDoc_OMPAssume[] = R"reST(Clang supports the ``[[omp::assume("assumption")]]`` attribute to
5504	provide additional information to the optimizer. The string-literal, here
5505	"assumption", will be attached to the function declaration such that later
5506	analysis and optimization passes can assume the "assumption" to hold.
5507	This is similar to :ref:`__builtin_assume <langext-__builtin_assume>` but
5508	instead of an expression that can be assumed to be non-zero, the assumption is
5509	expressed as a string and it holds for the entire function.
5510
5511	A function can have multiple assume attributes and they propagate from prior
5512	declarations to later definitions. Multiple assumptions are aggregated into a
5513	single comma separated string. Thus, one can provide multiple assumptions via
5514	a comma separated string, i.a.,
5515	``[[omp::assume("assumption1,assumption2")]]``.
5516
5517	While LLVM plugins might provide more assumption strings, the default LLVM
5518	optimization passes are aware of the following assumptions:
5519
5520	.. code-block:: none
5521
5522	"omp_no_openmp"
5523	"omp_no_openmp_routines"
5524	"omp_no_parallelism"
5525	"omp_no_openmp_constructs"
5526
5527	The OpenMP standard defines the meaning of OpenMP assumptions ("omp_XYZ" is
5528	spelled "XYZ" in the `OpenMP 5.1 Standard`_).
5529
5530	.. _`OpenMP 5.1 Standard`: https://www.openmp.org/spec-html/5.1/openmpsu37.html#x56-560002.5.2)reST";
5531
5532	static const char AttrDoc_OMPCaptureKind[] = R"reST()reST";
5533
5534	static const char AttrDoc_OMPCaptureNoInit[] = R"reST()reST";
5535
5536	static const char AttrDoc_OMPDeclareSimdDecl[] = R"reST(The ``declare simd`` construct can be applied to a function to enable the creation
5537	of one or more versions that can process multiple arguments using SIMD
5538	instructions from a single invocation in a SIMD loop. The ``declare simd``
5539	directive is a declarative directive. There may be multiple ``declare simd``
5540	directives for a function. The use of a ``declare simd`` construct on a function
5541	enables the creation of SIMD versions of the associated function that can be
5542	used to process multiple arguments from a single invocation from a SIMD loop
5543	concurrently.
5544	The syntax of the ``declare simd`` construct is as follows:
5545
5546	.. code-block:: none
5547
5548	#pragma omp declare simd [clause[[,] clause] ...] new-line
5549	[#pragma omp declare simd [clause[[,] clause] ...] new-line]
5550	[...]
5551	function definition or declaration
5552
5553	where clause is one of the following:
5554
5555	.. code-block:: none
5556
5557	simdlen(length)
5558	linear(argument-list[:constant-linear-step])
5559	aligned(argument-list[:alignment])
5560	uniform(argument-list)
5561	inbranch
5562	notinbranch)reST";
5563
5564	static const char AttrDoc_OMPDeclareTargetDecl[] = R"reST(The ``declare target`` directive specifies that variables and functions are mapped
5565	to a device for OpenMP offload mechanism.
5566
5567	The syntax of the declare target directive is as follows:
5568
5569	.. code-block:: c
5570
5571	#pragma omp declare target new-line
5572	declarations-definition-seq
5573	#pragma omp end declare target new-line
5574
5575	or
5576
5577	.. code-block:: c
5578
5579	#pragma omp declare target (extended-list) new-line
5580
5581	or
5582
5583	.. code-block:: c
5584
5585	#pragma omp declare target clause[ [,] clause ... ] new-line
5586
5587	where clause is one of the following:
5588
5589
5590	.. code-block:: c
5591
5592	to(extended-list)
5593	link(list)
5594	device_type(host \| nohost \| any))reST";
5595
5596	static const char AttrDoc_OMPDeclareVariant[] = R"reST(The ``declare variant`` directive declares a specialized variant of a base
5597	function and specifies the context in which that specialized variant is used.
5598	The declare variant directive is a declarative directive.
5599	The syntax of the ``declare variant`` construct is as follows:
5600
5601	.. code-block:: none
5602
5603	#pragma omp declare variant(variant-func-id) clause new-line
5604	[#pragma omp declare variant(variant-func-id) clause new-line]
5605	[...]
5606	function definition or declaration
5607
5608	where clause is one of the following:
5609
5610	.. code-block:: none
5611
5612	match(context-selector-specification)
5613
5614	and where ``variant-func-id`` is the name of a function variant that is either a
5615	base language identifier or, for C++, a template-id.
5616
5617	Clang provides the following context selector extensions, used via
5618	``implementation={extension(EXTENSION)}``:
5619
5620	.. code-block:: none
5621
5622	match_all
5623	match_any
5624	match_none
5625	disable_implicit_base
5626	allow_templates
5627	bind_to_declaration
5628
5629	The match extensions change when the entire context selector is considered a
5630	match for an OpenMP context. The default is ``all``, with ``none`` no trait in the
5631	selector is allowed to be in the OpenMP context, with ``any`` a single trait in
5632	both the selector and OpenMP context is sufficient. Only a single match
5633	extension trait is allowed per context selector.
5634	The disable extensions remove default effects of the ``begin declare variant``
5635	applied to a definition. If ``disable_implicit_base`` is given, we will not
5636	introduce an implicit base function for a variant if no base function was
5637	found. The variant is still generated but will never be called, due to the
5638	absence of a base function and consequently calls to a base function.
5639	The allow extensions change when the ``begin declare variant`` effect is
5640	applied to a definition. If ``allow_templates`` is given, template function
5641	definitions are considered as specializations of existing or assumed template
5642	declarations with the same name. The template parameters for the base functions
5643	are used to instantiate the specialization. If ``bind_to_declaration`` is given,
5644	apply the same variant rules to function declarations. This allows the user to
5645	override declarations with only a function declaration.)reST";
5646
5647	static const char AttrDoc_OMPGroupPrivateDecl[] = R"reST()reST";
5648
5649	static const char AttrDoc_OMPReferencedVar[] = R"reST()reST";
5650
5651	static const char AttrDoc_OMPThreadPrivateDecl[] = R"reST()reST";
5652
5653	static const char AttrDoc_OSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5654	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5655	convention (e.g. functions starting with "get" are assumed to return at
5656	``+0``).
5657
5658	It can be overridden using a family of the following attributes. In
5659	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5660	a function communicates that the object is returned at ``+1``, and the caller
5661	is responsible for freeing it.
5662	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5663	specifies that the object is returned at ``+0`` and the ownership remains with
5664	the callee.
5665	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5666	the Objective-C method call consumes the reference to ``self``, e.g. by
5667	attaching it to a supplied parameter.
5668	Additionally, parameters can have an annotation
5669	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5670	as that parameter effectively transfers the ownership, and the caller is no
5671	longer responsible for it.
5672	These attributes affect code generation when interacting with ARC code, and
5673	they are used by the Clang Static Analyzer.
5674
5675	In C programs using CoreFoundation, a similar set of attributes:
5676	``__attribute__((cf_returns_not_retained))``,
5677	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5678	have the same respective semantics when applied to CoreFoundation objects.
5679	These attributes affect code generation when interacting with ARC code, and
5680	they are used by the Clang Static Analyzer.
5681
5682	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5683	the same attribute family is present:
5684	``__attribute__((os_returns_not_retained))``,
5685	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5686	with the same respective semantics.
5687	Similar to ``__attribute__((ns_consumes_self))``,
5688	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5689	the reference to "this" (e.g., when attaching it to a different object supplied
5690	as a parameter).
5691	Out parameters (parameters the function is meant to write into,
5692	either via pointers-to-pointers or references-to-pointers)
5693	may be annotated with ``__attribute__((os_returns_retained))``
5694	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5695	written into the out parameter should (or respectively should not) be released
5696	after use.
5697	Since often out parameters may or may not be written depending on the exit
5698	code of the function,
5699	annotations ``__attribute__((os_returns_retained_on_zero))``
5700	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5701	an out parameter at ``+1`` is written if and only if the function returns a zero
5702	(respectively non-zero) error code.
5703	Observe that return-code-dependent out parameter annotations are only
5704	available for retained out parameters, as non-retained object do not have to be
5705	released by the callee.
5706	These attributes are only used by the Clang Static Analyzer.
5707
5708	The family of attributes ``X_returns_X_retained`` can be added to functions,
5709	C++ methods, and Objective-C methods and properties.
5710	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5711	and Objective-C methods.)reST";
5712
5713	static const char AttrDoc_OSConsumesThis[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5714	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5715	convention (e.g. functions starting with "get" are assumed to return at
5716	``+0``).
5717
5718	It can be overridden using a family of the following attributes. In
5719	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5720	a function communicates that the object is returned at ``+1``, and the caller
5721	is responsible for freeing it.
5722	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5723	specifies that the object is returned at ``+0`` and the ownership remains with
5724	the callee.
5725	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5726	the Objective-C method call consumes the reference to ``self``, e.g. by
5727	attaching it to a supplied parameter.
5728	Additionally, parameters can have an annotation
5729	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5730	as that parameter effectively transfers the ownership, and the caller is no
5731	longer responsible for it.
5732	These attributes affect code generation when interacting with ARC code, and
5733	they are used by the Clang Static Analyzer.
5734
5735	In C programs using CoreFoundation, a similar set of attributes:
5736	``__attribute__((cf_returns_not_retained))``,
5737	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5738	have the same respective semantics when applied to CoreFoundation objects.
5739	These attributes affect code generation when interacting with ARC code, and
5740	they are used by the Clang Static Analyzer.
5741
5742	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5743	the same attribute family is present:
5744	``__attribute__((os_returns_not_retained))``,
5745	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5746	with the same respective semantics.
5747	Similar to ``__attribute__((ns_consumes_self))``,
5748	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5749	the reference to "this" (e.g., when attaching it to a different object supplied
5750	as a parameter).
5751	Out parameters (parameters the function is meant to write into,
5752	either via pointers-to-pointers or references-to-pointers)
5753	may be annotated with ``__attribute__((os_returns_retained))``
5754	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5755	written into the out parameter should (or respectively should not) be released
5756	after use.
5757	Since often out parameters may or may not be written depending on the exit
5758	code of the function,
5759	annotations ``__attribute__((os_returns_retained_on_zero))``
5760	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5761	an out parameter at ``+1`` is written if and only if the function returns a zero
5762	(respectively non-zero) error code.
5763	Observe that return-code-dependent out parameter annotations are only
5764	available for retained out parameters, as non-retained object do not have to be
5765	released by the callee.
5766	These attributes are only used by the Clang Static Analyzer.
5767
5768	The family of attributes ``X_returns_X_retained`` can be added to functions,
5769	C++ methods, and Objective-C methods and properties.
5770	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5771	and Objective-C methods.)reST";
5772
5773	static const char AttrDoc_OSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5774	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5775	convention (e.g. functions starting with "get" are assumed to return at
5776	``+0``).
5777
5778	It can be overridden using a family of the following attributes. In
5779	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5780	a function communicates that the object is returned at ``+1``, and the caller
5781	is responsible for freeing it.
5782	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5783	specifies that the object is returned at ``+0`` and the ownership remains with
5784	the callee.
5785	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5786	the Objective-C method call consumes the reference to ``self``, e.g. by
5787	attaching it to a supplied parameter.
5788	Additionally, parameters can have an annotation
5789	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5790	as that parameter effectively transfers the ownership, and the caller is no
5791	longer responsible for it.
5792	These attributes affect code generation when interacting with ARC code, and
5793	they are used by the Clang Static Analyzer.
5794
5795	In C programs using CoreFoundation, a similar set of attributes:
5796	``__attribute__((cf_returns_not_retained))``,
5797	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5798	have the same respective semantics when applied to CoreFoundation objects.
5799	These attributes affect code generation when interacting with ARC code, and
5800	they are used by the Clang Static Analyzer.
5801
5802	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5803	the same attribute family is present:
5804	``__attribute__((os_returns_not_retained))``,
5805	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5806	with the same respective semantics.
5807	Similar to ``__attribute__((ns_consumes_self))``,
5808	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5809	the reference to "this" (e.g., when attaching it to a different object supplied
5810	as a parameter).
5811	Out parameters (parameters the function is meant to write into,
5812	either via pointers-to-pointers or references-to-pointers)
5813	may be annotated with ``__attribute__((os_returns_retained))``
5814	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5815	written into the out parameter should (or respectively should not) be released
5816	after use.
5817	Since often out parameters may or may not be written depending on the exit
5818	code of the function,
5819	annotations ``__attribute__((os_returns_retained_on_zero))``
5820	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5821	an out parameter at ``+1`` is written if and only if the function returns a zero
5822	(respectively non-zero) error code.
5823	Observe that return-code-dependent out parameter annotations are only
5824	available for retained out parameters, as non-retained object do not have to be
5825	released by the callee.
5826	These attributes are only used by the Clang Static Analyzer.
5827
5828	The family of attributes ``X_returns_X_retained`` can be added to functions,
5829	C++ methods, and Objective-C methods and properties.
5830	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5831	and Objective-C methods.)reST";
5832
5833	static const char AttrDoc_OSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5834	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5835	convention (e.g. functions starting with "get" are assumed to return at
5836	``+0``).
5837
5838	It can be overridden using a family of the following attributes. In
5839	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5840	a function communicates that the object is returned at ``+1``, and the caller
5841	is responsible for freeing it.
5842	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5843	specifies that the object is returned at ``+0`` and the ownership remains with
5844	the callee.
5845	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5846	the Objective-C method call consumes the reference to ``self``, e.g. by
5847	attaching it to a supplied parameter.
5848	Additionally, parameters can have an annotation
5849	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5850	as that parameter effectively transfers the ownership, and the caller is no
5851	longer responsible for it.
5852	These attributes affect code generation when interacting with ARC code, and
5853	they are used by the Clang Static Analyzer.
5854
5855	In C programs using CoreFoundation, a similar set of attributes:
5856	``__attribute__((cf_returns_not_retained))``,
5857	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5858	have the same respective semantics when applied to CoreFoundation objects.
5859	These attributes affect code generation when interacting with ARC code, and
5860	they are used by the Clang Static Analyzer.
5861
5862	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5863	the same attribute family is present:
5864	``__attribute__((os_returns_not_retained))``,
5865	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5866	with the same respective semantics.
5867	Similar to ``__attribute__((ns_consumes_self))``,
5868	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5869	the reference to "this" (e.g., when attaching it to a different object supplied
5870	as a parameter).
5871	Out parameters (parameters the function is meant to write into,
5872	either via pointers-to-pointers or references-to-pointers)
5873	may be annotated with ``__attribute__((os_returns_retained))``
5874	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5875	written into the out parameter should (or respectively should not) be released
5876	after use.
5877	Since often out parameters may or may not be written depending on the exit
5878	code of the function,
5879	annotations ``__attribute__((os_returns_retained_on_zero))``
5880	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5881	an out parameter at ``+1`` is written if and only if the function returns a zero
5882	(respectively non-zero) error code.
5883	Observe that return-code-dependent out parameter annotations are only
5884	available for retained out parameters, as non-retained object do not have to be
5885	released by the callee.
5886	These attributes are only used by the Clang Static Analyzer.
5887
5888	The family of attributes ``X_returns_X_retained`` can be added to functions,
5889	C++ methods, and Objective-C methods and properties.
5890	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5891	and Objective-C methods.)reST";
5892
5893	static const char AttrDoc_OSReturnsRetainedOnNonZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5894	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5895	convention (e.g. functions starting with "get" are assumed to return at
5896	``+0``).
5897
5898	It can be overridden using a family of the following attributes. In
5899	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5900	a function communicates that the object is returned at ``+1``, and the caller
5901	is responsible for freeing it.
5902	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5903	specifies that the object is returned at ``+0`` and the ownership remains with
5904	the callee.
5905	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5906	the Objective-C method call consumes the reference to ``self``, e.g. by
5907	attaching it to a supplied parameter.
5908	Additionally, parameters can have an annotation
5909	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5910	as that parameter effectively transfers the ownership, and the caller is no
5911	longer responsible for it.
5912	These attributes affect code generation when interacting with ARC code, and
5913	they are used by the Clang Static Analyzer.
5914
5915	In C programs using CoreFoundation, a similar set of attributes:
5916	``__attribute__((cf_returns_not_retained))``,
5917	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5918	have the same respective semantics when applied to CoreFoundation objects.
5919	These attributes affect code generation when interacting with ARC code, and
5920	they are used by the Clang Static Analyzer.
5921
5922	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5923	the same attribute family is present:
5924	``__attribute__((os_returns_not_retained))``,
5925	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5926	with the same respective semantics.
5927	Similar to ``__attribute__((ns_consumes_self))``,
5928	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5929	the reference to "this" (e.g., when attaching it to a different object supplied
5930	as a parameter).
5931	Out parameters (parameters the function is meant to write into,
5932	either via pointers-to-pointers or references-to-pointers)
5933	may be annotated with ``__attribute__((os_returns_retained))``
5934	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5935	written into the out parameter should (or respectively should not) be released
5936	after use.
5937	Since often out parameters may or may not be written depending on the exit
5938	code of the function,
5939	annotations ``__attribute__((os_returns_retained_on_zero))``
5940	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5941	an out parameter at ``+1`` is written if and only if the function returns a zero
5942	(respectively non-zero) error code.
5943	Observe that return-code-dependent out parameter annotations are only
5944	available for retained out parameters, as non-retained object do not have to be
5945	released by the callee.
5946	These attributes are only used by the Clang Static Analyzer.
5947
5948	The family of attributes ``X_returns_X_retained`` can be added to functions,
5949	C++ methods, and Objective-C methods and properties.
5950	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5951	and Objective-C methods.)reST";
5952
5953	static const char AttrDoc_OSReturnsRetainedOnZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5954	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5955	convention (e.g. functions starting with "get" are assumed to return at
5956	``+0``).
5957
5958	It can be overridden using a family of the following attributes. In
5959	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5960	a function communicates that the object is returned at ``+1``, and the caller
5961	is responsible for freeing it.
5962	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5963	specifies that the object is returned at ``+0`` and the ownership remains with
5964	the callee.
5965	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5966	the Objective-C method call consumes the reference to ``self``, e.g. by
5967	attaching it to a supplied parameter.
5968	Additionally, parameters can have an annotation
5969	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5970	as that parameter effectively transfers the ownership, and the caller is no
5971	longer responsible for it.
5972	These attributes affect code generation when interacting with ARC code, and
5973	they are used by the Clang Static Analyzer.
5974
5975	In C programs using CoreFoundation, a similar set of attributes:
5976	``__attribute__((cf_returns_not_retained))``,
5977	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5978	have the same respective semantics when applied to CoreFoundation objects.
5979	These attributes affect code generation when interacting with ARC code, and
5980	they are used by the Clang Static Analyzer.
5981
5982	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5983	the same attribute family is present:
5984	``__attribute__((os_returns_not_retained))``,
5985	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5986	with the same respective semantics.
5987	Similar to ``__attribute__((ns_consumes_self))``,
5988	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5989	the reference to "this" (e.g., when attaching it to a different object supplied
5990	as a parameter).
5991	Out parameters (parameters the function is meant to write into,
5992	either via pointers-to-pointers or references-to-pointers)
5993	may be annotated with ``__attribute__((os_returns_retained))``
5994	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5995	written into the out parameter should (or respectively should not) be released
5996	after use.
5997	Since often out parameters may or may not be written depending on the exit
5998	code of the function,
5999	annotations ``__attribute__((os_returns_retained_on_zero))``
6000	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
6001	an out parameter at ``+1`` is written if and only if the function returns a zero
6002	(respectively non-zero) error code.
6003	Observe that return-code-dependent out parameter annotations are only
6004	available for retained out parameters, as non-retained object do not have to be
6005	released by the callee.
6006	These attributes are only used by the Clang Static Analyzer.
6007
6008	The family of attributes ``X_returns_X_retained`` can be added to functions,
6009	C++ methods, and Objective-C methods and properties.
6010	Attributes ``X_consumed`` can be added to parameters of methods, functions,
6011	and Objective-C methods.)reST";
6012
6013	static const char AttrDoc_ObjCBoxable[] = R"reST(Structs and unions marked with the ``objc_boxable`` attribute can be used
6014	with the Objective-C boxed expression syntax, ``@(...)``.
6015
6016	Usage: ``__attribute__((objc_boxable))``. This attribute
6017	can only be placed on a declaration of a trivially-copyable struct or union:
6018
6019	.. code-block:: objc
6020
6021	struct __attribute__((objc_boxable)) some_struct {
6022	int i;
6023	};
6024	union __attribute__((objc_boxable)) some_union {
6025	int i;
6026	float f;
6027	};
6028	typedef struct __attribute__((objc_boxable)) _some_struct some_struct;
6029
6030	// ...
6031
6032	some_struct ss;
6033	NSValue *boxed = @(ss);)reST";
6034
6035	static const char AttrDoc_ObjCBridge[] = R"reST(No documentation.)reST";
6036
6037	static const char AttrDoc_ObjCBridgeMutable[] = R"reST(No documentation.)reST";
6038
6039	static const char AttrDoc_ObjCBridgeRelated[] = R"reST(No documentation.)reST";
6040
6041	static const char AttrDoc_ObjCClassStub[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
6042	instantiated at runtime.
6043
6044	Unlike ``__attribute__((objc_runtime_visible))``, a class having this attribute
6045	still has a "class stub" that is visible to the linker. This allows categories
6046	to be defined. Static message sends with the class as a receiver use a special
6047	access pattern to ensure the class is lazily instantiated from the class stub.
6048
6049	Classes annotated with this attribute cannot be subclassed and cannot have
6050	implementations defined for them. This attribute is intended for use in
6051	Swift-generated headers for classes defined in Swift.
6052
6053	Adding or removing this attribute to a class is an ABI-breaking change.)reST";
6054
6055	static const char AttrDoc_ObjCDesignatedInitializer[] = R"reST(No documentation.)reST";
6056
6057	static const char AttrDoc_ObjCDirect[] = R"reST(The ``objc_direct`` attribute can be used to mark an Objective-C method as
6058	being direct. A direct method is treated statically like an ordinary method,
6059	but dynamically it behaves more like a C function. This lowers some of the costs
6060	associated with the method but also sacrifices some of the ordinary capabilities
6061	of Objective-C methods.
6062
6063	A message send of a direct method calls the implementation directly, as if it
6064	were a C function, rather than using ordinary Objective-C method dispatch. This
6065	is substantially faster and potentially allows the implementation to be inlined,
6066	but it also means the method cannot be overridden in subclasses or replaced
6067	dynamically, as ordinary Objective-C methods can.
6068
6069	Furthermore, a direct method is not listed in the class's method lists. This
6070	substantially reduces the code-size overhead of the method but also means it
6071	cannot be called dynamically using ordinary Objective-C method dispatch at all;
6072	in particular, this means that it cannot override a superclass method or satisfy
6073	a protocol requirement.
6074
6075	Because a direct method cannot be overridden, it is an error to perform
6076	a ``super`` message send of one.
6077
6078	Although a message send of a direct method causes the method to be called
6079	directly as if it were a C function, it still obeys Objective-C semantics in other
6080	ways:
6081
6082	- If the receiver is ``nil``, the message send does nothing and returns the zero value
6083	for the return type.
6084
6085	- A message send of a direct class method will cause the class to be initialized,
6086	including calling the ``+initialize`` method if present.
6087
6088	- The implicit ``_cmd`` parameter containing the method's selector is still defined.
6089	In order to minimize code-size costs, the implementation will not emit a reference
6090	to the selector if the parameter is unused within the method.
6091
6092	Symbols for direct method implementations are implicitly given hidden
6093	visibility, meaning that they can only be called within the same linkage unit.
6094
6095	It is an error to do any of the following:
6096
6097	- declare a direct method in a protocol,
6098	- declare an override of a direct method with a method in a subclass,
6099	- declare an override of a non-direct method with a direct method in a subclass,
6100	- declare a method with different directness in different class interfaces, or
6101	- implement a non-direct method (as declared in any class interface) with a direct method.
6102
6103	If any of these rules would be violated if every method defined in an
6104	``@implementation`` within a single linkage unit were declared in an
6105	appropriate class interface, the program is ill-formed with no diagnostic
6106	required. If a violation of this rule is not diagnosed, behavior remains
6107	well-defined; this paragraph is simply reserving the right to diagnose such
6108	conflicts in the future, not to treat them as undefined behavior.
6109
6110	Additionally, Clang will warn about any ``@selector`` expression that
6111	names a selector that is only known to be used for direct methods.
6112
6113	For the purpose of these rules, a "class interface" includes a class's primary
6114	``@interface`` block, its class extensions, its categories, its declared protocols,
6115	and all the class interfaces of its superclasses.
6116
6117	An Objective-C property can be declared with the ``direct`` property
6118	attribute. If a direct property declaration causes an implicit declaration of
6119	a getter or setter method (that is, if the given method is not explicitly
6120	declared elsewhere), the method is declared to be direct.
6121
6122	Some programmers may wish to make many methods direct at once. In order
6123	to simplify this, the ``objc_direct_members`` attribute is provided; see its
6124	documentation for more information.)reST";
6125
6126	static const char AttrDoc_ObjCDirectMembers[] = R"reST(The ``objc_direct_members`` attribute can be placed on an Objective-C
6127	``@interface`` or ``@implementation`` to mark that methods declared
6128	therein should be considered direct by default. See the documentation
6129	for ``objc_direct`` for more information about direct methods.
6130
6131	When ``objc_direct_members`` is placed on an ``@interface`` block, every
6132	method in the block is considered to be declared as direct. This includes any
6133	implicit method declarations introduced by property declarations. If the method
6134	redeclares a non-direct method, the declaration is ill-formed, exactly as if the
6135	method was annotated with the ``objc_direct`` attribute.
6136
6137	When ``objc_direct_members`` is placed on an ``@implementation`` block,
6138	methods defined in the block are considered to be declared as direct unless
6139	they have been previously declared as non-direct in any interface of the class.
6140	This includes the implicit method definitions introduced by synthesized
6141	properties, including auto-synthesized properties.)reST";
6142
6143	static const char AttrDoc_ObjCException[] = R"reST(No documentation.)reST";
6144
6145	static const char AttrDoc_ObjCExplicitProtocolImpl[] = R"reST(No documentation.)reST";
6146
6147	static const char AttrDoc_ObjCExternallyRetained[] = R"reST(The ``objc_externally_retained`` attribute can be applied to strong local
6148	variables, functions, methods, or blocks to opt into
6149	`externally-retained semantics
6150	<https://clang.llvm.org/docs/AutomaticReferenceCounting.html#externally-retained-variables>`_.
6151
6152	When applied to the definition of a function, method, or block, every parameter
6153	of the function with implicit strong retainable object pointer type is
6154	considered externally-retained, and becomes ``const``. By explicitly annotating
6155	a parameter with ``__strong``, you can opt back into the default
6156	non-externally-retained behavior for that parameter. For instance,
6157	``first_param`` is externally-retained below, but not ``second_param``:
6158
6159	.. code-block:: objc
6160
6161	__attribute__((objc_externally_retained))
6162	void f(NSArray first_param, __strong NSArray second_param) {
6163	// ...
6164	}
6165
6166	Likewise, when applied to a strong local variable, that variable becomes
6167	``const`` and is considered externally-retained.
6168
6169	When compiled without ``-fobjc-arc``, this attribute is ignored.)reST";
6170
6171	static const char AttrDoc_ObjCGC[] = R"reST(No documentation.)reST";
6172
6173	static const char AttrDoc_ObjCIndependentClass[] = R"reST(No documentation.)reST";
6174
6175	static const char AttrDoc_ObjCInertUnsafeUnretained[] = R"reST()reST";
6176
6177	static const char AttrDoc_ObjCKindOf[] = R"reST(No documentation.)reST";
6178
6179	static const char AttrDoc_ObjCMethodFamily[] = R"reST(Many methods in Objective-C have conventional meanings determined by their
6180	selectors. It is sometimes useful to be able to mark a method as having a
6181	particular conventional meaning despite not having the right selector, or as
6182	not having the conventional meaning that its selector would suggest. For these
6183	use cases, we provide an attribute to specifically describe the "method family"
6184	that a method belongs to.
6185
6186	Usage: ``__attribute__((objc_method_family(X)))``, where ``X`` is one of
6187	``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This
6188	attribute can only be placed at the end of a method declaration:
6189
6190	.. code-block:: objc
6191
6192	- (NSString *)initMyStringValue __attribute__((objc_method_family(none)));
6193
6194	Users who do not wish to change the conventional meaning of a method, and who
6195	merely want to document its non-standard retain and release semantics, should
6196	use the retaining behavior attributes (``ns_returns_retained``,
6197	``ns_returns_not_retained``, etc).
6198
6199	Query for this feature with ``__has_attribute(objc_method_family)``.)reST";
6200
6201	static const char AttrDoc_ObjCNSObject[] = R"reST(No documentation.)reST";
6202
6203	static const char AttrDoc_ObjCNonLazyClass[] = R"reST(This attribute can be added to an Objective-C ``@interface`` or
6204	``@implementation`` declaration to add the class to the list of non-lazily
6205	initialized classes. A non-lazy class will be initialized eagerly when the
6206	Objective-C runtime is loaded. This is required for certain system classes which
6207	have instances allocated in non-standard ways, such as the classes for blocks
6208	and constant strings. Adding this attribute is essentially equivalent to
6209	providing a trivial ``+load`` method but avoids the (fairly small) load-time
6210	overheads associated with defining and calling such a method.)reST";
6211
6212	static const char AttrDoc_ObjCNonRuntimeProtocol[] = R"reST(The ``objc_non_runtime_protocol`` attribute can be used to mark that an
6213	Objective-C protocol is only used during static type-checking and doesn't need
6214	to be represented dynamically. This avoids several small code-size and run-time
6215	overheads associated with handling the protocol's metadata. A non-runtime
6216	protocol cannot be used as the operand of a ``@protocol`` expression, and
6217	dynamic attempts to find it with ``objc_getProtocol`` will fail.
6218
6219	If a non-runtime protocol inherits from any ordinary protocols, classes and
6220	derived protocols that declare conformance to the non-runtime protocol will
6221	dynamically list their conformance to those bare protocols.)reST";
6222
6223	static const char AttrDoc_ObjCOwnership[] = R"reST(No documentation.)reST";
6224
6225	static const char AttrDoc_ObjCPreciseLifetime[] = R"reST(No documentation.)reST";
6226
6227	static const char AttrDoc_ObjCRequiresPropertyDefs[] = R"reST(No documentation.)reST";
6228
6229	static const char AttrDoc_ObjCRequiresSuper[] = R"reST(Some Objective-C classes allow a subclass to override a particular method in a
6230	parent class but expect that the overriding method also calls the overridden
6231	method in the parent class. For these cases, we provide an attribute to
6232	designate that a method requires a "call to ``super``" in the overriding
6233	method in the subclass.
6234
6235	Usage: ``__attribute__((objc_requires_super))``. This attribute can only
6236	be placed at the end of a method declaration:
6237
6238	.. code-block:: objc
6239
6240	- (void)foo __attribute__((objc_requires_super));
6241
6242	This attribute can only be applied the method declarations within a class, and
6243	not a protocol. Currently this attribute does not enforce any placement of
6244	where the call occurs in the overriding method (such as in the case of
6245	``-dealloc`` where the call must appear at the end). It checks only that it
6246	exists.
6247
6248	Note that on both OS X and iOS that the Foundation framework provides a
6249	convenience macro ``NS_REQUIRES_SUPER`` that provides syntactic sugar for this
6250	attribute:
6251
6252	.. code-block:: objc
6253
6254	- (void)foo NS_REQUIRES_SUPER;
6255
6256	This macro is conditionally defined depending on the compiler's support for
6257	this attribute. If the compiler does not support the attribute the macro
6258	expands to nothing.
6259
6260	Operationally, when a method has this annotation the compiler will warn if the
6261	implementation of an override in a subclass does not call super. For example:
6262
6263	.. code-block:: objc
6264
6265	warning: method possibly missing a [super AnnotMeth] call
6266	- (void) AnnotMeth{};
6267	^)reST";
6268
6269	static const char AttrDoc_ObjCReturnsInnerPointer[] = R"reST(No documentation.)reST";
6270
6271	static const char AttrDoc_ObjCRootClass[] = R"reST(No documentation.)reST";
6272
6273	static const char AttrDoc_ObjCRuntimeName[] = R"reST(By default, the Objective-C interface or protocol identifier is used
6274	in the metadata name for that object. The ``objc_runtime_name``
6275	attribute allows annotated interfaces or protocols to use the
6276	specified string argument in the object's metadata name instead of the
6277	default name.
6278
6279	Usage: ``__attribute__((objc_runtime_name("MyLocalName")))``. This attribute
6280	can only be placed before an @protocol or @interface declaration:
6281
6282	.. code-block:: objc
6283
6284	__attribute__((objc_runtime_name("MyLocalName")))
6285	@interface Message
6286	@end)reST";
6287
6288	static const char AttrDoc_ObjCRuntimeVisible[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
6289	visible to the Objective-C runtime but not to the linker. Classes annotated
6290	with this attribute cannot be subclassed and cannot have categories defined for
6291	them.)reST";
6292
6293	static const char AttrDoc_ObjCSubclassingRestricted[] = R"reST(This attribute can be added to an Objective-C ``@interface`` declaration to
6294	ensure that this class cannot be subclassed.)reST";
6295
6296	static const char AttrDoc_OpenACCRoutineAnnot[] = R"reST()reST";
6297
6298	static const char AttrDoc_OpenACCRoutineDecl[] = R"reST()reST";
6299
6300	static const char AttrDoc_OpenCLAccess[] = R"reST(The access qualifiers must be used with image object arguments or pipe arguments
6301	to declare if they are being read or written by a kernel or function.
6302
6303	The read_only/__read_only, write_only/__write_only and read_write/__read_write
6304	names are reserved for use as access qualifiers and shall not be used otherwise.
6305
6306	.. code-block:: c
6307
6308	kernel void
6309	foo (read_only image2d_t imageA,
6310	write_only image2d_t imageB) {
6311	...
6312	}
6313
6314	In the above example imageA is a read-only 2D image object, and imageB is a
6315	write-only 2D image object.
6316
6317	The read_write (or __read_write) qualifier can not be used with pipe.
6318
6319	More details can be found in the OpenCL C language Spec v2.0, Section 6.6.)reST";
6320
6321	static const char AttrDoc_OpenCLConstantAddressSpace[] = R"reST(The constant address space attribute signals that an object is located in
6322	a constant (non-modifiable) memory region. It is available to all work items.
6323	Any type can be annotated with the constant address space attribute. Objects
6324	with the constant address space qualifier can be declared in any scope and must
6325	have an initializer.)reST";
6326
6327	static const char AttrDoc_OpenCLGenericAddressSpace[] = R"reST(The generic address space attribute is only available with OpenCL v2.0 and later.
6328	It can be used with pointer types. Variables in global and local scope and
6329	function parameters in non-kernel functions can have the generic address space
6330	type attribute. It is intended to be a placeholder for any other address space
6331	except for '__constant' in OpenCL code which can be used with multiple address
6332	spaces.)reST";
6333
6334	static const char AttrDoc_OpenCLGlobalAddressSpace[] = R"reST(The global address space attribute specifies that an object is allocated in
6335	global memory, which is accessible by all work items. The content stored in this
6336	memory area persists between kernel executions. Pointer types to the global
6337	address space are allowed as function parameters or local variables. Starting
6338	with OpenCL v2.0, the global address space can be used with global (program
6339	scope) variables and static local variable as well.)reST";
6340
6341	static const char AttrDoc_OpenCLGlobalDeviceAddressSpace[] = R"reST(The ``global_device`` and ``global_host`` address space attributes specify that
6342	an object is allocated in global memory on the device/host. It helps to
6343	distinguish USM (Unified Shared Memory) pointers that access global device
6344	memory from those that access global host memory. These new address spaces are
6345	a subset of the ``__global/opencl_global`` address space, the full address space
6346	set model for OpenCL 2.0 with the extension looks as follows:
6347
6348	\| generic->global->host
6349	\| ->device
6350	\| ->private
6351	\| ->local
6352	\| constant
6353
6354	As ``global_device`` and ``global_host`` are a subset of
6355	``__global/opencl_global`` address spaces it is allowed to convert
6356	``global_device`` and ``global_host`` address spaces to
6357	``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
6358	"Address space nesting and rules for pointers").)reST";
6359
6360	static const char AttrDoc_OpenCLGlobalHostAddressSpace[] = R"reST(The ``global_device`` and ``global_host`` address space attributes specify that
6361	an object is allocated in global memory on the device/host. It helps to
6362	distinguish USM (Unified Shared Memory) pointers that access global device
6363	memory from those that access global host memory. These new address spaces are
6364	a subset of the ``__global/opencl_global`` address space, the full address space
6365	set model for OpenCL 2.0 with the extension looks as follows:
6366
6367	\| generic->global->host
6368	\| ->device
6369	\| ->private
6370	\| ->local
6371	\| constant
6372
6373	As ``global_device`` and ``global_host`` are a subset of
6374	``__global/opencl_global`` address spaces it is allowed to convert
6375	``global_device`` and ``global_host`` address spaces to
6376	``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
6377	"Address space nesting and rules for pointers").)reST";
6378
6379	static const char AttrDoc_OpenCLIntelReqdSubGroupSize[] = R"reST(The optional attribute intel_reqd_sub_group_size can be used to indicate that
6380	the kernel must be compiled and executed with the specified subgroup size. When
6381	this attribute is present, get_max_sub_group_size() is guaranteed to return the
6382	specified integer value. This is important for the correctness of many subgroup
6383	algorithms, and in some cases may be used by the compiler to generate more optimal
6384	code. See `cl_intel_required_subgroup_size
6385	<https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt>`
6386	for details.)reST";
6387
6388	static const char AttrDoc_OpenCLLocalAddressSpace[] = R"reST(The local address space specifies that an object is allocated in the local (work
6389	group) memory area, which is accessible to all work items in the same work
6390	group. The content stored in this memory region is not accessible after
6391	the kernel execution ends. In a kernel function scope, any variable can be in
6392	the local address space. In other scopes, only pointer types to the local address
6393	space are allowed. Local address space variables cannot have an initializer.)reST";
6394
6395	static const char AttrDoc_OpenCLPrivateAddressSpace[] = R"reST(The private address space specifies that an object is allocated in the private
6396	(work item) memory. Other work items cannot access the same memory area and its
6397	content is destroyed after work item execution ends. Local variables can be
6398	declared in the private address space. Function arguments are always in the
6399	private address space. Kernel function arguments of a pointer or an array type
6400	cannot point to the private address space.)reST";
6401
6402	static const char AttrDoc_OpenCLUnrollHint[] = R"reST(The opencl_unroll_hint attribute qualifier can be used to specify that a loop
6403	(for, while and do loops) can be unrolled. This attribute qualifier can be
6404	used to specify full unrolling or partial unrolling by a specified amount.
6405	This is a compiler hint and the compiler may ignore this directive. See
6406	`OpenCL v2.0 <https://www.khronos.org/registry/cl/specs/opencl-2.0.pdf>`_
6407	s6.11.5 for details.)reST";
6408
6409	static const char AttrDoc_OptimizeNone[] = R"reST(The ``optnone`` attribute suppresses essentially all optimizations
6410	on a function or method, regardless of the optimization level applied to
6411	the compilation unit as a whole. This is particularly useful when you
6412	need to debug a particular function, but it is infeasible to build the
6413	entire application without optimization. Avoiding optimization on the
6414	specified function can improve the quality of the debugging information
6415	for that function.
6416
6417	This attribute is incompatible with the ``always_inline`` and ``minsize``
6418	attributes.
6419
6420	Note that this attribute does not apply recursively to nested functions such as
6421	lambdas or blocks when using declaration-specific attribute syntaxes such as double
6422	square brackets (``[[]]``) or ``__attribute__``. The ``#pragma`` syntax can be
6423	used to apply the attribute to all functions, including nested functions, in a
6424	range of source code.)reST";
6425
6426	static const char AttrDoc_OverflowBehavior[] = R"reST(No documentation.)reST";
6427
6428	static const char AttrDoc_Overloadable[] = R"reST(Clang provides support for C++ function overloading in C. Function overloading
6429	in C is introduced using the ``overloadable`` attribute. For example, one
6430	might provide several overloaded versions of a ``tgsin`` function that invokes
6431	the appropriate standard function computing the sine of a value with ``float``,
6432	``double``, or ``long double`` precision:
6433
6434	.. code-block:: c
6435
6436	#include <math.h>
6437	float __attribute__((overloadable)) tgsin(float x) { return sinf(x); }
6438	double __attribute__((overloadable)) tgsin(double x) { return sin(x); }
6439	long double __attribute__((overloadable)) tgsin(long double x) { return sinl(x); }
6440
6441	Given these declarations, one can call ``tgsin`` with a ``float`` value to
6442	receive a ``float`` result, with a ``double`` to receive a ``double`` result,
6443	etc. Function overloading in C follows the rules of C++ function overloading
6444	to pick the best overload given the call arguments, with a few C-specific
6445	semantics:
6446
6447	* Conversion from ``float`` or ``double`` to ``long double`` is ranked as a
6448	floating-point promotion (per C99) rather than as a floating-point conversion
6449	(as in C++).
6450
6451	* A conversion from a pointer of type ``T`` to a pointer of type ``U`` is
6452	considered a pointer conversion (with conversion rank) if ``T`` and ``U`` are
6453	compatible types.
6454
6455	* A conversion from type ``T`` to a value of type ``U`` is permitted if ``T``
6456	and ``U`` are compatible types. This conversion is given "conversion" rank.
6457
6458	* If no viable candidates are otherwise available, we allow a conversion from a
6459	pointer of type ``T`` to a pointer of type ``U``, where ``T`` and ``U`` are
6460	incompatible. This conversion is ranked below all other types of conversions.
6461	Please note: ``U`` lacking qualifiers that are present on ``T`` is sufficient
6462	for ``T`` and ``U`` to be incompatible.
6463
6464	The declaration of ``overloadable`` functions is restricted to function
6465	declarations and definitions. If a function is marked with the ``overloadable``
6466	attribute, then all declarations and definitions of functions with that name,
6467	except for at most one (see the note below about unmarked overloads), must have
6468	the ``overloadable`` attribute. In addition, redeclarations of a function with
6469	the ``overloadable`` attribute must have the ``overloadable`` attribute, and
6470	redeclarations of a function without the ``overloadable`` attribute must not
6471	have the ``overloadable`` attribute. e.g.,
6472
6473	.. code-block:: c
6474
6475	int f(int) __attribute__((overloadable));
6476	float f(float); // error: declaration of "f" must have the "overloadable" attribute
6477	int f(int); // error: redeclaration of "f" must have the "overloadable" attribute
6478
6479	int g(int) __attribute__((overloadable));
6480	int g(int) { } // error: redeclaration of "g" must also have the "overloadable" attribute
6481
6482	int h(int);
6483	int h(int) __attribute__((overloadable)); // error: declaration of "h" must not
6484	// have the "overloadable" attribute
6485
6486	Functions marked ``overloadable`` must have prototypes. Therefore, the
6487	following code is ill-formed:
6488
6489	.. code-block:: c
6490
6491	int h() __attribute__((overloadable)); // error: h does not have a prototype
6492
6493	However, ``overloadable`` functions are allowed to use a ellipsis even if there
6494	are no named parameters (as is permitted in C++). This feature is particularly
6495	useful when combined with the ``unavailable`` attribute:
6496
6497	.. code-block:: c++
6498
6499	void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error
6500
6501	Functions declared with the ``overloadable`` attribute have their names mangled
6502	according to the same rules as C++ function names. For example, the three
6503	``tgsin`` functions in our motivating example get the mangled names
6504	``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two
6505	caveats to this use of name mangling:
6506
6507	* Future versions of Clang may change the name mangling of functions overloaded
6508	in C, so you should not depend on an specific mangling. To be completely
6509	safe, we strongly urge the use of ``static inline`` with ``overloadable``
6510	functions.
6511
6512	* The ``overloadable`` attribute has almost no meaning when used in C++,
6513	because names will already be mangled and functions are already overloadable.
6514	However, when an ``overloadable`` function occurs within an ``extern "C"``
6515	linkage specification, its name will be mangled in the same way as it
6516	would in C.
6517
6518	For the purpose of backwards compatibility, at most one function with the same
6519	name as other ``overloadable`` functions may omit the ``overloadable``
6520	attribute. In this case, the function without the ``overloadable`` attribute
6521	will not have its name mangled.
6522
6523	For example:
6524
6525	.. code-block:: c
6526
6527	// Notes with mangled names assume Itanium mangling.
6528	int f(int);
6529	int f(double) __attribute__((overloadable));
6530	void foo() {
6531	f(5); // Emits a call to f (not _Z1fi, as it would with an overload that
6532	// was marked with overloadable).
6533	f(1.0); // Emits a call to _Z1fd.
6534	}
6535
6536	Support for unmarked overloads is not present in some versions of clang. You may
6537	query for it using ``__has_extension(overloadable_unmarked)``.
6538
6539	Query for this attribute with ``__has_attribute(overloadable)``.)reST";
6540
6541	static const char AttrDoc_Override[] = R"reST()reST";
6542
6543	static const char AttrDoc_Owner[] = R"reST(.. Note:: This attribute is experimental and its effect on analysis is subject to change in
6544	a future version of clang.
6545
6546	The attribute ``[[gsl::Owner(T)]]`` applies to structs and classes that own an
6547	object of type ``T``:
6548
6549	.. code::
6550
6551	class [[gsl::Owner(int)]] IntOwner {
6552	private:
6553	int value;
6554	public:
6555	int *getInt() { return &value; }
6556	};
6557
6558	The argument ``T`` is optional and is ignored.
6559	This attribute may be used by analysis tools and has no effect on code
6560	generation. A ``void`` argument means that the class can own any type.
6561
6562	See Pointer_ for an example.)reST";
6563
6564	static const char AttrDoc_Ownership[] = R"reST(.. note::
6565
6566	In order for the Clang Static Analyzer to acknowledge these attributes, the
6567	``Optimistic`` config needs to be set to true for the checker
6568	``unix.DynamicMemoryModeling``:
6569
6570	``-Xclang -analyzer-config -Xclang unix.DynamicMemoryModeling:Optimistic=true``
6571
6572	These attributes are used by the Clang Static Analyzer's dynamic memory modeling
6573	facilities to mark custom allocating/deallocating functions.
6574
6575	All 3 attributes' first parameter of type string is the type of the allocation:
6576	``malloc``, ``new``, etc. to allow for catching :ref:`mismatched deallocation
6577	<unix-MismatchedDeallocator>` bugs. The allocation type can be any string, e.g.
6578	a function annotated with
6579	returning a piece of memory of type ``lasagna`` but freed with a function
6580	annotated to release ``cheese`` typed memory will result in mismatched
6581	deallocation warning.
6582
6583	The (currently) only allocation type having special meaning is ``malloc`` --
6584	the Clang Static Analyzer makes sure that allocating functions annotated with
6585	``malloc`` are treated like they used the standard ``malloc()``, and can be
6586	safely deallocated with the standard ``free()``.
6587
6588	* Use ``ownership_returns`` to mark a function as an allocating function. Takes
6589	1 parameter to denote the allocation type.
6590	* Use ``ownership_takes`` to mark a function as a deallocating function. Takes 2
6591	parameters: the allocation type, and the index of the parameter that is being
6592	deallocated (counting from 1).
6593	* Use ``ownership_holds`` to mark that a function takes over the ownership of a
6594	piece of memory and will free it at some unspecified point in the future. Like
6595	``ownership_takes``, this takes 2 parameters: the allocation type, and the
6596	index of the parameter whose ownership will be taken over (counting from 1).
6597
6598	The annotations ``ownership_takes`` and ``ownership_holds`` both prevent memory
6599	leak reports (concerning the specified argument); the difference between them
6600	is that using taken memory is a use-after-free error, while using held memory
6601	is assumed to be legitimate.
6602
6603	Example:
6604
6605	.. code-block:: c
6606
6607	// Denotes that my_malloc will return with a dynamically allocated piece of
6608	// memory using malloc().
6609	void __attribute((ownership_returns(malloc))) *my_malloc(size_t);
6610
6611	// Denotes that my_free will deallocate its parameter using free().
6612	void __attribute((ownership_takes(malloc, 1))) my_free(void *);
6613
6614	// Denotes that my_hold will take over the ownership of its parameter that was
6615	// allocated via malloc().
6616	void __attribute((ownership_holds(malloc, 1))) my_hold(void *);
6617
6618	Further reading about dynamic memory modeling in the Clang Static Analyzer is
6619	found in these checker docs:
6620	:ref:`unix.Malloc <unix-Malloc>`, :ref:`unix.MallocSizeof <unix-MallocSizeof>`,
6621	:ref:`unix.MismatchedDeallocator <unix-MismatchedDeallocator>`,
6622	:ref:`cplusplus.NewDelete <cplusplus-NewDelete>`,
6623	:ref:`cplusplus.NewDeleteLeaks <cplusplus-NewDeleteLeaks>`,
6624	:ref:`optin.taint.TaintedAlloc <optin-taint-TaintedAlloc>`.
6625	Mind that many more checkers are affected by dynamic memory modeling changes to
6626	some extent.
6627
6628	Further reading for other annotations:
6629	`Source Annotations in the Clang Static Analyzer <https://clang.llvm.org/docs/analyzer/user-docs/Annotations.html>`_.)reST";
6630
6631	static const char AttrDoc_Packed[] = R"reST(No documentation.)reST";
6632
6633	static const char AttrDoc_ParamTypestate[] = R"reST(This attribute specifies expectations about function parameters. Calls to an
6634	function with annotated parameters will issue a warning if the corresponding
6635	argument isn't in the expected state. The attribute is also used to set the
6636	initial state of the parameter when analyzing the function's body.)reST";
6637
6638	static const char AttrDoc_Pascal[] = R"reST(No documentation.)reST";
6639
6640	static const char AttrDoc_PassObjectSize[] = R"reST(.. Note:: The mangling of functions with parameters that are annotated with
6641	``pass_object_size`` is subject to change. You can get around this by
6642	using ``__asm__("foo")`` to explicitly name your functions, thus preserving
6643	your ABI; also, non-overloadable C functions with ``pass_object_size`` are
6644	not mangled.
6645
6646	The ``pass_object_size(Type)`` attribute can be placed on function parameters to
6647	instruct clang to call ``__builtin_object_size(param, Type)`` at each callsite
6648	of said function, and implicitly pass the result of this call in as an invisible
6649	argument of type ``size_t`` directly after the parameter annotated with
6650	``pass_object_size``. Clang will also replace any calls to
6651	``__builtin_object_size(param, Type)`` in the function by said implicit
6652	parameter.
6653
6654	Example usage:
6655
6656	.. code-block:: c
6657
6658	int bzero1(char *const p __attribute__((pass_object_size(0))))
6659	__attribute__((noinline)) {
6660	int i = 0;
6661	for (/**/; i < (int)__builtin_object_size(p, 0); ++i) {
6662	p[i] = 0;
6663	}
6664	return i;
6665	}
6666
6667	int main() {
6668	char chars[100];
6669	int n = bzero1(&chars[0]);
6670	assert(n == sizeof(chars));
6671	return 0;
6672	}
6673
6674	If successfully evaluating ``__builtin_object_size(param, Type)`` at the
6675	callsite is not possible, then the "failed" value is passed in. So, using the
6676	definition of ``bzero1`` from above, the following code would exit cleanly:
6677
6678	.. code-block:: c
6679
6680	int main2(int argc, char *argv[]) {
6681	int n = bzero1(argv);
6682	assert(n == -1);
6683	return 0;
6684	}
6685
6686	``pass_object_size`` plays a part in overload resolution. If two overload
6687	candidates are otherwise equally good, then the overload with one or more
6688	parameters with ``pass_object_size`` is preferred. This implies that the choice
6689	between two identical overloads both with ``pass_object_size`` on one or more
6690	parameters will always be ambiguous; for this reason, having two such overloads
6691	is illegal. For example:
6692
6693	.. code-block:: c++
6694
6695	#define PS(N) __attribute__((pass_object_size(N)))
6696	// OK
6697	void Foo(char a, char b); // Overload A
6698	// OK -- overload A has no parameters with pass_object_size.
6699	void Foo(char a PS(0), char b PS(0)); // Overload B
6700	// Error -- Same signature (sans pass_object_size) as overload B, and both
6701	// overloads have one or more parameters with the pass_object_size attribute.
6702	void Foo(void a PS(0), void b);
6703
6704	// OK
6705	void Bar(void *a PS(0)); // Overload C
6706	// OK
6707	void Bar(char *c PS(1)); // Overload D
6708
6709	void main() {
6710	char known[10], *unknown;
6711	Foo(unknown, unknown); // Calls overload B
6712	Foo(known, unknown); // Calls overload B
6713	Foo(unknown, known); // Calls overload B
6714	Foo(known, known); // Calls overload B
6715
6716	Bar(known); // Calls overload D
6717	Bar(unknown); // Calls overload D
6718	}
6719
6720	Currently, ``pass_object_size`` is a bit restricted in terms of its usage:
6721
6722	* Only one use of ``pass_object_size`` is allowed per parameter.
6723
6724	* It is an error to take the address of a function with ``pass_object_size`` on
6725	any of its parameters. If you wish to do this, you can create an overload
6726	without ``pass_object_size`` on any parameters.
6727
6728	* It is an error to apply the ``pass_object_size`` attribute to parameters that
6729	are not pointers. Additionally, any parameter that ``pass_object_size`` is
6730	applied to must be marked ``const`` at its function's definition.
6731
6732	Clang also supports the ``pass_dynamic_object_size`` attribute, which behaves
6733	identically to ``pass_object_size``, but evaluates a call to
6734	``__builtin_dynamic_object_size`` at the callee instead of
6735	``__builtin_object_size``. ``__builtin_dynamic_object_size`` provides some extra
6736	runtime checks when the object size can't be determined at compile-time. You can
6737	read more about ``__builtin_dynamic_object_size`` `here
6738	<https://clang.llvm.org/docs/LanguageExtensions.html#evaluating-object-size-dynamically>`_.)reST";
6739
6740	static const char AttrDoc_PatchableFunctionEntry[] = R"reST(``__attribute__((patchable_function_entry(N,M,Section)))`` is used to generate M
6741	NOPs before the function entry and N-M NOPs after the function entry, with a record of
6742	the entry stored in section ``Section``. This attribute takes precedence over the
6743	command line option ``-fpatchable-function-entry=N,M,Section``. ``M`` defaults to 0
6744	if omitted.``Section`` defaults to the ``-fpatchable-function-entry`` section name if
6745	set, or to ``__patchable_function_entries`` otherwise.
6746
6747	This attribute is only supported on
6748	aarch64/aarch64-be/loongarch32/loongarch64/riscv32/riscv64/i386/x86-64/ppc/ppc64/ppc64le/s390x targets.
6749	For ppc/ppc64 targets, AIX is still not supported.)reST";
6750
6751	static const char AttrDoc_Pcs[] = R"reST(On ARM targets, this attribute can be used to select calling conventions
6752	similar to ``stdcall`` on x86. Valid parameter values are "aapcs" and
6753	"aapcs-vfp".)reST";
6754
6755	static const char AttrDoc_Pointer[] = R"reST(.. Note:: This attribute is experimental and its effect on analysis is subject to change in
6756	a future version of clang.
6757
6758	The attribute ``[[gsl::Pointer(T)]]`` applies to structs and classes that behave
6759	like pointers to an object of type ``T``:
6760
6761	.. code::
6762
6763	class [[gsl::Pointer(int)]] IntPointer {
6764	private:
6765	int *valuePointer;
6766	public:
6767	IntPointer(const IntOwner&);
6768	int *getInt() { return valuePointer; }
6769	};
6770
6771	The argument ``T`` is optional and is ignored.
6772	This attribute may be used by analysis tools and has no effect on code
6773	generation. A ``void`` argument means that the pointer can point to any type.
6774
6775	Example:
6776	When constructing an instance of a class annotated like this (a Pointer) from
6777	an instance of a class annotated with ``[[gsl::Owner]]`` (an Owner),
6778	then the analysis will consider the Pointer to point inside the Owner.
6779	When the Owner's lifetime ends, it will consider the Pointer to be dangling.
6780
6781	.. code-block:: c++
6782
6783	int f() {
6784	IntPointer P(IntOwner{}); // P "points into" a temporary IntOwner object
6785	P.getInt(); // P is dangling
6786	}
6787
6788	Transparent Member Functions
6789
6790	The analysis automatically tracks certain member functions of ``[[gsl::Pointer]]`` types
6791	that provide transparent access to the pointed-to object. These include:
6792
6793	* Dereference operators: ``operator*``, ``operator->``
6794	* Data access methods: ``data()``, ``c_str()``, ``get()``
6795	* Iterator methods: ``begin()``, ``end()``, ``rbegin()``, ``rend()``, ``cbegin()``, ``cend()``, ``crbegin()``, ``crend()``
6796
6797	When these methods return pointers, view types, or references, the analysis treats them as
6798	transparently borrowing from the same object that the pointer itself borrows from,
6799	enabling detection of use-after-free through these access patterns:
6800
6801	.. code-block:: c++
6802
6803	// For example, .data() here returns a borrow to 's' instead of 'v'.
6804	const char* f() {
6805	std::string s = "hello";
6806	std::string_view v = s; // warning: address of stack memory returned
6807	return v.data(); // note: returned here
6808	}
6809
6810	const MyObj& g(MyObj obj) {
6811	View v = obj; // warning: address of stack memory returned
6812	return *v; // note: returned here
6813	}
6814
6815	This tracking also applies to range-based for loops, where the ``begin()`` and ``end()``
6816	iterators are used to access elements:
6817
6818	.. code-block:: c++
6819
6820	std::string_view f(std::vector<std::string> vec) {
6821	for (const std::string& s : vec) { // warning: address of stack memory returned
6822	return s; // note: returned here
6823	}
6824	}
6825
6826	Container Template Specialization
6827
6828	If a template class is annotated with ``[[gsl::Owner]]``, and the first
6829	instantiated template argument is a pointer type (raw pointer, or ``[[gsl::Pointer]]``),
6830	the analysis will consider the instantiated class as a container of the pointer.
6831	When constructing such an object from a GSL owner object, the analysis will
6832	assume that the container holds a pointer to the owner object. Consequently,
6833	when the owner object is destroyed, the pointer will be considered dangling.
6834
6835	.. code-block:: c++
6836
6837	int f() {
6838	std::vector<std::string_view> v = {std::string()}; // v holds a dangling pointer.
6839	std::optional<std::string_view> o = std::string(); // o holds a dangling pointer.
6840	})reST";
6841
6842	static const char AttrDoc_PointerAuth[] = R"reST(The ``__ptrauth`` qualifier allows the programmer to directly control
6843	how pointers are signed when they are stored in a particular variable.
6844	This can be used to strengthen the default protections of pointer
6845	authentication and make it more difficult for an attacker to escalate
6846	an ability to alter memory into full control of a process.
6847
6848	.. code-block:: c
6849
6850	#include <ptrauth.h>
6851
6852	typedef void (my_callback)(const void);
6853	my_callback __ptrauth(ptrauth_key_process_dependent_code, 1, 0xe27a) callback;
6854
6855	The first argument to ``__ptrauth`` is the name of the signing key.
6856	Valid key names for the target are defined in ``<ptrauth.h>``.
6857
6858	The second argument to ``__ptrauth`` is a flag (0 or 1) specifying whether
6859	the object should use address discrimination.
6860
6861	The third argument to ``__ptrauth`` is a 16-bit non-negative integer which
6862	allows additional discrimination between objects.)reST";
6863
6864	static const char AttrDoc_PointerFieldProtection[] = R"reST(No documentation.)reST";
6865
6866	static const char AttrDoc_PragmaClangBSSSection[] = R"reST()reST";
6867
6868	static const char AttrDoc_PragmaClangDataSection[] = R"reST()reST";
6869
6870	static const char AttrDoc_PragmaClangRelroSection[] = R"reST()reST";
6871
6872	static const char AttrDoc_PragmaClangRodataSection[] = R"reST()reST";
6873
6874	static const char AttrDoc_PragmaClangTextSection[] = R"reST()reST";
6875
6876	static const char AttrDoc_PreferredName[] = R"reST(The ``preferred_name`` attribute can be applied to a class template, and
6877	specifies a preferred way of naming a specialization of the template. The
6878	preferred name will be used whenever the corresponding template specialization
6879	would otherwise be printed in a diagnostic or similar context.
6880
6881	The preferred name must be a typedef or type alias declaration that refers to a
6882	specialization of the class template (not including any type qualifiers). In
6883	general this requires the template to be declared at least twice. For example:
6884
6885	.. code-block:: c++
6886
6887	template<typename T> struct basic_string;
6888	using string = basic_string<char>;
6889	using wstring = basic_string<wchar_t>;
6890	template<typename T> struct [[clang::preferred_name(string),
6891	clang::preferred_name(wstring)]] basic_string {
6892	// ...
6893	};
6894
6895
6896	Note that the ``preferred_name`` attribute will be ignored when the compiler
6897	writes a C++20 Module interface now. This is due to a compiler issue
6898	(https://github.com/llvm/llvm-project/issues/56490) that blocks users to modularize
6899	declarations with `preferred_name`. This is intended to be fixed in the future.)reST";
6900
6901	static const char AttrDoc_PreferredType[] = R"reST(This attribute allows adjusting the type of a bit-field in debug information.
6902	This can be helpful when a bit-field is intended to store an enumeration value,
6903	but has to be specified as having the enumeration's underlying type in order to
6904	facilitate compiler optimizations or bit-field packing behavior. Normally, the
6905	underlying type is what is emitted in debug information, which can make it hard
6906	for debuggers to know to map a bit-field's value back to a particular enumeration.
6907
6908	.. code-block:: c++
6909
6910	enum Colors { Red, Green, Blue };
6911
6912	struct S {
6913	[[clang::preferred_type(Colors)]] unsigned ColorVal : 2;
6914	[[clang::preferred_type(bool)]] unsigned UseAlternateColorSpace : 1;
6915	} s = { Green, false };
6916
6917	Without the attribute, a debugger is likely to display the value ``1`` for ``ColorVal``
6918	and ``0`` for ``UseAlternateColorSpace``. With the attribute, the debugger may now
6919	display ``Green`` and ``false`` instead.
6920
6921	This can be used to map a bit-field to an arbitrary type that isn't integral
6922	or an enumeration type. For example:
6923
6924	.. code-block:: c++
6925
6926	struct A {
6927	short a1;
6928	short a2;
6929	};
6930
6931	struct B {
6932	[[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
6933	};
6934
6935	will associate the type ``A`` with the ``b1`` bit-field and is intended to display
6936	something like this in the debugger:
6937
6938	.. code-block:: text
6939
6940	Process 2755547 stopped
6941	* thread #1, name = 'test-preferred-', stop reason = step in
6942	frame #0: 0x0000555555555148 test-preferred-type`main at test.cxx:13:14
6943	10 int main()
6944	11 {
6945	12 B b;
6946	-> 13 return b.b1;
6947	14 }
6948	(lldb) v -T
6949	(B) b = {
6950	(A:32) b1 = {
6951	(short) a1 = 12
6952	(short) a2 = 15
6953	}
6954	}
6955
6956	Note that debuggers may not be able to handle more complex mappings, and so
6957	this usage is debugger-dependent.)reST";
6958
6959	static const char AttrDoc_PreserveAll[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
6960	a function. The ``preserve_all`` calling convention attempts to make the code
6961	in the caller even less intrusive than the ``preserve_most`` calling convention.
6962	This calling convention also behaves identical to the ``C`` calling convention
6963	on how arguments and return values are passed, but it uses a different set of
6964	caller/callee-saved registers. This removes the burden of saving and
6965	recovering a large register set before and after the call in the caller. If
6966	the arguments are passed in callee-saved registers, then they will be
6967	preserved by the callee across the call. This doesn't apply for values
6968	returned in callee-saved registers.
6969
6970	- On X86-64 the callee preserves all general purpose registers, except for
6971	R11. R11 can be used as a scratch register. Furthermore it also preserves
6972	all floating-point registers (XMMs/YMMs).
6973
6974	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
6975	X16-X18. Furthermore it also preserves lower 128 bits of V8-V31 SIMD - floating
6976	point registers.
6977
6978	The idea behind this convention is to support calls to runtime functions
6979	that don't need to call out to any other functions.
6980
6981	This calling convention, like the ``preserve_most`` calling convention, will be
6982	used by a future version of the Objective-C runtime and should be considered
6983	experimental at this time.)reST";
6984
6985	static const char AttrDoc_PreserveMost[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
6986	a function. The ``preserve_most`` calling convention attempts to make the code
6987	in the caller as unintrusive as possible. This convention behaves identically
6988	to the ``C`` calling convention on how arguments and return values are passed,
6989	but it uses a different set of caller/callee-saved registers. This alleviates
6990	the burden of saving and recovering a large register set before and after the
6991	call in the caller. If the arguments are passed in callee-saved registers,
6992	then they will be preserved by the callee across the call. This doesn't
6993	apply for values returned in callee-saved registers.
6994
6995	- On X86-64 the callee preserves all general purpose registers, except for
6996	R11. R11 can be used as a scratch register. Floating-point registers
6997	(XMMs/YMMs) are not preserved and need to be saved by the caller.
6998
6999	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
7000	X16-X18.
7001
7002	The idea behind this convention is to support calls to runtime functions
7003	that have a hot path and a cold path. The hot path is usually a small piece
7004	of code that doesn't use many registers. The cold path might need to call out to
7005	another function and therefore only needs to preserve the caller-saved
7006	registers, which haven't already been saved by the caller. The
7007	``preserve_most`` calling convention is very similar to the ``cold`` calling
7008	convention in terms of caller/callee-saved registers, but they are used for
7009	different types of function calls. ``coldcc`` is for function calls that are
7010	rarely executed, whereas ``preserve_most`` function calls are intended to be
7011	on the hot path and definitely executed a lot. Furthermore ``preserve_most``
7012	doesn't prevent the inliner from inlining the function call.
7013
7014	This calling convention will be used by a future version of the Objective-C
7015	runtime and should therefore still be considered experimental at this time.
7016	Although this convention was created to optimize certain runtime calls to
7017	the Objective-C runtime, it is not limited to this runtime and might be used
7018	by other runtimes in the future too. The current implementation only
7019	supports X86-64 and AArch64, but the intention is to support more architectures
7020	in the future.)reST";
7021
7022	static const char AttrDoc_PreserveNone[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of a function.
7023	The ``preserve_none`` calling convention tries to preserve as few general
7024	registers as possible. So all general registers are caller saved registers. It
7025	also uses more general registers to pass arguments. This attribute doesn't
7026	impact floating-point registers. ``preserve_none``'s ABI is still unstable, and
7027	may be changed in the future.
7028
7029	- On X86-64, only RSP and RBP are preserved by the callee.
7030	Registers R12, R13, R14, R15, RDI, RSI, RDX, RCX, R8, R9, R11, and RAX now can
7031	be used to pass function arguments. Floating-point registers (XMMs/YMMs) still
7032	follow the C calling convention.
7033	- On AArch64, only LR and FP are preserved by the callee.
7034	Registers X20-X28, X0-X7, and X9-X14 are used to pass function arguments.
7035	X8, X16-X19, SIMD and floating-point registers follow the AAPCS calling
7036	convention. X15 is not available for argument passing on Windows, but is
7037	used to pass arguments on other platforms.)reST";
7038
7039	static const char AttrDoc_PtGuardedBy[] = R"reST(No documentation.)reST";
7040
7041	static const char AttrDoc_PtGuardedVar[] = R"reST(No documentation.)reST";
7042
7043	static const char AttrDoc_Ptr32[] = R"reST(The ``__ptr32`` qualifier represents a native pointer on a 32-bit system. On a
7044	64-bit system, a pointer with ``__ptr32`` is extended to a 64-bit pointer. The
7045	``__sptr`` and ``__uptr`` qualifiers can be used to specify whether the pointer
7046	is sign extended or zero extended. This qualifier is enabled under
7047	``-fms-extensions``.)reST";
7048
7049	static const char AttrDoc_Ptr64[] = R"reST(The ``__ptr64`` qualifier represents a native pointer on a 64-bit system. On a
7050	32-bit system, a ``__ptr64`` pointer is truncated to a 32-bit pointer. This
7051	qualifier is enabled under ``-fms-extensions``.)reST";
7052
7053	static const char AttrDoc_Pure[] = R"reST(No documentation.)reST";
7054
7055	static const char AttrDoc_RISCVInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV
7056	targets. This attribute may be attached to a function definition and instructs
7057	the backend to generate appropriate function entry/exit code so that it can be
7058	used directly as an interrupt service routine.
7059
7060	Permissible values for this parameter are ``machine``, ``supervisor``,
7061	``rnmi``, ``qci-nest``, ``qci-nonest``, ``SiFive-CLIC-preemptible``, and
7062	``SiFive-CLIC-stack-swap``. If there is no parameter, then it defaults to
7063	``machine``.
7064
7065	The ``rnmi`` value is used for resumable non-maskable interrupts. It requires the
7066	standard Smrnmi extension.
7067
7068	The ``qci-nest`` and ``qci-nonest`` values require Qualcomm's Xqciint extension
7069	and are used for Machine-mode Interrupts and Machine-mode Non-maskable
7070	interrupts. These use the following instructions from Xqciint to save and
7071	restore interrupt state to the stack -- the ``qci-nest`` value will use
7072	``qc.c.mienter.nest`` and the ``qci-nonest`` value will use ``qc.c.mienter`` to
7073	begin the interrupt handler. Both of these will use ``qc.c.mileaveret`` to
7074	restore the state and return to the previous context.
7075
7076	The ``SiFive-CLIC-preemptible`` and ``SiFive-CLIC-stack-swap`` values are used
7077	for machine-mode interrupts. For ``SiFive-CLIC-preemptible`` interrupts, the
7078	values of ``mcause`` and ``mepc`` are saved onto the stack, and interrupts are
7079	re-enabled. For ``SiFive-CLIC-stack-swap`` interrupts, the stack pointer is
7080	swapped with ``mscratch`` before its first use and after its last use.
7081
7082	The SiFive CLIC values may be combined with each other and with the ``machine``
7083	attribute value. Any other combination of different values is not allowed.
7084
7085	Repeated interrupt attribute on the same declaration will cause a warning
7086	to be emitted. In case of repeated declarations, the last one prevails.
7087
7088	Refer to:
7089	https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html
7090	https://riscv.org/specifications/privileged-isa/
7091	The RISC-V Instruction Set Manual Volume II: Privileged Architecture
7092	Version 1.10.
7093	https://github.com/quic/riscv-unified-db/releases/tag/Xqci-0.13.0
7094	https://sifive.cdn.prismic.io/sifive/d1984d2b-c9b9-4c91-8de0-d68a5e64fa0f_sifive-interrupt-cookbook-v1p2.pdf)reST";
7095
7096	static const char AttrDoc_RISCVVLSCC[] = R"reST(The ``riscv_vls_cc`` attribute can be applied to a function. Functions
7097	declared with this attribute will utilize the standard fixed-length vector
7098	calling convention variant instead of the default calling convention defined by
7099	the ABI. This variant aims to pass fixed-length vectors via vector registers,
7100	if possible, rather than through general-purpose registers.)reST";
7101
7102	static const char AttrDoc_RISCVVectorCC[] = R"reST(The ``riscv_vector_cc`` attribute can be applied to a function. It preserves 15
7103	registers namely, v1-v7 and v24-v31 as callee-saved. Callers thus don't need
7104	to save these registers before function calls, and callees only need to save
7105	them if they use them.)reST";
7106
7107	static const char AttrDoc_RandomizeLayout[] = R"reST(The attribute ``randomize_layout``, when attached to a C structure, selects it
7108	for structure layout field randomization; a compile-time hardening technique. A
7109	"seed" value, is specified via the ``-frandomize-layout-seed=`` command line flag.
7110	For example:
7111
7112	.. code-block:: bash
7113
7114	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
7115	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
7116
7117	You can also supply the seed in a file with ``-frandomize-layout-seed-file=``.
7118	For example:
7119
7120	.. code-block:: bash
7121
7122	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
7123	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
7124
7125	The randomization is deterministic based for a given seed, so the entire
7126	program should be compiled with the same seed, but keep the seed safe
7127	otherwise.
7128
7129	The attribute ``no_randomize_layout``, when attached to a C structure,
7130	instructs the compiler that this structure should not have its field layout
7131	randomized.)reST";
7132
7133	static const char AttrDoc_ReadOnlyPlacement[] = R"reST(This attribute is attached to a structure, class or union declaration.
7134	When attached to a record declaration/definition, it checks if all instances
7135	of this type can be placed in the read-only data segment of the program. If it
7136	finds an instance that can not be placed in a read-only segment, the compiler
7137	emits a warning at the source location where the type was used.
7138
7139	Examples:
7140	* ``struct __attribute__((enforce_read_only_placement)) Foo;``
7141	* ``struct __attribute__((enforce_read_only_placement)) Bar { ... };``
7142
7143	Both ``Foo`` and ``Bar`` types have the ``enforce_read_only_placement`` attribute.
7144
7145	The goal of introducing this attribute is to assist developers with writing secure
7146	code. A ``const``-qualified global is generally placed in the read-only section
7147	of the memory that has additional run time protection from malicious writes. By
7148	attaching this attribute to a declaration, the developer can express the intent
7149	to place all instances of the annotated type in the read-only program memory.
7150
7151	Note 1: The attribute doesn't guarantee that the object will be placed in the
7152	read-only data segment as it does not instruct the compiler to ensure such
7153	a placement. It emits a warning if something in the code can be proven to prevent
7154	an instance from being placed in the read-only data segment.
7155
7156	Note 2: Currently, clang only checks if all global declarations of a given type 'T'
7157	are ``const``-qualified. The following conditions would also prevent the data to be
7158	put into read only segment, but the corresponding warnings are not yet implemented.
7159
7160	1. An instance of type ``T`` is allocated on the heap/stack.
7161	2. Type ``T`` defines/inherits a mutable field.
7162	3. Type ``T`` defines/inherits non-constexpr constructor(s) for initialization.
7163	4. A field of type ``T`` is defined by type ``Q``, which does not bear the
7164	``enforce_read_only_placement`` attribute.
7165	5. A type ``Q`` inherits from type ``T`` and it does not have the
7166	``enforce_read_only_placement`` attribute.)reST";
7167
7168	static const char AttrDoc_ReentrantCapability[] = R"reST(No documentation.)reST";
7169
7170	static const char AttrDoc_RegCall[] = R"reST(On x86 targets, this attribute changes the calling convention to
7171	`__regcall`_ convention. This convention aims to pass as many arguments
7172	as possible in registers. It also tries to utilize registers for the
7173	return value whenever it is possible.
7174
7175	.. _`__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";
7176
7177	static const char AttrDoc_Reinitializes[] = R"reST(The ``reinitializes`` attribute can be applied to a non-static, non-const C++
7178	member function to indicate that this member function reinitializes the entire
7179	object to a known state, independent of the previous state of the object.
7180
7181	This attribute can be interpreted by static analyzers that warn about uses of an
7182	object that has been left in an indeterminate state by a move operation. If a
7183	member function marked with the ``reinitializes`` attribute is called on a
7184	moved-from object, the analyzer can conclude that the object is no longer in an
7185	indeterminate state.
7186
7187	A typical example where this attribute would be used is on functions that clear
7188	a container class:
7189
7190	.. code-block:: c++
7191
7192	template <class T>
7193	class Container {
7194	public:
7195	...
7196	[[clang::reinitializes]] void Clear();
7197	...
7198	};)reST";
7199
7200	static const char AttrDoc_ReleaseCapability[] = R"reST(Marks a function as releasing a capability.)reST";
7201
7202	static const char AttrDoc_ReleaseHandle[] = R"reST(If a function parameter is annotated with ``release_handle(tag)`` it is assumed to
7203	close the handle. It is also assumed to require an open handle to work with. The
7204	attribute requires a string literal argument to identify the handle being released.
7205
7206	.. code-block:: c++
7207
7208	zx_status_t zx_handle_close(zx_handle_t handle [[clang::release_handle("tag")]]);)reST";
7209
7210	static const char AttrDoc_ReqdWorkGroupSize[] = R"reST(No documentation.)reST";
7211
7212	static const char AttrDoc_RequiresCapability[] = R"reST(No documentation.)reST";
7213
7214	static const char AttrDoc_Restrict[] = R"reST(The ``malloc`` attribute has two forms with different functionality. The first
7215	is when it is used without arguments, where it marks that a function acts like
7216	a system memory allocation function, returning a pointer to allocated storage
7217	that does not alias storage from any other object accessible to the caller.
7218
7219	The second form is when ``malloc`` takes one or two arguments. The first
7220	argument names a function that should be associated with this function as its
7221	deallocation function. When this form is used, it enables the compiler to
7222	diagnose when the incorrect deallocation function is used with this variable.
7223	However the associated warning, spelled `-Wmismatched-dealloc` in GCC, is not
7224	yet implemented in clang.)reST";
7225
7226	static const char AttrDoc_Retain[] = R"reST(This attribute, when attached to a function or variable definition, prevents
7227	section garbage collection in the linker. It does not prevent other discard
7228	mechanisms, such as archive member selection, and COMDAT group resolution.
7229
7230	If the compiler does not emit the definition, e.g. because it was not used in
7231	the translation unit or the compiler was able to eliminate all of the uses,
7232	this attribute has no effect. This attribute is typically combined with the
7233	``used`` attribute to force the definition to be emitted and preserved into the
7234	final linked image.
7235
7236	This attribute is only necessary on ELF targets; other targets prevent section
7237	garbage collection by the linker when using the ``used`` attribute alone.
7238	Using the attributes together should result in consistent behavior across
7239	targets.
7240
7241	This attribute requires the linker to support the ``SHF_GNU_RETAIN`` extension.
7242	This support is available in GNU ``ld`` and ``gold`` as of binutils 2.36, as
7243	well as in ``ld.lld`` 13.)reST";
7244
7245	static const char AttrDoc_ReturnTypestate[] = R"reST(The ``return_typestate`` attribute can be applied to functions or parameters.
7246	When applied to a function the attribute specifies the state of the returned
7247	value. The function's body is checked to ensure that it always returns a value
7248	in the specified state. On the caller side, values returned by the annotated
7249	function are initialized to the given state.
7250
7251	When applied to a function parameter it modifies the state of an argument after
7252	a call to the function returns. The function's body is checked to ensure that
7253	the parameter is in the expected state before returning.)reST";
7254
7255	static const char AttrDoc_ReturnsNonNull[] = R"reST(The ``returns_nonnull`` attribute indicates that a particular function (or
7256	Objective-C method) always returns a non-null pointer. For example, a
7257	particular system ``malloc`` might be defined to terminate a process when
7258	memory is not available rather than returning a null pointer:
7259
7260	.. code-block:: c
7261
7262	extern void * malloc (size_t size) __attribute__((returns_nonnull));
7263
7264	The ``returns_nonnull`` attribute implies that returning a null pointer is
7265	undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
7266	type qualifier indicates that a pointer cannot be null in a more general manner
7267	(because it is part of the type system) and does not imply undefined behavior,
7268	making it more widely applicable)reST";
7269
7270	static const char AttrDoc_ReturnsTwice[] = R"reST(No documentation.)reST";
7271
7272	static const char AttrDoc_RootSignature[] = R"reST(The ``RootSignature`` attribute applies to HLSL entry functions to define what
7273	types of resources are bound to the graphics pipeline.
7274
7275	For details about the use and specification of Root Signatures please see here:
7276	https://learn.microsoft.com/en-us/windows/win32/direct3d12/root-signatures)reST";
7277
7278	static const char AttrDoc_SPtr[] = R"reST(The ``__sptr`` qualifier specifies that a 32-bit pointer should be sign
7279	extended when converted to a 64-bit pointer.)reST";
7280
7281	static const char AttrDoc_SYCLExternal[] = R"reST(The ``sycl_external`` attribute indicates that a function defined in another
7282	translation unit may be called by a device function defined in the current
7283	translation unit or, if defined in the current translation unit, the function
7284	may be called by device functions defined in other translation units.
7285	The attribute is intended for use in the implementation of the ``SYCL_EXTERNAL``
7286	macro as specified in section 5.10.1, "SYCL functions and member functions
7287	linkage", of the SYCL 2020 specification.
7288
7289	The attribute only appertains to functions and only those that meet the
7290	following requirements:
7291
7292	* Has external linkage
7293	* Is not explicitly defined as deleted (the function may be an explicitly
7294	defaulted function that is defined as deleted)
7295
7296	The attribute shall be present on the first declaration of a function and
7297	may optionally be present on subsequent declarations.
7298
7299	When compiling for a SYCL device target that does not support the generic
7300	address space, the function shall not specify a raw pointer or reference type
7301	as the return type or as a parameter type.
7302	See section 5.10, "SYCL offline linking", of the SYCL 2020 specification.
7303	The following examples demonstrate the use of this attribute:
7304
7305	.. code-block:: c++
7306
7307	[[clang::sycl_external]] void Foo(); // Ok.
7308
7309	[[clang::sycl_external]] void Bar() { /* ... */ } // Ok.
7310
7311	[[clang::sycl_external]] extern void Baz(); // Ok.
7312
7313	[[clang::sycl_external]] static void Quux() { /* ... */ } // error: Quux() has internal linkage.)reST";
7314
7315	static const char AttrDoc_SYCLKernel[] = R"reST(The ``sycl_kernel`` attribute specifies that a function template will be used
7316	to outline device code and to generate an OpenCL kernel.
7317	Here is a code example of the SYCL program, which demonstrates the compiler's
7318	outlining job:
7319
7320	.. code-block:: c++
7321
7322	int foo(int x) { return ++x; }
7323
7324	using namespace cl::sycl;
7325	queue Q;
7326	buffer<int, 1> a(range<1>{1024});
7327	Q.submit([&](handler& cgh) {
7328	auto A = a.get_access<access::mode::write>(cgh);
7329	cgh.parallel_for<init_a>(range<1>{1024}, [=](id<1> index) {
7330	A[index] = index[0] + foo(42);
7331	});
7332	}
7333
7334	A C++ function object passed to the ``parallel_for`` is called a "SYCL kernel".
7335	A SYCL kernel defines the entry point to the "device part" of the code. The
7336	compiler will emit all symbols accessible from a "kernel". In this code
7337	example, the compiler will emit "foo" function. More details about the
7338	compilation of functions for the device part can be found in the SYCL 1.2.1
7339	specification Section 6.4.
7340	To show to the compiler entry point to the "device part" of the code, the SYCL
7341	runtime can use the ``sycl_kernel`` attribute in the following way:
7342
7343	.. code-block:: c++
7344
7345	namespace cl {
7346	namespace sycl {
7347	class handler {
7348	template <typename KernelName, typename KernelType/, .../>
7349	__attribute__((sycl_kernel)) void sycl_kernel_function(KernelType KernelFuncObj) {
7350	// ...
7351	KernelFuncObj();
7352	}
7353
7354	template <typename KernelName, typename KernelType, int Dims>
7355	void parallel_for(range<Dims> NumWorkItems, KernelType KernelFunc) {
7356	#ifdef __SYCL_DEVICE_ONLY__
7357	sycl_kernel_function<KernelName, KernelType, Dims>(KernelFunc);
7358	#else
7359	// Host implementation
7360	#endif
7361	}
7362	};
7363	} // namespace sycl
7364	} // namespace cl
7365
7366	The compiler will also generate an OpenCL kernel using the function marked with
7367	the ``sycl_kernel`` attribute.
7368	Here is the list of SYCL device compiler expectations with regard to the
7369	function marked with the ``sycl_kernel`` attribute:
7370
7371	- The function must be a template with at least two type template parameters.
7372	The compiler generates an OpenCL kernel and uses the first template parameter
7373	as a unique name for the generated OpenCL kernel. The host application uses
7374	this unique name to invoke the OpenCL kernel generated for the SYCL kernel
7375	specialized by this name and second template parameter ``KernelType`` (which
7376	might be an unnamed function object type).
7377	- The function must have at least one parameter. The first parameter is
7378	required to be a function object type (named or unnamed i.e. lambda). The
7379	compiler uses function object type fields to generate OpenCL kernel
7380	parameters.
7381	- The function must return void. The compiler reuses the body of marked functions to
7382	generate the OpenCL kernel body, and the OpenCL kernel must return ``void``.
7383
7384	The SYCL kernel in the previous code sample meets these expectations.)reST";
7385
7386	static const char AttrDoc_SYCLKernelEntryPoint[] = R"reST(The ``sycl_kernel_entry_point`` attribute facilitates the generation of an
7387	offload kernel entry point, sometimes called a SYCL kernel caller function,
7388	suitable for invoking a SYCL kernel on an offload device. The attribute is
7389	intended for use in the implementation of SYCL kernel invocation functions
7390	like the ``single_task`` and ``parallel_for`` member functions of the
7391	``sycl::handler`` class specified in section 4.9.4, "Command group ``handler``
7392	class", of the SYCL 2020 specification.
7393
7394	The attribute requires a single type argument that specifies a class type that
7395	meets the requirements for a SYCL kernel name as described in section 5.2,
7396	"Naming of kernels", of the SYCL 2020 specification. A unique kernel name type
7397	is required for each function declared with the attribute. The attribute may
7398	not first appear on a declaration that follows a definition of the function.
7399
7400	The attribute only appertains to functions and only those that meet the
7401	following requirements.
7402
7403	* Has a non-deduced ``void`` return type.
7404	* Is not a non-static member function, constructor, or destructor.
7405	* Is not a C variadic function.
7406	* Is not a coroutine.
7407	* Is not defined as deleted or as defaulted.
7408	* Is not defined with a function try block.
7409	* Is not declared with the ``constexpr`` or ``consteval`` specifiers.
7410	* Is not declared with the ``[[noreturn]]`` attribute.
7411
7412	Use in the implementation of a SYCL kernel invocation function might look as
7413	follows.
7414
7415	.. code-block:: c++
7416
7417	namespace sycl {
7418	class handler {
7419	template<typename KernelNameType, typename KernelType>
7420	[[ clang::sycl_kernel_entry_point(KernelNameType) ]]
7421	static void kernel_entry_point(KernelType kernel) {
7422	kernel();
7423	}
7424
7425	public:
7426	template<typename KernelNameType, typename KernelType>
7427	void single_task(KernelType kernel) {
7428	// Call kernel_entry_point() to trigger generation of an offload
7429	// kernel entry point.
7430	kernel_entry_point<KernelNameType>(kernel);
7431	// Call functions appropriate for the desired offload backend
7432	// (OpenCL, CUDA, HIP, Level Zero, etc...).
7433	}
7434	};
7435	} // namespace sycl
7436
7437	A SYCL kernel is a callable object of class type that is constructed on a host,
7438	often via a lambda expression, and then passed to a SYCL kernel invocation
7439	function to be executed on an offload device. A SYCL kernel invocation function
7440	is responsible for copying the provided SYCL kernel object to an offload
7441	device and initiating a call to it. The SYCL kernel object and its data members
7442	constitute the parameters of an offload kernel.
7443
7444	A SYCL kernel type is required to satisfy the device copyability requirements
7445	specified in section 3.13.1, "Device copyable", of the SYCL 2020 specification.
7446	Additionally, any data members of the kernel object type are required to satisfy
7447	section 4.12.4, "Rules for parameter passing to kernels". For most types, these
7448	rules require that the type is trivially copyable. However, the SYCL
7449	specification mandates that certain special SYCL types, such as
7450	``sycl::accessor`` and ``sycl::stream`` be device copyable even if they are not
7451	trivially copyable. These types require special handling because they cannot
7452	be copied to device memory as if by ``memcpy()``. Additionally, some offload
7453	backends, OpenCL for example, require objects of some of these types to be
7454	passed as individual arguments to the offload kernel.
7455
7456	An offload kernel consists of an entry point function that declares the
7457	parameters of the offload kernel and the set of all functions and variables that
7458	are directly or indirectly used by the entry point function.
7459
7460	A SYCL kernel invocation function invokes a SYCL kernel on a device by
7461	performing the following tasks (likely with the help of an offload backend
7462	like OpenCL):
7463
7464	#. Identifying the offload kernel entry point to be used for the SYCL kernel.
7465
7466	#. Deconstructing the SYCL kernel object, if necessary, to produce the set of
7467	offload kernel arguments required by the offload kernel entry point.
7468
7469	#. Copying the offload kernel arguments to device memory.
7470
7471	#. Initiating execution of the offload kernel entry point.
7472
7473	The offload kernel entry point for a SYCL kernel performs the following tasks:
7474
7475	#. Reconstituting the SYCL kernel object, if necessary, using the offload
7476	kernel parameters.
7477
7478	#. Calling the ``operator()`` member function of the (reconstituted) SYCL kernel
7479	object.
7480
7481	The ``sycl_kernel_entry_point`` attribute automates generation of an offload
7482	kernel entry point that performs those latter tasks. The parameters and body of
7483	a function declared with the ``sycl_kernel_entry_point`` attribute specify a
7484	pattern from which the parameters and body of the entry point function are
7485	derived. Consider the following call to a SYCL kernel invocation function.
7486
7487	.. code-block:: c++
7488
7489	struct S { int i; };
7490	void f(sycl::handler &handler, sycl::stream &sout, S s) {
7491	handler.single_task<struct KN>([=] {
7492	sout << "The value of s.i is " << s.i << "\n";
7493	});
7494	}
7495
7496	The SYCL kernel object is the result of the lambda expression. It has two
7497	data members corresponding to the captures of ``sout`` and ``s``. Since one
7498	of these data members corresponds to a special SYCL type that must be passed
7499	individually as an offload kernel parameter, it is necessary to decompose the
7500	SYCL kernel object into its constituent parts; the offload kernel will have
7501	two kernel parameters. Given a SYCL implementation that uses a
7502	``sycl_kernel_entry_point`` attributed function like the one shown above, an
7503	offload kernel entry point function will be generated that looks approximately
7504	as follows.
7505
7506	.. code-block:: c++
7507
7508	void sycl-kernel-caller-for-KN(sycl::stream sout, S s) {
7509	kernel-type kernel = { sout, s );
7510	kernel();
7511	}
7512
7513	There are a few items worthy of note:
7514
7515	#. The name of the generated function incorporates the SYCL kernel name,
7516	``KN``, that was passed as the ``KernelNameType`` template parameter to
7517	``kernel_entry_point()`` and provided as the argument to the
7518	``sycl_kernel_entry_point`` attribute. There is a one-to-one correspondence
7519	between SYCL kernel names and offload kernel entry points.
7520
7521	#. The SYCL kernel is a lambda closure type and therefore has no name;
7522	``kernel-type`` is substituted above and corresponds to the ``KernelType``
7523	template parameter deduced in the call to ``kernel_entry_point()``.
7524	Lambda types cannot be declared and initialized using the aggregate
7525	initialization syntax used above, but the intended behavior should be clear.
7526
7527	#. ``S`` is a device copyable type that does not directly or indirectly contain
7528	a data member of a SYCL special type. It therefore does not need to be
7529	decomposed into its constituent members to be passed as a kernel argument.
7530
7531	#. The depiction of the ``sycl::stream`` parameter as a single self contained
7532	kernel parameter is an oversimplification. SYCL special types may require
7533	additional decomposition such that the generated function might have three
7534	or more parameters depending on how the SYCL library implementation defines
7535	these types.
7536
7537	#. The call to ``kernel_entry_point()`` has no effect other than to trigger
7538	emission of the entry point function. The statments that make up the body
7539	of the function are not executed when the function is called; they are
7540	only used in the generation of the entry point function.
7541
7542	It is not necessary for a function declared with the ``sycl_kernel_entry_point``
7543	attribute to be called for the offload kernel entry point to be emitted. For
7544	inline functions and function templates, any ODR-use will suffice. For other
7545	functions, an ODR-use is not required; the offload kernel entry point will be
7546	emitted if the function is defined.
7547
7548	Functions declared with the ``sycl_kernel_entry_point`` attribute are not
7549	limited to the simple example shown above. They may have additional template
7550	parameters, declare additional function parameters, and have complex control
7551	flow in the function body. Function parameter decomposition and reconstitution
7552	is performed for all function parameters. The function must abide by the
7553	language feature restrictions described in section 5.4, "Language restrictions
7554	for device functions" in the SYCL 2020 specification.)reST";
7555
7556	static const char AttrDoc_SYCLSpecialClass[] = R"reST(SYCL defines some special classes (accessor, sampler, and stream) which require
7557	specific handling during the generation of the SPIR entry point.
7558	The ``__attribute__((sycl_special_class))`` attribute is used in SYCL
7559	headers to indicate that a class or a struct needs a specific handling when
7560	it is passed from host to device.
7561	Special classes will have a mandatory ``__init`` method and an optional
7562	``__finalize`` method (the ``__finalize`` method is used only with the
7563	``stream`` type). Kernel parameters types are extract from the ``__init`` method
7564	parameters. The kernel function arguments list is derived from the
7565	arguments of the ``__init`` method. The arguments of the ``__init`` method are
7566	copied into the kernel function argument list and the ``__init`` and
7567	``__finalize`` methods are called at the beginning and the end of the kernel,
7568	respectively.
7569	The ``__init`` and ``__finalize`` methods must be defined inside the
7570	special class.
7571	Please note that this is an attribute that is used as an internal
7572	implementation detail and not intended to be used by external users.
7573
7574	The syntax of the attribute is as follows:
7575
7576	.. code-block:: text
7577
7578	class __attribute__((sycl_special_class)) accessor {};
7579	class [[clang::sycl_special_class]] accessor {};
7580
7581	This is a code example that illustrates the use of the attribute:
7582
7583	.. code-block:: c++
7584
7585	class __attribute__((sycl_special_class)) SpecialType {
7586	int F1;
7587	int F2;
7588	void __init(int f1) {
7589	F1 = f1;
7590	F2 = f1;
7591	}
7592	void __finalize() {}
7593	public:
7594	SpecialType() = default;
7595	int getF2() const { return F2; }
7596	};
7597
7598	int main () {
7599	SpecialType T;
7600	cgh.single_task([=] {
7601	T.getF2();
7602	});
7603	}
7604
7605	This would trigger the following kernel entry point in the AST:
7606
7607	.. code-block:: c++
7608
7609	void __sycl_kernel(int f1) {
7610	SpecialType T;
7611	T.__init(f1);
7612	...
7613	T.__finalize()
7614	})reST";
7615
7616	static const char AttrDoc_ScopedLockable[] = R"reST(No documentation.)reST";
7617
7618	static const char AttrDoc_Section[] = R"reST(The ``section`` attribute allows you to specify a specific section a
7619	global variable or function should be in after translation.)reST";
7620
7621	static const char AttrDoc_SelectAny[] = R"reST(This attribute appertains to a global symbol, causing it to have a weak
7622	definition (
7623	`linkonce <https://llvm.org/docs/LangRef.html#linkage-types>`_
7624	), allowing the linker to select any definition.
7625
7626	For more information see
7627	`gcc documentation <https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html>`_
7628	or `msvc documentation <https://docs.microsoft.com/pl-pl/cpp/cpp/selectany>`_.)reST";
7629
7630	static const char AttrDoc_Sentinel[] = R"reST(No documentation.)reST";
7631
7632	static const char AttrDoc_SetTypestate[] = R"reST(Annotate methods that transition an object into a new state with
7633	``__attribute__((set_typestate(new_state)))``. The new state must be
7634	unconsumed, consumed, or unknown.)reST";
7635
7636	static const char AttrDoc_SizedBy[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
7637	structure in C. The argument for the attribute is the name of a field member
7638	holding the count of elements in the flexible array. This information can be
7639	used to improve the results of the array bound sanitizer and the
7640	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
7641	within the same non-anonymous, enclosing struct as the flexible array member.
7642
7643	This example specifies that the flexible array member ``array`` has the number
7644	of elements allocated for it in ``count``:
7645
7646	.. code-block:: c
7647
7648	struct bar;
7649
7650	struct foo {
7651	size_t count;
7652	char other;
7653	struct bar *array[] __attribute__((counted_by(count)));
7654	};
7655
7656	This establishes a relationship between ``array`` and ``count``. Specifically,
7657	``array`` must have at least ``count`` number of elements available. It's the
7658	user's responsibility to ensure that this relationship is maintained through
7659	changes to the structure.
7660
7661	In the following example, the allocated array erroneously has fewer elements
7662	than what's specified by ``p->count``. This would result in an out-of-bounds
7663	access not being detected.
7664
7665	.. code-block:: c
7666
7667	#define SIZE_INCR 42
7668
7669	struct foo *p;
7670
7671	void foo_alloc(size_t count) {
7672	p = malloc(MAX(sizeof(struct foo),
7673	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
7674	p->count = count + SIZE_INCR;
7675	}
7676
7677	The next example updates ``p->count``, but breaks the relationship requirement
7678	that ``p->array`` must have at least ``p->count`` number of elements available:
7679
7680	.. code-block:: c
7681
7682	#define SIZE_INCR 42
7683
7684	struct foo *p;
7685
7686	void foo_alloc(size_t count) {
7687	p = malloc(MAX(sizeof(struct foo),
7688	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
7689	p->count = count;
7690	}
7691
7692	void use_foo(int index, int val) {
7693	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
7694	p->array[index] = val; /* The sanitizer can't properly check this access. */
7695	}
7696
7697	In this example, an update to ``p->count`` maintains the relationship
7698	requirement:
7699
7700	.. code-block:: c
7701
7702	void use_foo(int index, int val) {
7703	if (p->count == 0)
7704	return;
7705	--p->count;
7706	p->array[index] = val;
7707	})reST";
7708
7709	static const char AttrDoc_SizedByOrNull[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
7710	structure in C. The argument for the attribute is the name of a field member
7711	holding the count of elements in the flexible array. This information can be
7712	used to improve the results of the array bound sanitizer and the
7713	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
7714	within the same non-anonymous, enclosing struct as the flexible array member.
7715
7716	This example specifies that the flexible array member ``array`` has the number
7717	of elements allocated for it in ``count``:
7718
7719	.. code-block:: c
7720
7721	struct bar;
7722
7723	struct foo {
7724	size_t count;
7725	char other;
7726	struct bar *array[] __attribute__((counted_by(count)));
7727	};
7728
7729	This establishes a relationship between ``array`` and ``count``. Specifically,
7730	``array`` must have at least ``count`` number of elements available. It's the
7731	user's responsibility to ensure that this relationship is maintained through
7732	changes to the structure.
7733
7734	In the following example, the allocated array erroneously has fewer elements
7735	than what's specified by ``p->count``. This would result in an out-of-bounds
7736	access not being detected.
7737
7738	.. code-block:: c
7739
7740	#define SIZE_INCR 42
7741
7742	struct foo *p;
7743
7744	void foo_alloc(size_t count) {
7745	p = malloc(MAX(sizeof(struct foo),
7746	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
7747	p->count = count + SIZE_INCR;
7748	}
7749
7750	The next example updates ``p->count``, but breaks the relationship requirement
7751	that ``p->array`` must have at least ``p->count`` number of elements available:
7752
7753	.. code-block:: c
7754
7755	#define SIZE_INCR 42
7756
7757	struct foo *p;
7758
7759	void foo_alloc(size_t count) {
7760	p = malloc(MAX(sizeof(struct foo),
7761	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
7762	p->count = count;
7763	}
7764
7765	void use_foo(int index, int val) {
7766	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
7767	p->array[index] = val; /* The sanitizer can't properly check this access. */
7768	}
7769
7770	In this example, an update to ``p->count`` maintains the relationship
7771	requirement:
7772
7773	.. code-block:: c
7774
7775	void use_foo(int index, int val) {
7776	if (p->count == 0)
7777	return;
7778	--p->count;
7779	p->array[index] = val;
7780	})reST";
7781
7782	static const char AttrDoc_SpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
7783	that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
7784	should be enabled for the function body. This can also be applied to a method
7785	in Objective C. This attribute will take precedence over the command line flag in
7786	the case where `-mno-speculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
7787
7788	Speculative Load Hardening is a best-effort mitigation against
7789	information leak attacks that make use of control flow
7790	miss-speculation - specifically miss-speculation of whether a branch
7791	is taken or not. Typically vulnerabilities enabling such attacks are
7792	classified as "Spectre variant #1". Notably, this does not attempt to
7793	mitigate against miss-speculation of branch target, classified as
7794	"Spectre variant #2" vulnerabilities.
7795
7796	When inlining, the attribute is sticky. Inlining a function that
7797	carries this attribute will cause the caller to gain the
7798	attribute. This is intended to provide a maximally conservative model
7799	where the code in a function annotated with this attribute will always
7800	(even after inlining) end up hardened.)reST";
7801
7802	static const char AttrDoc_StackProtectorIgnore[] = R"reST(The ``stack_protector_ignore`` attribute skips analysis of the given local
7803	variable when determining if a function should use a stack protector.
7804
7805	The ``-fstack-protector`` option uses a heuristic to only add stack protectors
7806	to functions which contain variables or buffers over some size threshold. This
7807	attribute overrides that heuristic for the attached variable, opting
7808	them out. If this results in no variables or buffers remaining over the stack
7809	protector threshold, then the function will no longer use a stack protector.)reST";
7810
7811	static const char AttrDoc_StandaloneDebug[] = R"reST(The ``standalone_debug`` attribute causes debug info to be emitted for a record
7812	type regardless of the debug info optimizations that are enabled with
7813	-fno-standalone-debug. This attribute only has an effect when debug info
7814	optimizations are enabled (e.g. with -fno-standalone-debug), and is C++-only.)reST";
7815
7816	static const char AttrDoc_StdCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
7817	function to clear parameters off of the stack on return. This convention does
7818	not support variadic calls or unprototyped functions in C, and has no effect on
7819	x86_64 targets. This calling convention is used widely by the Windows API and
7820	COM applications. See the documentation for `__stdcall`_ on MSDN.
7821
7822	.. _`__stdcall`: http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx)reST";
7823
7824	static const char AttrDoc_StrictFP[] = R"reST()reST";
7825
7826	static const char AttrDoc_StrictGuardStackCheck[] = R"reST(Clang supports the Microsoft style ``__declspec((strict_gs_check))`` attribute
7827	which upgrades the stack protector check from ``-fstack-protector`` to
7828	``-fstack-protector-strong``.
7829
7830	For example, it upgrades the stack protector for the function ``foo`` to
7831	``-fstack-protector-strong`` but function ``bar`` will still be built with the
7832	stack protector with the ``-fstack-protector`` option.
7833
7834	.. code-block:: c
7835
7836	__declspec((strict_gs_check))
7837	int foo(int x); // stack protection will be upgraded for foo.
7838
7839	int bar(int y); // bar can be built with the standard stack protector checks.)reST";
7840
7841	static const char AttrDoc_Suppress[] = R"reST(The ``suppress`` attribute suppresses unwanted warnings coming from static
7842	analysis tools such as the Clang Static Analyzer. The tool will not report
7843	any issues in source code annotated with the attribute.
7844
7845	The attribute cannot be used to suppress traditional Clang warnings, because
7846	many such warnings are emitted before the attribute is fully parsed.
7847	Consider using ``#pragma clang diagnostic`` to control such diagnostics,
7848	as described in `Controlling Diagnostics via Pragmas
7849	<https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas>`_.
7850
7851	The ``suppress`` attribute can be placed on an individual statement in order to
7852	suppress warnings about undesirable behavior occurring at that statement:
7853
7854	.. code-block:: c++
7855
7856	int foo() {
7857	int *x = nullptr;
7858	...
7859	[[clang::suppress]]
7860	return *x; // null pointer dereference warning suppressed here
7861	}
7862
7863	Putting the attribute on a compound statement suppresses all warnings in scope:
7864
7865	.. code-block:: c++
7866
7867	int foo() {
7868	[[clang::suppress]] {
7869	int *x = nullptr;
7870	...
7871	return *x; // warnings suppressed in the entire scope
7872	}
7873	}
7874
7875	The attribute can also be placed on entire declarations of functions, classes,
7876	variables, member variables, and so on, to suppress warnings related
7877	to the declarations themselves. When used this way, the attribute additionally
7878	suppresses all warnings in the lexical scope of the declaration:
7879
7880	.. code-block:: c++
7881
7882	class [[clang::suppress]] C {
7883	int foo() {
7884	int *x = nullptr;
7885	...
7886	return *x; // warnings suppressed in the entire class scope
7887	}
7888
7889	int bar();
7890	};
7891
7892	int C::bar() {
7893	int *x = nullptr;
7894	...
7895	return *x; // warning NOT suppressed! - not lexically nested in 'class C{}'
7896	}
7897
7898	Some static analysis warnings are accompanied by one or more notes, and the
7899	line of code against which the warning is emitted isn't necessarily the best
7900	for suppression purposes. In such cases the tools are allowed to implement
7901	additional ways to suppress specific warnings based on the attribute attached
7902	to a note location.
7903
7904	For example, the Clang Static Analyzer suppresses memory leak warnings when
7905	the suppression attribute is placed at the allocation site (highlited by
7906	a "note: memory is allocated"), which may be different from the line of code
7907	at which the program "loses track" of the pointer (where the warning
7908	is ultimately emitted):
7909
7910	.. code-block:: c
7911
7912	int bar1(bool coin_flip) {
7913	__attribute__((suppress))
7914	int result = (int )malloc(sizeof(int));
7915	if (coin_flip)
7916	return 1; // warning about this leak path is suppressed
7917
7918	return *result; // warning about this leak path is also suppressed
7919	}
7920
7921	int bar2(bool coin_flip) {
7922	int result = (int )malloc(sizeof(int));
7923	if (coin_flip)
7924	return 1; // leak warning on this path NOT suppressed
7925
7926	__attribute__((suppress))
7927	return *result; // leak warning is suppressed only on this path
7928	}
7929
7930
7931	When written as ``[[gsl::suppress]]``, this attribute suppresses specific
7932	clang-tidy diagnostics for rules of the `C++ Core Guidelines`_ in a portable
7933	way. The attribute can be attached to declarations, statements, and at
7934	namespace scope.
7935
7936	.. code-block:: c++
7937
7938	[[gsl::suppress("Rh-public")]]
7939	void f_() {
7940	int *p;
7941	[[gsl::suppress("type")]] {
7942	p = reinterpret_cast<int*>(7);
7943	}
7944	}
7945	namespace N {
7946	[[clang::suppress("type", "bounds")]];
7947	...
7948	}
7949
7950	.. _`C++ Core Guidelines`: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement)reST";
7951
7952	static const char AttrDoc_SwiftAsync[] = R"reST(The ``swift_async`` attribute specifies if and how a particular function or
7953	Objective-C method is imported into a swift async method. For instance:
7954
7955	.. code-block:: objc
7956
7957	@interface MyClass : NSObject
7958	-(void)notActuallyAsync:(int)p1 withCompletionHandler:(void (^)())handler
7959	__attribute__((swift_async(none)));
7960
7961	-(void)actuallyAsync:(int)p1 callThisAsync:(void (^)())fun
7962	__attribute__((swift_async(swift_private, 1)));
7963	@end
7964
7965	Here, ``notActuallyAsync:withCompletionHandler`` would have been imported as
7966	``async`` (because it's last parameter's selector piece is
7967	``withCompletionHandler``) if not for the ``swift_async(none)`` attribute.
7968	Conversely, ``actuallyAsync:callThisAsync`` wouldn't have been imported as
7969	``async`` if not for the ``swift_async`` attribute because it doesn't match the
7970	naming convention.
7971
7972	When using ``swift_async`` to enable importing, the first argument to the
7973	attribute is either ``swift_private`` or ``not_swift_private`` to indicate
7974	whether the function/method is private to the current framework, and the second
7975	argument is the index of the completion handler parameter.)reST";
7976
7977	static const char AttrDoc_SwiftAsyncCall[] = R"reST(The ``swiftasynccall`` attribute indicates that a function is
7978	compatible with the low-level conventions of Swift async functions,
7979	provided it declares the right formal arguments.
7980
7981	In most respects, this is similar to the ``swiftcall`` attribute, except for
7982	the following:
7983
7984	- A parameter may be marked ``swift_async_context``, ``swift_context``
7985	or ``swift_indirect_result`` (with the same restrictions on parameter
7986	ordering as ``swiftcall``) but the parameter attribute
7987	``swift_error_result`` is not permitted.
7988
7989	- A ``swiftasynccall`` function must have return type ``void``.
7990
7991	- Within a ``swiftasynccall`` function, a call to a ``swiftasynccall``
7992	function that is the immediate operand of a ``return`` statement is
7993	guaranteed to be performed as a tail call. This syntax is allowed even
7994	in C as an extension (a call to a void-returning function cannot be a
7995	return operand in standard C). If something in the calling function would
7996	semantically be performed after a guaranteed tail call, such as the
7997	non-trivial destruction of a local variable or temporary,
7998	then the program is ill-formed.
7999
8000	Query for this attribute with ``__has_attribute(swiftasynccall)``. Query if
8001	the target supports the calling convention with
8002	``__has_extension(swiftasynccc)``.)reST";
8003
8004	static const char AttrDoc_SwiftAsyncContext[] = R"reST(The ``swift_async_context`` attribute marks a parameter of a ``swiftasynccall``
8005	function as having the special asynchronous context-parameter ABI treatment.
8006
8007	If the function is not ``swiftasynccall``, this attribute only generates
8008	extended frame information.
8009
8010	A context parameter must have pointer or reference type.)reST";
8011
8012	static const char AttrDoc_SwiftAsyncError[] = R"reST(The ``swift_async_error`` attribute specifies how an error state will be
8013	represented in a swift async method. It's a bit analogous to the ``swift_error``
8014	attribute for the generated async method. The ``swift_async_error`` attribute
8015	can indicate a variety of different ways of representing an error.
8016
8017	- ``__attribute__((swift_async_error(zero_argument, N)))``, specifies that the
8018	async method is considered to have failed if the Nth argument to the
8019	completion handler is zero.
8020
8021	- ``__attribute__((swift_async_error(nonzero_argument, N)))``, specifies that
8022	the async method is considered to have failed if the Nth argument to the
8023	completion handler is non-zero.
8024
8025	- ``__attribute__((swift_async_error(nonnull_error)))``, specifies that the
8026	async method is considered to have failed if the ``NSError *`` argument to the
8027	completion handler is non-null.
8028
8029	- ``__attribute__((swift_async_error(none)))``, specifies that the async method
8030	cannot fail.
8031
8032
8033	For instance:
8034
8035	.. code-block:: objc
8036
8037	@interface MyClass : NSObject
8038	-(void)asyncMethod:(void (^)(char, int, float))handler
8039	__attribute__((swift_async(swift_private, 1)))
8040	__attribute__((swift_async_error(zero_argument, 2)));
8041	@end
8042
8043	Here, the ``swift_async`` attribute specifies that ``handler`` is the completion
8044	handler for this method, and the ``swift_async_error`` attribute specifies that
8045	the ``int`` parameter is the one that represents the error.)reST";
8046
8047	static const char AttrDoc_SwiftAsyncName[] = R"reST(The ``swift_async_name`` attribute provides the name of the ``async`` overload for
8048	the given declaration in Swift. If this attribute is absent, the name is
8049	transformed according to the algorithm built into the Swift compiler.
8050
8051	The argument is a string literal that contains the Swift name of the function or
8052	method. The name may be a compound Swift name. The function or method with such
8053	an attribute must have more than zero parameters, as its last parameter is
8054	assumed to be a callback that's eliminated in the Swift ``async`` name.
8055
8056	.. code-block:: objc
8057
8058	@interface URL
8059	+ (void) loadContentsFrom:(URL )url callback:(void (^)(NSData ))data __attribute__((__swift_async_name__("URL.loadContentsFrom(_:)")))
8060	@end)reST";
8061
8062	static const char AttrDoc_SwiftAttr[] = R"reST(The ``swift_attr`` provides a Swift-specific annotation for the declaration
8063	or type to which the attribute appertains to. It can be used on any declaration
8064	or type in Clang. This kind of annotation is ignored by Clang as it doesn't have any
8065	semantic meaning in languages supported by Clang. The Swift compiler can
8066	interpret these annotations according to its own rules when importing C or
8067	Objective-C declarations.)reST";
8068
8069	static const char AttrDoc_SwiftBridge[] = R"reST(The ``swift_bridge`` attribute indicates that the declaration to which the
8070	attribute appertains is bridged to the named Swift type.
8071
8072	.. code-block:: objc
8073
8074	__attribute__((__objc_root__))
8075	@interface Base
8076	- (instancetype)init;
8077	@end
8078
8079	__attribute__((__swift_bridge__("BridgedI")))
8080	@interface I : Base
8081	@end
8082
8083	In this example, the Objective-C interface ``I`` will be made available to Swift
8084	with the name ``BridgedI``. It would be possible for the compiler to refer to
8085	``I`` still in order to bridge the type back to Objective-C.)reST";
8086
8087	static const char AttrDoc_SwiftBridgedTypedef[] = R"reST(The ``swift_bridged_typedef`` attribute indicates that when the typedef to which
8088	the attribute appertains is imported into Swift, it should refer to the bridged
8089	Swift type (e.g. Swift's ``String``) rather than the Objective-C type as written
8090	(e.g. ``NSString``).
8091
8092	.. code-block:: objc
8093
8094	@interface NSString;
8095	typedef NSString *AliasedString __attribute__((__swift_bridged_typedef__));
8096
8097	extern void acceptsAliasedString(AliasedString _Nonnull parameter);
8098
8099	In this case, the function ``acceptsAliasedString`` will be imported into Swift
8100	as a function which accepts a ``String`` type parameter.)reST";
8101
8102	static const char AttrDoc_SwiftCall[] = R"reST(The ``swiftcall`` attribute indicates that a function should be called
8103	using the Swift calling convention for a function or function pointer.
8104
8105	The lowering for the Swift calling convention, as described by the Swift
8106	ABI documentation, occurs in multiple phases. The first, "high-level"
8107	phase breaks down the formal parameters and results into innately direct
8108	and indirect components, adds implicit parameters for the generic
8109	signature, and assigns the context and error ABI treatments to parameters
8110	where applicable. The second phase breaks down the direct parameters
8111	and results from the first phase and assigns them to registers or the
8112	stack. The ``swiftcall`` convention only handles this second phase of
8113	lowering; the C function type must accurately reflect the results
8114	of the first phase, as follows:
8115
8116	- Results classified as indirect by high-level lowering should be
8117	represented as parameters with the ``swift_indirect_result`` attribute.
8118
8119	- Results classified as direct by high-level lowering should be represented
8120	as follows:
8121
8122	- First, remove any empty direct results.
8123
8124	- If there are no direct results, the C result type should be ``void``.
8125
8126	- If there is one direct result, the C result type should be a type with
8127	the exact layout of that result type.
8128
8129	- If there are a multiple direct results, the C result type should be
8130	a struct type with the exact layout of a tuple of those results.
8131
8132	- Parameters classified as indirect by high-level lowering should be
8133	represented as parameters of pointer type.
8134
8135	- Parameters classified as direct by high-level lowering should be
8136	omitted if they are empty types; otherwise, they should be represented
8137	as a parameter type with a layout exactly matching the layout of the
8138	Swift parameter type.
8139
8140	- The context parameter, if present, should be represented as a trailing
8141	parameter with the ``swift_context`` attribute.
8142
8143	- The error result parameter, if present, should be represented as a
8144	trailing parameter (always following a context parameter) with the
8145	``swift_error_result`` attribute.
8146
8147	``swiftcall`` does not support variadic arguments or unprototyped functions.
8148
8149	The parameter ABI treatment attributes are aspects of the function type.
8150	A function type which applies an ABI treatment attribute to a
8151	parameter is a different type from an otherwise-identical function type
8152	that does not. A single parameter may not have multiple ABI treatment
8153	attributes.
8154
8155	Support for this feature is target-dependent, although it should be
8156	supported on every target that Swift supports. Query for this attribute
8157	with ``__has_attribute(swiftcall)``. Query if the target supports the
8158	calling convention with ``__has_extension(swiftcc)``. This implies
8159	support for the ``swift_context``, ``swift_error_result``, and
8160	``swift_indirect_result`` attributes.)reST";
8161
8162	static const char AttrDoc_SwiftContext[] = R"reST(The ``swift_context`` attribute marks a parameter of a ``swiftcall``
8163	or ``swiftasynccall`` function as having the special context-parameter
8164	ABI treatment.
8165
8166	This treatment generally passes the context value in a special register
8167	which is normally callee-preserved.
8168
8169	A ``swift_context`` parameter must either be the last parameter or must be
8170	followed by a ``swift_error_result`` parameter (which itself must always be
8171	the last parameter).
8172
8173	A context parameter must have pointer or reference type.)reST";
8174
8175	static const char AttrDoc_SwiftError[] = R"reST(The ``swift_error`` attribute controls whether a particular function (or
8176	Objective-C method) is imported into Swift as a throwing function, and if so,
8177	which dynamic convention it uses.
8178
8179	All of these conventions except ``none`` require the function to have an error
8180	parameter. Currently, the error parameter is always the last parameter of type
8181	``NSError*`` or ``CFErrorRef``. Swift will remove the error parameter from
8182	the imported API. When calling the API, Swift will always pass a valid address
8183	initialized to a null pointer.
8184
8185	* ``swift_error(none)`` means that the function should not be imported as
8186	throwing. The error parameter and result type will be imported normally.
8187
8188	* ``swift_error(null_result)`` means that calls to the function should be
8189	considered to have thrown if they return a null value. The return type must be
8190	a pointer type, and it will be imported into Swift with a non-optional type.
8191	This is the default error convention for Objective-C methods that return
8192	pointers.
8193
8194	* ``swift_error(zero_result)`` means that calls to the function should be
8195	considered to have thrown if they return a zero result. The return type must be
8196	an integral type. If the return type would have been imported as ``Bool``, it
8197	is instead imported as ``Void``. This is the default error convention for
8198	Objective-C methods that return a type that would be imported as ``Bool``.
8199
8200	* ``swift_error(nonzero_result)`` means that calls to the function should be
8201	considered to have thrown if they return a non-zero result. The return type must
8202	be an integral type. If the return type would have been imported as ``Bool``,
8203	it is instead imported as ``Void``.
8204
8205	* ``swift_error(nonnull_error)`` means that calls to the function should be
8206	considered to have thrown if they leave a non-null error in the error parameter.
8207	The return type is left unmodified.)reST";
8208
8209	static const char AttrDoc_SwiftErrorResult[] = R"reST(The ``swift_error_result`` attribute marks a parameter of a ``swiftcall``
8210	function as having the special error-result ABI treatment.
8211
8212	This treatment generally passes the underlying error value in and out of
8213	the function through a special register which is normally callee-preserved.
8214	This is modeled in C by pretending that the register is addressable memory:
8215
8216	- The caller appears to pass the address of a variable of pointer type.
8217	The current value of this variable is copied into the register before
8218	the call; if the call returns normally, the value is copied back into the
8219	variable.
8220
8221	- The callee appears to receive the address of a variable. This address
8222	is actually a hidden location in its own stack, initialized with the
8223	value of the register upon entry. When the function returns normally,
8224	the value in that hidden location is written back to the register.
8225
8226	A ``swift_error_result`` parameter must be the last parameter, and it must be
8227	preceded by a ``swift_context`` parameter.
8228
8229	A ``swift_error_result`` parameter must have type ``T*`` or ``T&`` for some
8230	type T. Note that no qualifiers are permitted on the intermediate level.
8231
8232	It is undefined behavior if the caller does not pass a pointer or
8233	reference to a valid object.
8234
8235	The standard convention is that the error value itself (that is, the
8236	value stored in the apparent argument) will be null upon function entry,
8237	but this is not enforced by the ABI.)reST";
8238
8239	static const char AttrDoc_SwiftImportAsNonGeneric[] = R"reST()reST";
8240
8241	static const char AttrDoc_SwiftImportPropertyAsAccessors[] = R"reST()reST";
8242
8243	static const char AttrDoc_SwiftIndirectResult[] = R"reST(The ``swift_indirect_result`` attribute marks a parameter of a ``swiftcall``
8244	or ``swiftasynccall`` function as having the special indirect-result ABI
8245	treatment.
8246
8247	This treatment gives the parameter the target's normal indirect-result
8248	ABI treatment, which may involve passing it differently from an ordinary
8249	parameter. However, only the first indirect result will receive this
8250	treatment. Furthermore, low-level lowering may decide that a direct result
8251	must be returned indirectly; if so, this will take priority over the
8252	``swift_indirect_result`` parameters.
8253
8254	A ``swift_indirect_result`` parameter must either be the first parameter or
8255	follow another ``swift_indirect_result`` parameter.
8256
8257	A ``swift_indirect_result`` parameter must have type ``T*`` or ``T&`` for
8258	some object type ``T``. If ``T`` is a complete type at the point of
8259	definition of a function, it is undefined behavior if the argument
8260	value does not point to storage of adequate size and alignment for a
8261	value of type ``T``.
8262
8263	Making indirect results explicit in the signature allows C functions to
8264	directly construct objects into them without relying on language
8265	optimizations like C++'s named return value optimization (NRVO).)reST";
8266
8267	static const char AttrDoc_SwiftName[] = R"reST(The ``swift_name`` attribute provides the name of the declaration in Swift. If
8268	this attribute is absent, the name is transformed according to the algorithm
8269	built into the Swift compiler.
8270
8271	The argument is a string literal that contains the Swift name of the function,
8272	variable, or type. When renaming a function, the name may be a compound Swift
8273	name. For a type, enum constant, property, or variable declaration, the name
8274	must be a simple or qualified identifier.
8275
8276	.. code-block:: objc
8277
8278	@interface URL
8279	- (void) initWithString:(NSString *)s __attribute__((__swift_name__("URL.init(_:)")))
8280	@end
8281
8282	void __attribute__((__swift_name__("squareRoot()"))) sqrt(double v) {
8283	})reST";
8284
8285	static const char AttrDoc_SwiftNewType[] = R"reST(The ``swift_newtype`` attribute indicates that the typedef to which the
8286	attribute appertains is imported as a new Swift type of the typedef's name.
8287	Previously, the attribute was spelt ``swift_wrapper``. While the behaviour of
8288	the attribute is identical with either spelling, ``swift_wrapper`` is
8289	deprecated, only exists for compatibility purposes, and should not be used in
8290	new code.
8291
8292	* ``swift_newtype(struct)`` means that a Swift struct will be created for this
8293	typedef.
8294
8295	* ``swift_newtype(enum)`` means that a Swift enum will be created for this
8296	typedef.
8297
8298	.. code-block:: c
8299
8300	// Import UIFontTextStyle as an enum type, with enumerated values being
8301	// constants.
8302	typedef NSString * UIFontTextStyle __attribute__((__swift_newtype__(enum)));
8303
8304	// Import UIFontDescriptorFeatureKey as a structure type, with enumerated
8305	// values being members of the type structure.
8306	typedef NSString * UIFontDescriptorFeatureKey __attribute__((__swift_newtype__(struct)));)reST";
8307
8308	static const char AttrDoc_SwiftNullability[] = R"reST()reST";
8309
8310	static const char AttrDoc_SwiftObjCMembers[] = R"reST(This attribute indicates that Swift subclasses and members of Swift extensions
8311	of this class will be implicitly marked with the ``@objcMembers`` Swift
8312	attribute, exposing them back to Objective-C.)reST";
8313
8314	static const char AttrDoc_SwiftPrivate[] = R"reST(Declarations marked with the ``swift_private`` attribute are hidden from the
8315	framework client but are still made available for use within the framework or
8316	Swift SDK overlay.
8317
8318	The purpose of this attribute is to permit a more idomatic implementation of
8319	declarations in Swift while hiding the non-idiomatic one.)reST";
8320
8321	static const char AttrDoc_SwiftType[] = R"reST()reST";
8322
8323	static const char AttrDoc_SwiftVersionedAddition[] = R"reST()reST";
8324
8325	static const char AttrDoc_SwiftVersionedRemoval[] = R"reST()reST";
8326
8327	static const char AttrDoc_SysVABI[] = R"reST(On Windows x86_64 targets, this attribute changes the calling convention of a
8328	function to match the default convention used on Sys V targets such as Linux,
8329	Mac, and BSD. This attribute has no effect on other targets.)reST";
8330
8331	static const char AttrDoc_TLSModel[] = R"reST(The ``tls_model`` attribute allows you to specify which thread-local storage
8332	model to use. It accepts the following strings:
8333
8334	* global-dynamic
8335	* local-dynamic
8336	* initial-exec
8337	* local-exec
8338
8339	TLS models are mutually exclusive.)reST";
8340
8341	static const char AttrDoc_Target[] = R"reST(Clang supports the GNU style ``__attribute__((target("OPTIONS")))`` attribute.
8342	This attribute may be attached to a function definition and instructs
8343	the backend to use different code generation options than were passed on the
8344	command line.
8345
8346	The current set of options correspond to the existing "subtarget features" for
8347	the target with or without a "-mno-" in front corresponding to the absence
8348	of the feature, as well as ``arch="CPU"`` which will change the default "CPU"
8349	for the function.
8350
8351	For X86, the attribute also allows ``tune="CPU"`` to optimize the generated
8352	code for the given CPU without changing the available instructions.
8353
8354	For AArch64, ``arch="Arch"`` will set the architecture, similar to the -march
8355	command line options. ``cpu="CPU"`` can be used to select a specific cpu,
8356	as per the ``-mcpu`` option, similarly for ``tune=``. The attribute also allows the
8357	"branch-protection=<args>" option, where the permissible arguments and their
8358	effect on code generation are the same as for the command-line option
8359	``-mbranch-protection``.
8360
8361	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
8362	"avx", "xop" and largely correspond to the machine specific options handled by
8363	the front end.
8364
8365	Note that this attribute does not apply transitively to nested functions such
8366	as blocks or C++ lambdas.
8367
8368	Additionally, this attribute supports function multiversioning for ELF based
8369	x86/x86-64 targets, which can be used to create multiple implementations of the
8370	same function that will be resolved at runtime based on the priority of their
8371	``target`` attribute strings. A function is considered a multiversioned function
8372	if either two declarations of the function have different ``target`` attribute
8373	strings, or if it has a ``target`` attribute string of ``default``. For
8374	example:
8375
8376	.. code-block:: c++
8377
8378	__attribute__((target("arch=atom")))
8379	void foo() {} // will be called on 'atom' processors.
8380	__attribute__((target("default")))
8381	void foo() {} // will be called on any other processors.
8382
8383	All multiversioned functions must contain a ``default`` (fallback)
8384	implementation, otherwise usages of the function are considered invalid.
8385	Additionally, a function may not become multiversioned after its first use.)reST";
8386
8387	static const char AttrDoc_TargetClones[] = R"reST(Clang supports the ``target_clones("OPTIONS")`` attribute. This attribute may be
8388	attached to a function declaration and causes function multiversioning, where
8389	multiple versions of the function will be emitted with different code
8390	generation options. Additionally, these versions will be resolved at runtime
8391	based on the priority of their attribute options. All ``target_clone`` functions
8392	are considered multiversioned functions.
8393
8394	For AArch64 target:
8395	The attribute contains comma-separated strings of target features joined by "+"
8396	sign. For example:
8397
8398	.. code-block:: c++
8399
8400	__attribute__((target_clones("sha2+memtag", "fcma+sve2-pmull128")))
8401	void foo() {}
8402
8403	For every multiversioned function a ``default`` (fallback) implementation
8404	always generated if not specified directly.
8405
8406	For x86/x86-64 targets:
8407	All multiversioned functions must contain a ``default`` (fallback)
8408	implementation, otherwise usages of the function are considered invalid.
8409	Additionally, a function may not become multiversioned after its first use.
8410
8411	The options to ``target_clones`` can either be a target-specific architecture
8412	(specified as ``arch=CPU``), or one of a list of subtarget features.
8413
8414	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
8415	"avx", "xop" and largely correspond to the machine specific options handled by
8416	the front end.
8417
8418	The versions can either be listed as a comma-separated sequence of string
8419	literals or as a single string literal containing a comma-separated list of
8420	versions. For compatibility with GCC, the two formats can be mixed. For
8421	example, the following will emit 4 versions of the function:
8422
8423	.. code-block:: c++
8424
8425	__attribute__((target_clones("arch=atom,avx2","arch=ivybridge","default")))
8426	void foo() {}
8427
8428	For targets that support the GNU indirect function (IFUNC) feature, dispatch
8429	is performed by emitting an indirect function that is resolved to the appropriate
8430	target clone at load time. The indirect function is given the name the
8431	multiversioned function would have if it had been declared without the attribute.
8432	For backward compatibility with earlier Clang releases, a function alias with an
8433	``.ifunc`` suffix is also emitted. The ``.ifunc`` suffixed symbol is a deprecated
8434	feature and support for it may be removed in the future.)reST";
8435
8436	static const char AttrDoc_TargetVersion[] = R"reST(For AArch64 target clang supports function multiversioning by
8437	``__attribute__((target_version("OPTIONS")))`` attribute. When applied to a
8438	function it instructs compiler to emit multiple function versions based on
8439	``target_version`` attribute strings, which resolved at runtime depend on their
8440	priority and target features availability. One of the versions is always
8441	( implicitly or explicitly ) the ``default`` (fallback). Attribute strings can
8442	contain dependent features names joined by the "+" sign.
8443
8444	For targets that support the GNU indirect function (IFUNC) feature, dispatch
8445	is performed by emitting an indirect function that is resolved to the appropriate
8446	target clone at load time. The indirect function is given the name the
8447	multiversioned function would have if it had been declared without the attribute.
8448	For backward compatibility with earlier Clang releases, a function alias with an
8449	``.ifunc`` suffix is also emitted. The ``.ifunc`` suffixed symbol is a deprecated
8450	feature and support for it may be removed in the future.)reST";
8451
8452	static const char AttrDoc_TestTypestate[] = R"reST(Use ``__attribute__((test_typestate(tested_state)))`` to indicate that a method
8453	returns true if the object is in the specified state..)reST";
8454
8455	static const char AttrDoc_ThisCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
8456	function to use ECX for the first parameter (typically the implicit ``this``
8457	parameter of C++ methods) and clear parameters off of the stack on return. This
8458	convention does not support variadic calls or unprototyped functions in C, and
8459	has no effect on x86_64 targets. See the documentation for `__thiscall`_ on
8460	MSDN.
8461
8462	.. _`__thiscall`: http://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx)reST";
8463
8464	static const char AttrDoc_Thread[] = R"reST(The ``__declspec(thread)`` attribute declares a variable with thread local
8465	storage. It is available under the ``-fms-extensions`` flag for MSVC
8466	compatibility. See the documentation for `__declspec(thread)`_ on MSDN.
8467
8468	.. _`__declspec(thread)`: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx
8469
8470	In Clang, ``__declspec(thread)`` is generally equivalent in functionality to the
8471	GNU ``__thread`` keyword. The variable must not have a destructor and must have
8472	a constant initializer, if any. The attribute only applies to variables
8473	declared with static storage duration, such as globals, class static data
8474	members, and static locals.)reST";
8475
8476	static const char AttrDoc_TransparentUnion[] = R"reST(This attribute can be applied to a union to change the behavior of calls to
8477	functions that have an argument with a transparent union type. The compiler
8478	behavior is changed in the following manner:
8479
8480	- A value whose type is any member of the transparent union can be passed as an
8481	argument without the need to cast that value.
8482
8483	- The argument is passed to the function using the calling convention of the
8484	first member of the transparent union. Consequently, all the members of the
8485	transparent union should have the same calling convention as its first member.
8486
8487	Transparent unions are not supported in C++.)reST";
8488
8489	static const char AttrDoc_TrivialABI[] = R"reST(The ``trivial_abi`` attribute can be applied to a C++ class, struct, or union.
8490	It instructs the compiler to pass and return the type using the C ABI for the
8491	underlying type when the type would otherwise be considered non-trivial for the
8492	purpose of calls.
8493	A class annotated with ``trivial_abi`` can have non-trivial destructors or
8494	copy/move constructors without automatically becoming non-trivial for the
8495	purposes of calls. For example:
8496
8497	.. code-block:: c++
8498
8499	// A is trivial for the purposes of calls because ``trivial_abi`` makes the
8500	// user-provided special functions trivial.
8501	struct __attribute__((trivial_abi)) A {
8502	~A();
8503	A(const A &);
8504	A(A &&);
8505	int x;
8506	};
8507
8508	// B's destructor and copy/move constructor are considered trivial for the
8509	// purpose of calls because A is trivial.
8510	struct B {
8511	A a;
8512	};
8513
8514	If a type is trivial for the purposes of calls, has a non-trivial destructor,
8515	and is passed as an argument by value, the convention is that the callee will
8516	destroy the object before returning. The lifetime of the copy of the parameter
8517	in the caller ends without a destructor call when the call begins.
8518
8519	If a type is trivial for the purpose of calls, it is assumed to be trivially
8520	relocatable for the purpose of ``__is_trivially_relocatable`` and
8521	``__builtin_is_cpp_trivially_relocatable``.
8522	When a type marked with ``[[trivial_abi]]`` is used as a function argument,
8523	the compiler may omit the call to the copy constructor.
8524	Thus, side effects of the copy constructor are potentially not performed.
8525	For example, objects that contain pointers to themselves or otherwise depend
8526	on their address (or the address or their subobjects) should not be declared
8527	``[[trivial_abi]]``.
8528
8529	Attribute ``trivial_abi`` has no effect in the following cases:
8530
8531	- The class directly declares a virtual base or virtual methods.
8532	- Copy constructors and move constructors of the class are all deleted.
8533	- The class has a base class that is non-trivial for the purposes of calls.
8534	- The class has a non-static data member whose type is non-trivial for the
8535	purposes of calls, which includes:
8536
8537	- classes that are non-trivial for the purposes of calls
8538	- __weak-qualified types in Objective-C++
8539	- arrays of any of the above)reST";
8540
8541	static const char AttrDoc_TryAcquireCapability[] = R"reST(Marks a function that attempts to acquire a capability. This function may fail to
8542	actually acquire the capability; they accept a Boolean value determining
8543	whether acquiring the capability means success (true), or failing to acquire
8544	the capability means success (false).)reST";
8545
8546	static const char AttrDoc_TypeNonNull[] = R"reST(The ``_Nonnull`` nullability qualifier indicates that null is not a meaningful
8547	value for a value of the ``_Nonnull`` pointer type. For example, given a
8548	declaration such as:
8549
8550	.. code-block:: c
8551
8552	int fetch(int * _Nonnull ptr);
8553
8554	a caller of ``fetch`` should not provide a null value, and the compiler will
8555	produce a warning if it sees a literal null value passed to ``fetch``. Note
8556	that, unlike the declaration attribute ``nonnull``, the presence of
8557	``_Nonnull`` does not imply that passing null is undefined behavior: ``fetch``
8558	is free to consider null undefined behavior or (perhaps for
8559	backward-compatibility reasons) defensively handle null.)reST";
8560
8561	static const char AttrDoc_TypeNullUnspecified[] = R"reST(The ``_Null_unspecified`` nullability qualifier indicates that neither the
8562	``_Nonnull`` nor ``_Nullable`` qualifiers make sense for a particular pointer
8563	type. It is used primarily to indicate that the role of null with specific
8564	pointers in a nullability-annotated header is unclear, e.g., due to
8565	overly-complex implementations or historical factors with a long-lived API.)reST";
8566
8567	static const char AttrDoc_TypeNullable[] = R"reST(The ``_Nullable`` nullability qualifier indicates that a value of the
8568	``_Nullable`` pointer type can be null. For example, given:
8569
8570	.. code-block:: c
8571
8572	int fetch_or_zero(int * _Nullable ptr);
8573
8574	a caller of ``fetch_or_zero`` can provide null.
8575
8576	The ``_Nullable`` attribute on classes indicates that the given class can
8577	represent null values, and so the ``_Nullable``, ``_Nonnull`` etc qualifiers
8578	make sense for this type. For example:
8579
8580	.. code-block:: c
8581
8582	class _Nullable ArenaPointer { ... };
8583
8584	ArenaPointer _Nonnull x = ...;
8585	ArenaPointer _Nullable y = nullptr;)reST";
8586
8587	static const char AttrDoc_TypeNullableResult[] = R"reST(The ``_Nullable_result`` nullability qualifier means that a value of the
8588	``_Nullable_result`` pointer can be ``nil``, just like ``_Nullable``. Where this
8589	attribute differs from ``_Nullable`` is when it's used on a parameter to a
8590	completion handler in a Swift async method. For instance, here:
8591
8592	.. code-block:: objc
8593
8594	-(void)fetchSomeDataWithID:(int)identifier
8595	completionHandler:(void (^)(Data _Nullable_result result, NSError error))completionHandler;
8596
8597	This method asynchronously calls ``completionHandler`` when the data is
8598	available, or calls it with an error. ``_Nullable_result`` indicates to the
8599	Swift importer that this is the uncommon case where ``result`` can get ``nil``
8600	even if no error has occurred, and will therefore import it as a Swift optional
8601	type. Otherwise, if ``result`` was annotated with ``_Nullable``, the Swift
8602	importer will assume that ``result`` will always be non-nil unless an error
8603	occurred.)reST";
8604
8605	static const char AttrDoc_TypeTagForDatatype[] = R"reST(When declaring a variable, use
8606	``__attribute__((type_tag_for_datatype(kind, type)))`` to create a type tag that
8607	is tied to the ``type`` argument given to the attribute.
8608
8609	In the attribute prototype above:
8610	* ``kind`` is an identifier that should be used when annotating all applicable
8611	type tags.
8612	* ``type`` indicates the name of the type.
8613
8614	Clang supports annotating type tags of two forms.
8615
8616	* Type tag that is a reference to a declared identifier.
8617	Use ``__attribute__((type_tag_for_datatype(kind, type)))`` when declaring that
8618	identifier:
8619
8620	.. code-block:: c++
8621
8622	typedef int MPI_Datatype;
8623	extern struct mpi_datatype mpi_datatype_int
8624	__attribute__(( type_tag_for_datatype(mpi,int) ));
8625	#define MPI_INT ((MPI_Datatype) &mpi_datatype_int)
8626	// &mpi_datatype_int is a type tag. It is tied to type "int".
8627
8628	* Type tag that is an integral literal.
8629	Declare a ``static const`` variable with an initializer value and attach
8630	``__attribute__((type_tag_for_datatype(kind, type)))`` on that declaration:
8631
8632	.. code-block:: c++
8633
8634	typedef int MPI_Datatype;
8635	static const MPI_Datatype mpi_datatype_int
8636	__attribute__(( type_tag_for_datatype(mpi,int) )) = 42;
8637	#define MPI_INT ((MPI_Datatype) 42)
8638	// The number 42 is a type tag. It is tied to type "int".
8639
8640
8641	The ``type_tag_for_datatype`` attribute also accepts an optional third argument
8642	that determines how the type of the function argument specified by either
8643	``arg_idx`` or ``ptr_idx`` is compared against the type associated with the type
8644	tag. (Recall that for the ``argument_with_type_tag`` attribute, the type of the
8645	function argument specified by ``arg_idx`` is compared against the type
8646	associated with the type tag. Also recall that for the ``pointer_with_type_tag``
8647	attribute, the pointee type of the function argument specified by ``ptr_idx`` is
8648	compared against the type associated with the type tag.) There are two supported
8649	values for this optional third argument:
8650
8651	* ``layout_compatible`` will cause types to be compared according to
8652	layout-compatibility rules (In C++11 [class.mem] p 17, 18, see the
8653	layout-compatibility rules for two standard-layout struct types and for two
8654	standard-layout union types). This is useful when creating a type tag
8655	associated with a struct or union type. For example:
8656
8657	.. code-block:: c++
8658
8659	/* In mpi.h */
8660	typedef int MPI_Datatype;
8661	struct internal_mpi_double_int { double d; int i; };
8662	extern struct mpi_datatype mpi_datatype_double_int
8663	__attribute__(( type_tag_for_datatype(mpi,
8664	struct internal_mpi_double_int, layout_compatible) ));
8665
8666	#define MPI_DOUBLE_INT ((MPI_Datatype) &mpi_datatype_double_int)
8667
8668	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
8669	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
8670
8671	/* In user code */
8672	struct my_pair { double a; int b; };
8673	struct my_pair *buffer;
8674	MPI_Send(buffer, 1, MPI_DOUBLE_INT /, ... /); // no warning because the
8675	// layout of my_pair is
8676	// compatible with that of
8677	// internal_mpi_double_int
8678
8679	struct my_int_pair { int a; int b; }
8680	struct my_int_pair *buffer2;
8681	MPI_Send(buffer2, 1, MPI_DOUBLE_INT /, ... /); // warning because the
8682	// layout of my_int_pair
8683	// does not match that of
8684	// internal_mpi_double_int
8685
8686	* ``must_be_null`` specifies that the function argument specified by either
8687	``arg_idx`` (for the ``argument_with_type_tag`` attribute) or ``ptr_idx`` (for
8688	the ``pointer_with_type_tag`` attribute) should be a null pointer constant.
8689	The second argument to the ``type_tag_for_datatype`` attribute is ignored. For
8690	example:
8691
8692	.. code-block:: c++
8693
8694	/* In mpi.h */
8695	typedef int MPI_Datatype;
8696	extern struct mpi_datatype mpi_datatype_null
8697	__attribute__(( type_tag_for_datatype(mpi, void, must_be_null) ));
8698
8699	#define MPI_DATATYPE_NULL ((MPI_Datatype) &mpi_datatype_null)
8700	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
8701	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
8702
8703	/* In user code */
8704	struct my_pair { double a; int b; };
8705	struct my_pair *buffer;
8706	MPI_Send(buffer, 1, MPI_DATATYPE_NULL /, ... /); // warning: MPI_DATATYPE_NULL
8707	// was specified but buffer
8708	// is not a null pointer)reST";
8709
8710	static const char AttrDoc_TypeVisibility[] = R"reST(The ``type_visibility`` attribute allows the visibility of a type and its vague
8711	linkage objects (vtable, typeinfo, typeinfo name) to be controlled separately from
8712	the visibility of functions and data members of the type.
8713
8714	For example, this can be used to give default visibility to the typeinfo and the vtable
8715	of a type while still keeping hidden visibility on its member functions and static data
8716	members.
8717
8718	This attribute can only be applied to types and namespaces.
8719
8720	If both ``visibility`` and ``type_visibility`` are applied to a type or a namespace, the
8721	visibility specified with the ``type_visibility`` attribute overrides the visibility
8722	provided with the regular ``visibility`` attribute.)reST";
8723
8724	static const char AttrDoc_UPtr[] = R"reST(The ``__uptr`` qualifier specifies that a 32-bit pointer should be zero
8725	extended when converted to a 64-bit pointer.)reST";
8726
8727	static const char AttrDoc_Unavailable[] = R"reST(No documentation.)reST";
8728
8729	static const char AttrDoc_Uninitialized[] = R"reST(The command-line parameter ``-ftrivial-auto-var-init=*`` can be used to
8730	initialize trivial automatic stack variables. By default, trivial automatic
8731	stack variables are uninitialized. This attribute is used to override the
8732	command-line parameter, forcing variables to remain uninitialized. It has no
8733	semantic meaning in that using uninitialized values is undefined behavior,
8734	it rather documents the programmer's intent.)reST";
8735
8736	static const char AttrDoc_Unlikely[] = R"reST(The ``likely`` and ``unlikely`` attributes are used as compiler hints.
8737	The attributes are used to aid the compiler to determine which branch is
8738	likely or unlikely to be taken. This is done by marking the branch substatement
8739	with one of the two attributes.
8740
8741	It isn't allowed to annotate a single statement with both ``likely`` and
8742	``unlikely``. Annotating the ``true`` and ``false`` branch of an ``if``
8743	statement with the same likelihood attribute will result in a diagnostic and
8744	the attributes are ignored on both branches.
8745
8746	In a ``switch`` statement it's allowed to annotate multiple ``case`` labels
8747	or the ``default`` label with the same likelihood attribute. This makes
8748	* all labels without an attribute have a neutral likelihood,
8749	* all labels marked ``[[likely]]`` have an equally positive likelihood, and
8750	* all labels marked ``[[unlikely]]`` have an equally negative likelihood.
8751	The neutral likelihood is the more likely of path execution than the negative
8752	likelihood. The positive likelihood is the more likely of path of execution
8753	than the neutral likelihood.
8754
8755	These attributes have no effect on the generated code when using
8756	PGO (Profile-Guided Optimization) or at optimization level 0.
8757
8758	In Clang, the attributes will be ignored if they're not placed on
8759	* the ``case`` or ``default`` label of a ``switch`` statement,
8760	* or on the substatement of an ``if`` or ``else`` statement,
8761	* or on the substatement of an ``for`` or ``while`` statement.
8762	The C++ Standard recommends to honor them on every statement in the
8763	path of execution, but that can be confusing:
8764
8765	.. code-block:: c++
8766
8767	if (b) {
8768	[[unlikely]] --b; // In the path of execution,
8769	// this branch is considered unlikely.
8770	}
8771
8772	if (b) {
8773	--b;
8774	if(b)
8775	return;
8776	[[unlikely]] --b; // Not in the path of execution,
8777	} // the branch has no likelihood information.
8778
8779	if (b) {
8780	--b;
8781	foo(b);
8782	// Whether or not the next statement is in the path of execution depends
8783	// on the declaration of foo():
8784	// In the path of execution: void foo(int);
8785	// Not in the path of execution: [[noreturn]] void foo(int);
8786	// This means the likelihood of the branch depends on the declaration
8787	// of foo().
8788	[[unlikely]] --b;
8789	}
8790
8791
8792	Below are some example usages of the likelihood attributes and their effects:
8793
8794	.. code-block:: c++
8795
8796	if (b) [[likely]] { // Placement on the first statement in the branch.
8797	// The compiler will optimize to execute the code here.
8798	} else {
8799	}
8800
8801	if (b)
8802	[[unlikely]] b++; // Placement on the first statement in the branch.
8803	else {
8804	// The compiler will optimize to execute the code here.
8805	}
8806
8807	if (b) {
8808	[[unlikely]] b++; // Placement on the second statement in the branch.
8809	} // The attribute will be ignored.
8810
8811	if (b) [[likely]] {
8812	[[unlikely]] b++; // No contradiction since the second attribute
8813	} // is ignored.
8814
8815	if (b)
8816	;
8817	else [[likely]] {
8818	// The compiler will optimize to execute the code here.
8819	}
8820
8821	if (b)
8822	;
8823	else
8824	// The compiler will optimize to execute the next statement.
8825	[[likely]] b = f();
8826
8827	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
8828	else [[likely]]; // and the attributes are ignored.
8829
8830	if (b)
8831	[[likely]] int i = 5; // Issues a diagnostic since the attribute
8832	// isn't allowed on a declaration.
8833
8834	switch (i) {
8835	[[likely]] case 1: // This value is likely
8836	...
8837	break;
8838
8839	[[unlikely]] case 2: // This value is unlikely
8840	...
8841	[[fallthrough]];
8842
8843	case 3: // No likelihood attribute
8844	...
8845	[[likely]] break; // No effect
8846
8847	case 4: [[likely]] { // attribute on substatement has no effect
8848	...
8849	break;
8850	}
8851
8852	[[unlikely]] default: // All other values are unlikely
8853	...
8854	break;
8855	}
8856
8857	switch (i) {
8858	[[likely]] case 0: // This value and code path is likely
8859	...
8860	[[fallthrough]];
8861
8862	case 1: // No likelihood attribute, code path is neutral
8863	break; // falling through has no effect on the likelihood
8864
8865	case 2: // No likelihood attribute, code path is neutral
8866	[[fallthrough]];
8867
8868	[[unlikely]] default: // This value and code path are both unlikely
8869	break;
8870	}
8871
8872	for(int i = 0; i != size; ++i) [[likely]] {
8873	... // The loop is the likely path of execution
8874	}
8875
8876	for(const auto &E : Elements) [[likely]] {
8877	... // The loop is the likely path of execution
8878	}
8879
8880	while(i != size) [[unlikely]] {
8881	... // The loop is the unlikely path of execution
8882	} // The generated code will optimize to skip the loop body
8883
8884	while(true) [[unlikely]] {
8885	... // The attribute has no effect
8886	} // Clang elides the comparison and generates an infinite
8887	// loop)reST";
8888
8889	static const char AttrDoc_UnsafeBufferUsage[] = R"reST(The attribute ``[[clang::unsafe_buffer_usage]]`` should be placed on functions
8890	that need to be avoided as they are prone to buffer overflows or unsafe buffer
8891	struct fields. It is designed to work together with the off-by-default compiler
8892	warning ``-Wunsafe-buffer-usage`` to help codebases transition away from raw pointer
8893	based buffer management, in favor of safer abstractions such as C++20 ``std::span``.
8894	The attribute causes ``-Wunsafe-buffer-usage`` to warn on every use of the function or
8895	the field it is attached to, and it may also lead to emission of automatic fix-it
8896	hints which would help the user replace the use of unsafe functions(/fields) with safe
8897	alternatives, though the attribute can be used even when the fix can't be automated.
8898
8899	* Attribute attached to functions: The attribute suppresses all
8900	``-Wunsafe-buffer-usage`` warnings within the function it is attached to, as the
8901	function is now classified as unsafe. The attribute should be used carefully, as it
8902	will silence all unsafe operation warnings inside the function; including any new
8903	unsafe operations introduced in the future.
8904
8905	The attribute is warranted even if the only way a function can overflow
8906	the buffer is by violating the function's preconditions. For example, it
8907	would make sense to put the attribute on function ``foo()`` below because
8908	passing an incorrect size parameter would cause a buffer overflow:
8909
8910	.. code-block:: c++
8911
8912	[[clang::unsafe_buffer_usage]]
8913	void foo(int *buf, size_t size) {
8914	for (size_t i = 0; i < size; ++i) {
8915	buf[i] = i;
8916	}
8917	}
8918
8919	The attribute is NOT warranted when the function uses safe abstractions,
8920	assuming that these abstractions weren't misused outside the function.
8921	For example, function ``bar()`` below doesn't need the attribute,
8922	because assuming that the container ``buf`` is well-formed (has size that
8923	fits the original buffer it refers to), overflow cannot occur:
8924
8925	.. code-block:: c++
8926
8927	void bar(std::span<int> buf) {
8928	for (size_t i = 0; i < buf.size(); ++i) {
8929	buf[i] = i;
8930	}
8931	}
8932
8933	In this case function ``bar()`` enables the user to keep the buffer
8934	"containerized" in a span for as long as possible. On the other hand,
8935	Function ``foo()`` in the previous example may have internal
8936	consistency, but by accepting a raw buffer it requires the user to unwrap
8937	their span, which is undesirable according to the programming model
8938	behind ``-Wunsafe-buffer-usage``.
8939
8940	The attribute is warranted when a function accepts a raw buffer only to
8941	immediately put it into a span:
8942
8943	.. code-block:: c++
8944
8945	[[clang::unsafe_buffer_usage]]
8946	void baz(int *buf, size_t size) {
8947	std::span<int> sp{ buf, size };
8948	for (size_t i = 0; i < sp.size(); ++i) {
8949	sp[i] = i;
8950	}
8951	}
8952
8953	In this case ``baz()`` does not contain any unsafe operations, but the awkward
8954	parameter type causes the caller to unwrap the span unnecessarily.
8955	Note that regardless of the attribute, code inside ``baz()`` isn't flagged
8956	by ``-Wunsafe-buffer-usage`` as unsafe. It is definitely undesirable,
8957	but if ``baz()`` is on an API surface, there is no way to improve it
8958	to make it as safe as ``bar()`` without breaking the source and binary
8959	compatibility with existing users of the function. In such cases
8960	the proper solution would be to create a different function (possibly
8961	an overload of ``baz()``) that accepts a safe container like ``bar()``,
8962	and then use the attribute on the original ``baz()`` to help the users
8963	update their code to use the new function.
8964
8965	* Attribute attached to fields: The attribute should only be attached to
8966	struct fields, if the fields can not be updated to a safe type with bounds
8967	check, such as std::span. In other words, the buffers prone to unsafe accesses
8968	should always be updated to use safe containers/views and attaching the attribute
8969	must be last resort when such an update is infeasible.
8970
8971	The attribute can be placed on individual fields or a set of them as shown below.
8972
8973	.. code-block:: c++
8974
8975	struct A {
8976	[[clang::unsafe_buffer_usage]]
8977	int *ptr1;
8978
8979	[[clang::unsafe_buffer_usage]]
8980	int *ptr2, buf[10];
8981
8982	[[clang::unsafe_buffer_usage]]
8983	size_t sz;
8984	};
8985
8986	Here, every read/write to the fields ptr1, ptr2, buf and sz will trigger a warning
8987	that the field has been explcitly marked as unsafe due to unsafe-buffer operations.)reST";
8988
8989	static const char AttrDoc_Unused[] = R"reST(When passing the ``-Wunused`` flag to Clang, entities that are unused by the
8990	program may be diagnosed. The ``[[maybe_unused]]`` (or
8991	``__attribute__((unused))``) attribute can be used to silence such diagnostics
8992	when the entity cannot be removed. For instance, a local variable may exist
8993	solely for use in an ``assert()`` statement, which makes the local variable
8994	unused when ``NDEBUG`` is defined.
8995
8996	The attribute may be applied to the declaration of a class, a typedef, a
8997	variable, a function or method, a function parameter, an enumeration, an
8998	enumerator, a non-static data member, or a label.
8999
9000	.. code-block:: c++
9001
9002	#include <cassert>
9003
9004	[[maybe_unused]] void f([[maybe_unused]] bool thing1,
9005	[[maybe_unused]] bool thing2) {
9006	[[maybe_unused]] bool b = thing1 && thing2;
9007	assert(b);
9008	})reST";
9009
9010	static const char AttrDoc_UseHandle[] = R"reST(A function taking a handle by value might close the handle. If a function
9011	parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
9012	the state of the handle. It is also assumed to require an open handle to work with.
9013	The attribute requires a string literal argument to identify the handle being used.
9014
9015	.. code-block:: c++
9016
9017	zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle("zircon")]],
9018	zx_time_t deadline,
9019	zx_port_packet_t* packet);)reST";
9020
9021	static const char AttrDoc_Used[] = R"reST(This attribute, when attached to a function or variable definition, indicates
9022	that there may be references to the entity which are not apparent in the source
9023	code. For example, it may be referenced from inline ``asm``, or it may be
9024	found through a dynamic symbol or section lookup.
9025
9026	The compiler must emit the definition even if it appears to be unused, and it
9027	must not apply optimizations which depend on fully understanding how the entity
9028	is used.
9029
9030	Whether this attribute has any effect on the linker depends on the target and
9031	the linker. Most linkers support the feature of section garbage collection
9032	(``--gc-sections``), also known as "dead stripping" (``ld64 -dead_strip``) or
9033	discarding unreferenced sections (``link.exe /OPT:REF``). On COFF and Mach-O
9034	targets (Windows and Apple platforms), the `used` attribute prevents symbols
9035	from being removed by linker section GC. On ELF targets, it has no effect on its
9036	own, and the linker may remove the definition if it is not otherwise referenced.
9037	This linker GC can be avoided by also adding the ``retain`` attribute. Note
9038	that ``retain`` requires special support from the linker; see that attribute's
9039	documentation for further information.)reST";
9040
9041	static const char AttrDoc_UsingIfExists[] = R"reST(The ``using_if_exists`` attribute applies to a using-declaration. It allows
9042	programmers to import a declaration that potentially does not exist, instead
9043	deferring any errors to the point of use. For instance:
9044
9045	.. code-block:: c++
9046
9047	namespace empty_namespace {};
9048	__attribute__((using_if_exists))
9049	using empty_namespace::does_not_exist; // no error!
9050
9051	does_not_exist x; // error: use of unresolved 'using_if_exists'
9052
9053	The C++ spelling of the attribute (`[[clang::using_if_exists]]`) is also
9054	supported as a clang extension, since ISO C++ doesn't support attributes in this
9055	position. If the entity referred to by the using-declaration is found by name
9056	lookup, the attribute has no effect. This attribute is useful for libraries
9057	(primarily, libc++) that wish to redeclare a set of declarations in another
9058	namespace, when the availability of those declarations is difficult or
9059	impossible to detect at compile time with the preprocessor.)reST";
9060
9061	static const char AttrDoc_Uuid[] = R"reST(No documentation.)reST";
9062
9063	static const char AttrDoc_VTablePointerAuthentication[] = R"reST(No documentation.)reST";
9064
9065	static const char AttrDoc_VecReturn[] = R"reST(No documentation.)reST";
9066
9067	static const char AttrDoc_VecTypeHint[] = R"reST(No documentation.)reST";
9068
9069	static const char AttrDoc_VectorCall[] = R"reST(On 32-bit x86 and x86_64 targets, this attribute changes the calling
9070	convention of a function to pass vector parameters in SSE registers.
9071
9072	On 32-bit x86 targets, this calling convention is similar to ``__fastcall``.
9073	The first two integer parameters are passed in ECX and EDX. Subsequent integer
9074	parameters are passed in memory, and callee clears the stack. On x86_64
9075	targets, the callee does not clear the stack, and integer parameters are
9076	passed in RCX, RDX, R8, and R9 as is done for the default Windows x64 calling
9077	convention.
9078
9079	On both 32-bit x86 and x86_64 targets, vector and floating point arguments are
9080	passed in XMM0-XMM5. Homogeneous vector aggregates of up to four elements are
9081	passed in sequential SSE registers if enough are available. If AVX is enabled,
9082	256 bit vectors are passed in YMM0-YMM5. Any vector or aggregate type that
9083	cannot be passed in registers for any reason is passed by reference, which
9084	allows the caller to align the parameter memory.
9085
9086	See the documentation for `__vectorcall`_ on MSDN for more details.
9087
9088	.. _`__vectorcall`: http://msdn.microsoft.com/en-us/library/dn375768.aspx)reST";
9089
9090	static const char AttrDoc_Visibility[] = R"reST(No documentation.)reST";
9091
9092	static const char AttrDoc_WarnUnused[] = R"reST(No documentation.)reST";
9093
9094	static const char AttrDoc_WarnUnusedResult[] = R"reST(Clang supports the ability to diagnose when the results of a function call
9095	expression are discarded under suspicious circumstances. A diagnostic is
9096	generated when a function or its return type is marked with ``[[nodiscard]]``
9097	(or ``__attribute__((warn_unused_result))``) and the function call appears as a
9098	potentially-evaluated discarded-value expression that is not explicitly cast to
9099	``void``.
9100
9101	A string literal may optionally be provided to the attribute, which will be
9102	reproduced in any resulting diagnostics. Redeclarations using different forms
9103	of the attribute (with or without the string literal or with different string
9104	literal contents) are allowed. If there are redeclarations of the entity with
9105	differing string literals, it is unspecified which one will be used by Clang
9106	in any resulting diagnostics.
9107
9108	.. code-block:: c++
9109
9110	struct [[nodiscard]] error_info { /.../ };
9111	error_info enable_missile_safety_mode();
9112
9113	void launch_missiles();
9114	void test_missiles() {
9115	enable_missile_safety_mode(); // diagnoses
9116	launch_missiles();
9117	}
9118	error_info &foo();
9119	void f() { foo(); } // Does not diagnose, error_info is a reference.
9120
9121	Additionally, discarded temporaries resulting from a call to a constructor
9122	marked with ``[[nodiscard]]`` or a constructor of a type marked
9123	``[[nodiscard]]`` will also diagnose. This also applies to type conversions that
9124	use the annotated ``[[nodiscard]]`` constructor or result in an annotated type.
9125
9126	.. code-block:: c++
9127
9128	struct [[nodiscard]] marked_type {/../ };
9129	struct marked_ctor {
9130	[[nodiscard]] marked_ctor();
9131	marked_ctor(int);
9132	};
9133
9134	struct S {
9135	operator marked_type() const;
9136	[[nodiscard]] operator int() const;
9137	};
9138
9139	void usages() {
9140	marked_type(); // diagnoses.
9141	marked_ctor(); // diagnoses.
9142	marked_ctor(3); // Does not diagnose, int constructor isn't marked nodiscard.
9143
9144	S s;
9145	static_cast<marked_type>(s); // diagnoses
9146	(int)s; // diagnoses
9147	})reST";
9148
9149	static const char AttrDoc_Weak[] = R"reST(In supported output formats the ``weak`` attribute can be used to
9150	specify that a variable or function should be emitted as a symbol with
9151	``weak`` (if a definition) or ``extern_weak`` (if a declaration of an
9152	external symbol) `linkage
9153	<https://llvm.org/docs/LangRef.html#linkage-types>`_.
9154
9155	If there is a non-weak definition of the symbol the linker will select
9156	that over the weak. They must have same type and alignment (variables
9157	must also have the same size), but may have a different value.
9158
9159	If there are multiple weak definitions of same symbol, but no non-weak
9160	definition, they should have same type, size, alignment and value, the
9161	linker will select one of them (see also selectany_ attribute).
9162
9163	If the ``weak`` attribute is applied to a ``const`` qualified variable
9164	definition that variable is no longer consider a compiletime constant
9165	as its value can change during linking (or dynamic linking). This
9166	means that it can e.g no longer be part of an initializer expression.
9167
9168	.. code-block:: c
9169
9170	const int ANSWER __attribute__ ((weak)) = 42;
9171
9172	/* This function may be replaced link-time */
9173	__attribute__ ((weak)) void debug_log(const char *msg)
9174	{
9175	fprintf(stderr, "DEBUG: %s\n", msg);
9176	}
9177
9178	int main(int argc, const char **argv)
9179	{
9180	debug_log ("Starting up...");
9181
9182	/* This may print something else than "6 * 7 = 42",
9183	if there is a non-weak definition of "ANSWER" in
9184	an object linked in */
9185	printf("6 * 7 = %d\n", ANSWER);
9186
9187	return 0;
9188	}
9189
9190	If an external declaration is marked weak and that symbol does not
9191	exist during linking (possibly dynamic) the address of the symbol will
9192	evaluate to NULL.
9193
9194	.. code-block:: c
9195
9196	void may_not_exist(void) __attribute__ ((weak));
9197
9198	int main(int argc, const char **argv)
9199	{
9200	if (may_not_exist) {
9201	may_not_exist();
9202	} else {
9203	printf("Function did not exist\n");
9204	}
9205	return 0;
9206	})reST";
9207
9208	static const char AttrDoc_WeakImport[] = R"reST(No documentation.)reST";
9209
9210	static const char AttrDoc_WeakRef[] = R"reST(No documentation.)reST";
9211
9212	static const char AttrDoc_WebAssemblyExportName[] = R"reST(Clang supports the ``__attribute__((export_name(<name>)))``
9213	attribute for the WebAssembly target. This attribute may be attached to a
9214	function declaration, where it modifies how the symbol is to be exported
9215	from the linked WebAssembly.
9216
9217	WebAssembly functions are exported via string name. By default when a symbol
9218	is exported, the export name for C/C++ symbols are the same as their C/C++
9219	symbol names. This attribute can be used to override the default behavior, and
9220	request a specific string name be used instead.)reST";
9221
9222	static const char AttrDoc_WebAssemblyFuncref[] = R"reST(Clang supports the ``__attribute__((export_name(<name>)))``
9223	attribute for the WebAssembly target. This attribute may be attached to a
9224	function declaration, where it modifies how the symbol is to be exported
9225	from the linked WebAssembly.
9226
9227	WebAssembly functions are exported via string name. By default when a symbol
9228	is exported, the export name for C/C++ symbols are the same as their C/C++
9229	symbol names. This attribute can be used to override the default behavior, and
9230	request a specific string name be used instead.)reST";
9231
9232	static const char AttrDoc_WebAssemblyImportModule[] = R"reST(Clang supports the ``__attribute__((import_module(<module_name>)))``
9233	attribute for the WebAssembly target. This attribute may be attached to a
9234	function declaration, where it modifies how the symbol is to be imported
9235	within the WebAssembly linking environment.
9236
9237	WebAssembly imports use a two-level namespace scheme, consisting of a module
9238	name, which typically identifies a module from which to import, and a field
9239	name, which typically identifies a field from that module to import. By
9240	default, module names for C/C++ symbols are assigned automatically by the
9241	linker. This attribute can be used to override the default behavior, and
9242	request a specific module name be used instead.)reST";
9243
9244	static const char AttrDoc_WebAssemblyImportName[] = R"reST(Clang supports the ``__attribute__((import_name(<name>)))``
9245	attribute for the WebAssembly target. This attribute may be attached to a
9246	function declaration, where it modifies how the symbol is to be imported
9247	within the WebAssembly linking environment.
9248
9249	WebAssembly imports use a two-level namespace scheme, consisting of a module
9250	name, which typically identifies a module from which to import, and a field
9251	name, which typically identifies a field from that module to import. By
9252	default, field names for C/C++ symbols are the same as their C/C++ symbol
9253	names. This attribute can be used to override the default behavior, and
9254	request a specific field name be used instead.)reST";
9255
9256	static const char AttrDoc_WorkGroupSizeHint[] = R"reST(No documentation.)reST";
9257
9258	static const char AttrDoc_X86ForceAlignArgPointer[] = R"reST(Use this attribute to force stack alignment.
9259
9260	Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
9261	(like 'movaps') that work with the stack require operands to be 16-byte aligned.
9262	This attribute realigns the stack in the function prologue to make sure the
9263	stack can be used with SSE instructions.
9264
9265	Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
9266	Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
9267	rare cases where the caller does not align the stack properly (e.g. flow
9268	jumps from i386 arch code).
9269
9270	.. code-block:: c
9271
9272	__attribute__ ((force_align_arg_pointer))
9273	void f () {
9274	...
9275	})reST";
9276
9277	static const char AttrDoc_XRayInstrument[] = R"reST(``__attribute__((xray_always_instrument))`` or
9278	``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++),
9279	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
9280	instrumented with XRay. This will cause the function to always have space at
9281	the beginning and exit points to allow for runtime patching.
9282
9283	Conversely, ``__attribute__((xray_never_instrument))`` or
9284	``[[clang::xray_never_instrument]]`` will inhibit the insertion of these
9285	instrumentation points.
9286
9287	If a function has neither of these attributes, they become subject to the XRay
9288	heuristics used to determine whether a function should be instrumented or
9289	otherwise.
9290
9291	``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is
9292	used to preserve N function arguments for the logging function. Currently,
9293	only N==1 is supported.)reST";
9294
9295	static const char AttrDoc_XRayLogArgs[] = R"reST(``__attribute__((xray_always_instrument))`` or
9296	``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++),
9297	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
9298	instrumented with XRay. This will cause the function to always have space at
9299	the beginning and exit points to allow for runtime patching.
9300
9301	Conversely, ``__attribute__((xray_never_instrument))`` or
9302	``[[clang::xray_never_instrument]]`` will inhibit the insertion of these
9303	instrumentation points.
9304
9305	If a function has neither of these attributes, they become subject to the XRay
9306	heuristics used to determine whether a function should be instrumented or
9307	otherwise.
9308
9309	``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is
9310	used to preserve N function arguments for the logging function. Currently,
9311	only N==1 is supported.)reST";
9312
9313	static const char AttrDoc_ZeroCallUsedRegs[] = R"reST(This attribute, when attached to a function, causes the compiler to zero a
9314	subset of all call-used registers before the function returns. It's used to
9315	increase program security by either mitigating `Return-Oriented Programming`_
9316	(ROP) attacks or preventing information leakage through registers.
9317
9318	The term "call-used" means registers which are not guaranteed to be preserved
9319	unchanged for the caller by the current calling convention. This could also be
9320	described as "caller-saved" or "not callee-saved".
9321
9322	The `choice` parameters gives the programmer flexibility to choose the subset
9323	of the call-used registers to be zeroed:
9324
9325	- ``skip`` doesn't zero any call-used registers. This choice overrides any
9326	command-line arguments.
9327	- ``used`` only zeros call-used registers used in the function. By ``used``, we
9328	mean a register whose contents have been set or referenced in the function.
9329	- ``used-gpr`` only zeros call-used GPR registers used in the function.
9330	- ``used-arg`` only zeros call-used registers used to pass arguments to the
9331	function.
9332	- ``used-gpr-arg`` only zeros call-used GPR registers used to pass arguments to
9333	the function.
9334	- ``all`` zeros all call-used registers.
9335	- ``all-gpr`` zeros all call-used GPR registers.
9336	- ``all-arg`` zeros all call-used registers used to pass arguments to the
9337	function.
9338	- ``all-gpr-arg`` zeros all call-used GPR registers used to pass arguments to
9339	the function.
9340
9341	The default for the attribute is controlled by the ``-fzero-call-used-regs``
9342	flag.
9343
9344	.. _Return-Oriented Programming: https://en.wikipedia.org/wiki/Return-oriented_programming)reST";
9345

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