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_AMDGPUKernelCall[] = R"reST(No documentation.)reST";
76
77	static const char AttrDoc_AMDGPUMaxNumWorkGroups[] = R"reST(This attribute specifies the max number of work groups when the kernel
78	is dispatched.
79
80	Clang supports the
81	``__attribute__((amdgpu_max_num_work_groups(<x>, <y>, <z>)))`` or
82	``[[clang::amdgpu_max_num_work_groups(<x>, <y>, <z>)]]`` attribute for the
83	AMDGPU target. This attribute may be attached to HIP or OpenCL kernel function
84	definitions and is an optimization hint.
85
86	The ``<x>`` parameter specifies the maximum number of work groups in the x dimension.
87	Similarly ``<y>`` and ``<z>`` are for the y and z dimensions respectively.
88	Each of the three values must be greater than 0 when provided. The ``<x>`` parameter
89	is required, while ``<y>`` and ``<z>`` are optional with default value of 1.
90
91	If specified, the AMDGPU target backend might be able to produce better machine
92	code.
93
94	An error will be given if:
95	- Specified values violate subtarget specifications;
96	- Specified values are not compatible with values provided through other
97	attributes.)reST";
98
99	static const char AttrDoc_AMDGPUNumSGPR[] = R"reST(Clang supports the ``__attribute__((amdgpu_num_sgpr(<num_sgpr>)))`` and
100	``__attribute__((amdgpu_num_vgpr(<num_vgpr>)))`` attributes for the AMDGPU
101	target. These attributes may be attached to a kernel function definition and are
102	an optimization hint.
103
104	If these attributes are specified, then the AMDGPU target backend will attempt
105	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
106	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
107	allocation requirements or constraints of the subtarget. Passing ``0`` as
108	``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits).
109
110	These attributes can be used to test the AMDGPU target backend. It is
111	recommended that the ``amdgpu_waves_per_eu`` attribute be used to control
112	resources such as SGPRs and VGPRs since it is aware of the limits for different
113	subtargets.
114
115	An error will be given if:
116	- Specified values violate subtarget specifications;
117	- Specified values are not compatible with values provided through other
118	attributes;
119	- The AMDGPU target backend is unable to create machine code that can meet the
120	request.)reST";
121
122	static const char AttrDoc_AMDGPUNumVGPR[] = R"reST(Clang supports the ``__attribute__((amdgpu_num_sgpr(<num_sgpr>)))`` and
123	``__attribute__((amdgpu_num_vgpr(<num_vgpr>)))`` attributes for the AMDGPU
124	target. These attributes may be attached to a kernel function definition and are
125	an optimization hint.
126
127	If these attributes are specified, then the AMDGPU target backend will attempt
128	to limit the number of SGPRs and/or VGPRs used to the specified value(s). The
129	number of used SGPRs and/or VGPRs may further be rounded up to satisfy the
130	allocation requirements or constraints of the subtarget. Passing ``0`` as
131	``num_sgpr`` and/or ``num_vgpr`` implies the default behavior (no limits).
132
133	These attributes can be used to test the AMDGPU target backend. It is
134	recommended that the ``amdgpu_waves_per_eu`` attribute be used to control
135	resources such as SGPRs and VGPRs since it is aware of the limits for different
136	subtargets.
137
138	An error will be given if:
139	- Specified values violate subtarget specifications;
140	- Specified values are not compatible with values provided through other
141	attributes;
142	- The AMDGPU target backend is unable to create machine code that can meet the
143	request.)reST";
144
145	static const char AttrDoc_AMDGPUWavesPerEU[] = R"reST(A compute unit (CU) is responsible for executing the wavefronts of a work-group.
146	It is composed of one or more execution units (EU), which are responsible for
147	executing the wavefronts. An EU can have enough resources to maintain the state
148	of more than one executing wavefront. This allows an EU to hide latency by
149	switching between wavefronts in a similar way to symmetric multithreading on a
150	CPU. In order to allow the state for multiple wavefronts to fit on an EU, the
151	resources used by a single wavefront have to be limited. For example, the number
152	of SGPRs and VGPRs. Limiting such resources can allow greater latency hiding,
153	but can result in having to spill some register state to memory.
154
155	Clang supports the ``__attribute__((amdgpu_waves_per_eu(<min>[, <max>])))``
156	attribute for the AMDGPU target. This attribute may be attached to a kernel
157	function definition and is an optimization hint.
158
159	``<min>`` parameter specifies the requested minimum number of waves per EU, and
160	optional ``<max>`` parameter specifies the requested maximum number of waves
161	per EU (must be greater than ``<min>`` if specified). If ``<max>`` is omitted,
162	then there is no restriction on the maximum number of waves per EU other than
163	the one dictated by the hardware for which the kernel is compiled. Passing
164	``0, 0`` as ``<min>, <max>`` implies the default behavior (no limits).
165
166	If specified, this attribute allows an advanced developer to tune the number of
167	wavefronts that are capable of fitting within the resources of an EU. The AMDGPU
168	target backend can use this information to limit resources, such as number of
169	SGPRs, number of VGPRs, size of available group and private memory segments, in
170	such a way that guarantees that at least ``<min>`` wavefronts and at most
171	``<max>`` wavefronts are able to fit within the resources of an EU. Requesting
172	more wavefronts can hide memory latency but limits available registers which
173	can result in spilling. Requesting fewer wavefronts can help reduce cache
174	thrashing, but can reduce memory latency hiding.
175
176	This attribute controls the machine code generated by the AMDGPU target backend
177	to ensure it is capable of meeting the requested values. However, when the
178	kernel is executed, there may be other reasons that prevent meeting the request,
179	for example, there may be wavefronts from other kernels executing on the EU.
180
181	An error will be given if:
182	- Specified values violate subtarget specifications;
183	- Specified values are not compatible with values provided through other
184	attributes;
185
186	The AMDGPU target backend will emit a warning whenever it is unable to
187	create machine code that meets the request.)reST";
188
189	static const char AttrDoc_ARMInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt("TYPE")))`` attribute on
190	ARM targets. This attribute may be attached to a function definition and
191	instructs the backend to generate appropriate function entry/exit code so that
192	it can be used directly as an interrupt service routine.
193
194	The parameter passed to the interrupt attribute is optional, but if
195	provided it must be a string literal with one of the following values: "IRQ",
196	"FIQ", "SWI", "ABORT", "UNDEF".
197
198	The semantics are as follows:
199
200	- If the function is AAPCS, Clang instructs the backend to realign the stack to
201	8 bytes on entry. This is a general requirement of the AAPCS at public
202	interfaces, but may not hold when an exception is taken. Doing this allows
203	other AAPCS functions to be called.
204	- If the CPU is M-class this is all that needs to be done since the architecture
205	itself is designed in such a way that functions obeying the normal AAPCS ABI
206	constraints are valid exception handlers.
207	- If the CPU is not M-class, the prologue and epilogue are modified to save all
208	non-banked registers that are used, so that upon return the user-mode state
209	will not be corrupted. Note that to avoid unnecessary overhead, only
210	general-purpose (integer) registers are saved in this way. If VFP operations
211	are needed, that state must be saved manually.
212
213	Specifically, interrupt kinds other than "FIQ" will save all core registers
214	except "lr" and "sp". "FIQ" interrupts will save r0-r7.
215	- If the CPU is not M-class, the return instruction is changed to one of the
216	canonical sequences permitted by the architecture for exception return. Where
217	possible the function itself will make the necessary "lr" adjustments so that
218	the "preferred return address" is selected.
219
220	Unfortunately the compiler is unable to make this guarantee for an "UNDEF"
221	handler, where the offset from "lr" to the preferred return address depends on
222	the execution state of the code which generated the exception. In this case
223	a sequence equivalent to "movs pc, lr" will be used.)reST";
224
225	static const char AttrDoc_AVRInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on
226	AVR targets. This attribute may be attached to a function definition and instructs
227	the backend to generate appropriate function entry/exit code so that it can be used
228	directly as an interrupt service routine.
229
230	On the AVR, the hardware globally disables interrupts when an interrupt is executed.
231	The first instruction of an interrupt handler declared with this attribute is a SEI
232	instruction to re-enable interrupts. See also the signal attribute that
233	does not insert a SEI instruction.)reST";
234
235	static const char AttrDoc_AVRSignal[] = R"reST(Clang supports the GNU style ``__attribute__((signal))`` attribute on
236	AVR targets. This attribute may be attached to a function definition and instructs
237	the backend to generate appropriate function entry/exit code so that it can be used
238	directly as an interrupt service routine.
239
240	Interrupt handler functions defined with the signal attribute do not re-enable interrupts.)reST";
241
242	static const char AttrDoc_AbiTag[] = R"reST(The ``abi_tag`` attribute can be applied to a function, variable, class or
243	inline namespace declaration to modify the mangled name of the entity. It gives
244	the ability to distinguish between different versions of the same entity but
245	with different ABI versions supported. For example, a newer version of a class
246	could have a different set of data members and thus have a different size. Using
247	the ``abi_tag`` attribute, it is possible to have different mangled names for
248	a global variable of the class type. Therefore, the old code could keep using
249	the old mangled name and the new code will use the new mangled name with tags.)reST";
250
251	static const char AttrDoc_AcquireCapability[] = R"reST(Marks a function as acquiring a capability.)reST";
252
253	static const char AttrDoc_AcquireHandle[] = R"reST(If this annotation is on a function or a function type it is assumed to return
254	a new handle. In case this annotation is on an output parameter,
255	the function is assumed to fill the corresponding argument with a new
256	handle. The attribute requires a string literal argument which used to
257	identify the handle with later uses of ``use_handle`` or
258	``release_handle``.
259
260	.. code-block:: c++
261
262	// Output arguments from Zircon.
263	zx_status_t zx_socket_create(uint32_t options,
264	zx_handle_t __attribute__((acquire_handle("zircon"))) * out0,
265	zx_handle_t* out1 [[clang::acquire_handle("zircon")]]);
266
267
268	// Returned handle.
269	[[clang::acquire_handle("tag")]] int open(const char *path, int oflag, ... );
270	int open(const char *path, int oflag, ... ) __attribute__((acquire_handle("tag")));)reST";
271
272	static const char AttrDoc_AcquiredAfter[] = R"reST(No documentation.)reST";
273
274	static const char AttrDoc_AcquiredBefore[] = R"reST(No documentation.)reST";
275
276	static const char AttrDoc_AddressSpace[] = R"reST(No documentation.)reST";
277
278	static const char AttrDoc_Alias[] = R"reST(No documentation.)reST";
279
280	static const char AttrDoc_AlignMac68k[] = R"reST()reST";
281
282	static const char AttrDoc_AlignNatural[] = R"reST()reST";
283
284	static const char AttrDoc_AlignValue[] = R"reST(The align_value attribute can be added to the typedef of a pointer type or the
285	declaration of a variable of pointer or reference type. It specifies that the
286	pointer will point to, or the reference will bind to, only objects with at
287	least the provided alignment. This alignment value must be some positive power
288	of 2.
289
290	.. code-block:: c
291
292	typedef double * aligned_double_ptr __attribute__((align_value(64)));
293	void foo(double & x __attribute__((align_value(128)),
294	aligned_double_ptr y) { ... }
295
296	If the pointer value does not have the specified alignment at runtime, the
297	behavior of the program is undefined.)reST";
298
299	static const char AttrDoc_Aligned[] = R"reST(No documentation.)reST";
300
301	static const char AttrDoc_AllocAlign[] = R"reST(Use ``__attribute__((alloc_align(<alignment>))`` on a function
302	declaration to specify that the return value of the function (which must be a
303	pointer type) is at least as aligned as the value of the indicated parameter. The
304	parameter is given by its index in the list of formal parameters; the first
305	parameter has index 1 unless the function is a C++ non-static member function,
306	in which case the first parameter has index 2 to account for the implicit ``this``
307	parameter.
308
309	.. code-block:: c++
310
311	// The returned pointer has the alignment specified by the first parameter.
312	void *a(size_t align) __attribute__((alloc_align(1)));
313
314	// The returned pointer has the alignment specified by the second parameter.
315	void b(void v, size_t align) __attribute__((alloc_align(2)));
316
317	// The returned pointer has the alignment specified by the second visible
318	// parameter, however it must be adjusted for the implicit 'this' parameter.
319	void Foo::b(void v, size_t align) __attribute__((alloc_align(3)));
320
321	Note that this attribute merely informs the compiler that a function always
322	returns a sufficiently aligned pointer. It does not cause the compiler to
323	emit code to enforce that alignment. The behavior is undefined if the returned
324	pointer is not sufficiently aligned.)reST";
325
326	static const char AttrDoc_AllocSize[] = R"reST(The ``alloc_size`` attribute can be placed on functions that return pointers in
327	order to hint to the compiler how many bytes of memory will be available at the
328	returned pointer. ``alloc_size`` takes one or two arguments.
329
330	- ``alloc_size(N)`` implies that argument number N equals the number of
331	available bytes at the returned pointer.
332	- ``alloc_size(N, M)`` implies that the product of argument number N and
333	argument number M equals the number of available bytes at the returned
334	pointer.
335
336	Argument numbers are 1-based.
337
338	An example of how to use ``alloc_size``
339
340	.. code-block:: c
341
342	void *my_malloc(int a) __attribute__((alloc_size(1)));
343	void *my_calloc(int a, int b) __attribute__((alloc_size(1, 2)));
344
345	int main() {
346	void *const p = my_malloc(100);
347	assert(__builtin_object_size(p, 0) == 100);
348	void *const a = my_calloc(20, 5);
349	assert(__builtin_object_size(a, 0) == 100);
350	}
351
352	.. Note:: This attribute works differently in clang than it does in GCC.
353	Specifically, clang will only trace ``const`` pointers (as above); we give up
354	on pointers that are not marked as ``const``. In the vast majority of cases,
355	this is unimportant, because LLVM has support for the ``alloc_size``
356	attribute. However, this may cause mildly unintuitive behavior when used with
357	other attributes, such as ``enable_if``.)reST";
358
359	static const char AttrDoc_Allocating[] = R"reST(Declares that a function potentially allocates heap memory, and prevents any potential inference
360	of ``nonallocating`` by the compiler.)reST";
361
362	static const char AttrDoc_AlwaysDestroy[] = R"reST(The ``always_destroy`` attribute specifies that a variable with static or thread
363	storage duration should have its exit-time destructor run. This attribute is the
364	default unless clang was invoked with -fno-c++-static-destructors.
365
366	If a variable is explicitly declared with this attribute, Clang will silence
367	otherwise applicable ``-Wexit-time-destructors`` warnings.)reST";
368
369	static const char AttrDoc_AlwaysInline[] = R"reST(Inlining heuristics are disabled and inlining is always attempted regardless of
370	optimization level.
371
372	``[[clang::always_inline]]`` spelling can be used as a statement attribute; other
373	spellings of the attribute are not supported on statements. If a statement is
374	marked ``[[clang::always_inline]]`` and contains calls, the compiler attempts
375	to inline those calls.
376
377	.. code-block:: c
378
379	int example(void) {
380	int i;
381	[[clang::always_inline]] foo(); // attempts to inline foo
382	[[clang::always_inline]] i = bar(); // attempts to inline bar
383	[[clang::always_inline]] return f(42, baz(bar())); // attempts to inline everything
384	}
385
386	A declaration statement, which is a statement, is not a statement that can have an
387	attribute associated with it (the attribute applies to the declaration, not the
388	statement in that case). So this use case will not work:
389
390	.. code-block:: c
391
392	int example(void) {
393	[[clang::always_inline]] int i = bar();
394	return i;
395	}
396
397	This attribute does not guarantee that inline substitution actually occurs.
398
399	<ins>Note: applying this attribute to a coroutine at the `-O0` optimization level
400	has no effect; other optimization levels may only partially inline and result in a
401	diagnostic.</ins>
402
403	See also `the Microsoft Docs on Inline Functions`_, `the GCC Common Function
404	Attribute docs`_, and `the GCC Inline docs`_.
405
406	.. _the Microsoft Docs on Inline Functions: https://docs.microsoft.com/en-us/cpp/cpp/inline-functions-cpp
407	.. _the GCC Common Function Attribute docs: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
408	.. _the GCC Inline docs: https://gcc.gnu.org/onlinedocs/gcc/Inline.html)reST";
409
410	static const char AttrDoc_AnalyzerNoReturn[] = R"reST(No documentation.)reST";
411
412	static const char AttrDoc_Annotate[] = R"reST(No documentation.)reST";
413
414	static const char AttrDoc_AnnotateType[] = R"reST(This attribute is used to add annotations to types, typically for use by static
415	analysis tools that are not integrated into the core Clang compiler (e.g.,
416	Clang-Tidy checks or out-of-tree Clang-based tools). It is a counterpart to the
417	`annotate` attribute, which serves the same purpose, but for declarations.
418
419	The attribute takes a mandatory string literal argument specifying the
420	annotation category and an arbitrary number of optional arguments that provide
421	additional information specific to the annotation category. The optional
422	arguments must be constant expressions of arbitrary type.
423
424	For example:
425
426	.. code-block:: c++
427
428	int* [[clang::annotate_type("category1", "foo", 1)]] f(int[[clang::annotate_type("category2")]] *);
429
430	The attribute does not have any effect on the semantics of the type system,
431	neither type checking rules, nor runtime semantics. In particular:
432
433	- ``std::is_same<T, T [[clang::annotate_type("foo")]]>`` is true for all types
434	``T``.
435
436	- It is not permissible for overloaded functions or template specializations
437	to differ merely by an ``annotate_type`` attribute.
438
439	- The presence of an ``annotate_type`` attribute will not affect name
440	mangling.)reST";
441
442	static const char AttrDoc_AnyX86Interrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on X86
443	targets. This attribute may be attached to a function definition and instructs
444	the backend to generate appropriate function entry/exit code so that it can be
445	used directly as an interrupt service routine.
446
447	Interrupt handlers have access to the stack frame pushed onto the stack by the processor,
448	and return using the ``IRET`` instruction. All registers in an interrupt handler are callee-saved.
449	Exception handlers also have access to the error code pushed onto the stack by the processor,
450	when applicable.
451
452	An interrupt handler must take the following arguments:
453
454	.. code-block:: c
455
456	__attribute__ ((interrupt))
457	void f (struct stack_frame *frame) {
458	...
459	}
460
461	Where ``struct stack_frame`` is a suitable struct matching the stack frame pushed by the
462	processor.
463
464	An exception handler must take the following arguments:
465
466	.. code-block:: c
467
468	__attribute__ ((interrupt))
469	void g (struct stack_frame *frame, unsigned long code) {
470	...
471	}
472
473	On 32-bit targets, the ``code`` argument should be of type ``unsigned int``.
474
475	Exception handlers should only be used when an error code is pushed by the processor.
476	Using the incorrect handler type will crash the system.
477
478	Interrupt and exception handlers cannot be called by other functions and must have return type ``void``.
479
480	Interrupt and exception handlers should only call functions with the 'no_caller_saved_registers'
481	attribute, or should be compiled with the '-mgeneral-regs-only' flag to avoid saving unused
482	non-GPR registers.)reST";
483
484	static const char AttrDoc_AnyX86NoCallerSavedRegisters[] = R"reST(Use this attribute to indicate that the specified function has no
485	caller-saved registers. That is, all registers are callee-saved except for
486	registers used for passing parameters to the function or returning parameters
487	from the function.
488	The compiler saves and restores any modified registers that were not used for
489	passing or returning arguments to the function.
490
491	The user can call functions specified with the 'no_caller_saved_registers'
492	attribute from an interrupt handler without saving and restoring all
493	call-clobbered registers.
494
495	Functions specified with the 'no_caller_saved_registers' attribute should only
496	call other functions with the 'no_caller_saved_registers' attribute, or should be
497	compiled with the '-mgeneral-regs-only' flag to avoid saving unused non-GPR registers.
498
499	Note that 'no_caller_saved_registers' attribute is not a calling convention.
500	In fact, it only overrides the decision of which registers should be saved by
501	the caller, but not how the parameters are passed from the caller to the callee.
502
503	For example:
504
505	.. code-block:: c
506
507	__attribute__ ((no_caller_saved_registers, fastcall))
508	void f (int arg1, int arg2) {
509	...
510	}
511
512	In this case parameters 'arg1' and 'arg2' will be passed in registers.
513	In this case, on 32-bit x86 targets, the function 'f' will use ECX and EDX as
514	register parameters. However, it will not assume any scratch registers and
515	should save and restore any modified registers except for ECX and EDX.)reST";
516
517	static const char AttrDoc_AnyX86NoCfCheck[] = R"reST(Jump Oriented Programming attacks rely on tampering with addresses used by
518	indirect call / jmp, e.g. redirect control-flow to non-programmer
519	intended bytes in the binary.
520	X86 Supports Indirect Branch Tracking (IBT) as part of Control-Flow
521	Enforcement Technology (CET). IBT instruments ENDBR instructions used to
522	specify valid targets of indirect call / jmp.
523	The ``nocf_check`` attribute has two roles:
524	1. Appertains to a function - do not add ENDBR instruction at the beginning of
525	the function.
526	2. Appertains to a function pointer - do not track the target function of this
527	pointer (by adding nocf_check prefix to the indirect-call instruction).)reST";
528
529	static const char AttrDoc_ArcWeakrefUnavailable[] = R"reST(No documentation.)reST";
530
531	static const char AttrDoc_ArgumentWithTypeTag[] = R"reST(Use ``__attribute__((argument_with_type_tag(arg_kind, arg_idx,
532	type_tag_idx)))`` on a function declaration to specify that the function
533	accepts a type tag that determines the type of some other argument.
534
535	This attribute is primarily useful for checking arguments of variadic functions
536	(``pointer_with_type_tag`` can be used in most non-variadic cases).
537
538	In the attribute prototype above:
539	* ``arg_kind`` is an identifier that should be used when annotating all
540	applicable type tags.
541	* ``arg_idx`` provides the position of a function argument. The expected type of
542	this function argument will be determined by the function argument specified
543	by ``type_tag_idx``. In the code example below, "3" means that the type of the
544	function's third argument will be determined by ``type_tag_idx``.
545	* ``type_tag_idx`` provides the position of a function argument. This function
546	argument will be a type tag. The type tag will determine the expected type of
547	the argument specified by ``arg_idx``. In the code example below, "2" means
548	that the type tag associated with the function's second argument should agree
549	with the type of the argument specified by ``arg_idx``.
550
551	For example:
552
553	.. code-block:: c++
554
555	int fcntl(int fd, int cmd, ...)
556	__attribute__(( argument_with_type_tag(fcntl,3,2) ));
557	// The function's second argument will be a type tag; this type tag will
558	// determine the expected type of the function's third argument.)reST";
559
560	static const char AttrDoc_ArmBuiltinAlias[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics.
561	It allows the intrinsic functions to
562	be declared using the names defined in ACLE, and still be recognized
563	as clang builtins equivalent to the underlying name. For example,
564	``arm_mve.h`` declares the function ``vaddq_u32`` with
565	``__attribute__((__clang_arm_mve_alias(__builtin_arm_mve_vaddq_u32)))``,
566	and similarly, one of the type-overloaded declarations of ``vaddq``
567	will have the same attribute. This ensures that both functions are
568	recognized as that clang builtin, and in the latter case, the choice
569	of which builtin to identify the function as can be deferred until
570	after overload resolution.
571
572	This attribute can only be used to set up the aliases for certain Arm
573	intrinsic functions; it is intended for use only inside ``arm_*.h``
574	and is not a general mechanism for declaring arbitrary aliases for
575	clang builtin functions.
576
577	In order to avoid duplicating the attribute definitions for similar
578	purpose for other architecture, there is a general form for the
579	attribute `clang_builtin_alias`.)reST";
580
581	static const char AttrDoc_ArmIn[] = R"reST(The ``__arm_in`` keyword applies to prototyped function types and specifies
582	that the function shares a given state S with its caller. For ``__arm_in``, the
583	function takes the state S as input and returns with the state S unchanged.
584
585	The attribute takes string arguments to instruct the compiler which state
586	is shared. The supported states for S are:
587
588	* ``"za"`` for Matrix Storage (requires SME)
589
590	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
591	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
592
593	static const char AttrDoc_ArmInOut[] = R"reST(The ``__arm_inout`` keyword applies to prototyped function types and specifies
594	that the function shares a given state S with its caller. For ``__arm_inout``,
595	the function takes the state S as input and returns new state for S.
596
597	The attribute takes string arguments to instruct the compiler which state
598	is shared. The supported states for S are:
599
600	* ``"za"`` for Matrix Storage (requires SME)
601
602	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
603	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
604
605	static const char AttrDoc_ArmLocallyStreaming[] = R"reST(The ``__arm_locally_streaming`` keyword applies to function declarations
606	and specifies that all the statements in the function are executed in
607	streaming mode. This means that:
608
609	* the function requires that the target processor implements the Scalable Matrix
610	Extension (SME).
611
612	* the program automatically puts the machine into streaming mode before
613	executing the statements and automatically restores the previous mode
614	afterwards.
615
616	Clang manages PSTATE.SM automatically; it is not the source code's
617	responsibility to do this. For example, Clang will emit code to enable
618	streaming mode at the start of the function, and disable streaming mode
619	at the end of the function.)reST";
620
621	static const char AttrDoc_ArmMveStrictPolymorphism[] = R"reST(This attribute is used in the implementation of the ACLE intrinsics for the Arm
622	MVE instruction set. It is used to define the vector types used by the MVE
623	intrinsics.
624
625	Its effect is to modify the behavior of a vector type with respect to function
626	overloading. If a candidate function for overload resolution has a parameter
627	type with this attribute, then the selection of that candidate function will be
628	disallowed if the actual argument can only be converted via a lax vector
629	conversion. The aim is to prevent spurious ambiguity in ARM MVE polymorphic
630	intrinsics.
631
632	.. code-block:: c++
633
634	void overloaded(uint16x8_t vector, uint16_t scalar);
635	void overloaded(int32x4_t vector, int32_t scalar);
636	uint16x8_t myVector;
637	uint16_t myScalar;
638
639	// myScalar is promoted to int32_t as a side effect of the addition,
640	// so if lax vector conversions are considered for myVector, then
641	// the two overloads are equally good (one argument conversion
642	// each). But if the vector has the __clang_arm_mve_strict_polymorphism
643	// attribute, only the uint16x8_t,uint16_t overload will match.
644	overloaded(myVector, myScalar + 1);
645
646	However, this attribute does not prohibit lax vector conversions in contexts
647	other than overloading.
648
649	.. code-block:: c++
650
651	uint16x8_t function();
652
653	// This is still permitted with lax vector conversion enabled, even
654	// if the vector types have __clang_arm_mve_strict_polymorphism
655	int32x4_t result = function();)reST";
656
657	static const char AttrDoc_ArmNew[] = R"reST(The ``__arm_new`` keyword applies to function declarations and specifies
658	that the function will create a new scope for state S.
659
660	The attribute takes string arguments to instruct the compiler for which state
661	to create new scope. The supported states for S are:
662
663	* ``"za"`` for Matrix Storage (requires SME)
664
665	For state ``"za"``, this means that:
666
667	* the function requires that the target processor implements the Scalable Matrix
668	Extension (SME).
669
670	* the function will commit any lazily saved ZA data.
671
672	* the function will create a new ZA context and enable PSTATE.ZA.
673
674	* the function will disable PSTATE.ZA (by setting it to 0) before returning.
675
676	For ``__arm_new("za")`` functions Clang will set up the ZA context automatically
677	on entry to the function and disable it before returning. For example, if ZA is
678	in a dormant state Clang will generate the code to commit a lazy-save and set up
679	a new ZA state before executing user code.)reST";
680
681	static const char AttrDoc_ArmOut[] = R"reST(The ``__arm_out`` keyword applies to prototyped function types and specifies
682	that the function shares a given state S with its caller. For ``__arm_out``,
683	the function ignores the incoming state for S and returns new state for S.
684
685	The attribute takes string arguments to instruct the compiler which state
686	is shared. The supported states for S are:
687
688	* ``"za"`` for Matrix Storage (requires SME)
689
690	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
691	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
692
693	static const char AttrDoc_ArmPreserves[] = R"reST(The ``__arm_preserves`` keyword applies to prototyped function types and
694	specifies that the function does not read a given state S and returns
695	with state S unchanged.
696
697	The attribute takes string arguments to instruct the compiler which state
698	is shared. The supported states for S are:
699
700	* ``"za"`` for Matrix Storage (requires SME)
701
702	The attributes ``__arm_in(S)``, ``__arm_out(S)``, ``__arm_inout(S)`` and
703	``__arm_preserves(S)`` are all mutually exclusive for the same state S.)reST";
704
705	static const char AttrDoc_ArmStreaming[] = R"reST(The ``__arm_streaming`` keyword applies to prototyped function types and specifies
706	that the function has a "streaming interface". This means that:
707
708	* the function requires that the processor implements the Scalable Matrix
709	Extension (SME).
710
711	* the function must be entered in streaming mode (that is, with PSTATE.SM
712	set to 1)
713
714	* the function must return in streaming mode
715
716	Clang manages PSTATE.SM automatically; it is not the source code's
717	responsibility to do this. For example, if a non-streaming
718	function calls an ``__arm_streaming`` function, Clang generates code
719	that switches into streaming mode before calling the function and
720	switches back to non-streaming mode on return.)reST";
721
722	static const char AttrDoc_ArmStreamingCompatible[] = R"reST(The ``__arm_streaming_compatible`` keyword applies to prototyped function types and
723	specifies that the function has a "streaming compatible interface". This
724	means that:
725
726	* the function may be entered in either non-streaming mode (PSTATE.SM=0) or
727	in streaming mode (PSTATE.SM=1).
728
729	* the function must return in the same mode as it was entered.
730
731	* the code executed in the function is compatible with either mode.
732
733	Clang manages PSTATE.SM automatically; it is not the source code's
734	responsibility to do this. Clang will ensure that the generated code in
735	streaming-compatible functions is valid in either mode (PSTATE.SM=0 or
736	PSTATE.SM=1). For example, if an ``__arm_streaming_compatible`` function calls a
737	non-streaming function, Clang generates code to temporarily switch out of streaming
738	mode before calling the function and switch back to streaming-mode on return if
739	``PSTATE.SM`` is ``1`` on entry of the caller. If ``PSTATE.SM`` is ``0`` on
740	entry to the ``__arm_streaming_compatible`` function, the call will be executed
741	without changing modes.)reST";
742
743	static const char AttrDoc_Artificial[] = R"reST(The ``artificial`` attribute can be applied to an inline function. If such a
744	function is inlined, the attribute indicates that debuggers should associate
745	the resulting instructions with the call site, rather than with the
746	corresponding line within the inlined callee.)reST";
747
748	static const char AttrDoc_AsmLabel[] = R"reST(This attribute can be used on a function or variable to specify its symbol name.
749
750	On some targets, all C symbols are prefixed by default with a single character,
751	typically ``_``. This was done historically to distinguish them from symbols
752	used by other languages. (This prefix is also added to the standard Itanium
753	C++ ABI prefix on "mangled" symbol names, so that e.g. on such targets the true
754	symbol name for a C++ variable declared as ``int cppvar;`` would be
755	``__Z6cppvar``; note the two underscores.) This prefix is not added to the
756	symbol names specified by the ``asm`` attribute; programmers wishing to match a
757	C symbol name must compensate for this.
758
759	For example, consider the following C code:
760
761	.. code-block:: c
762
763	int var1 asm("altvar") = 1; // "altvar" in symbol table.
764	int var2 = 1; // "_var2" in symbol table.
765
766	void func1(void) asm("altfunc");
767	void func1(void) {} // "altfunc" in symbol table.
768	void func2(void) {} // "_func2" in symbol table.
769
770	Clang's implementation of this attribute is compatible with GCC's, `documented here <https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html>`_.
771
772	While it is possible to use this attribute to name a special symbol used
773	internally by the compiler, such as an LLVM intrinsic, this is neither
774	recommended nor supported and may cause the compiler to crash or miscompile.
775	Users who wish to gain access to intrinsic behavior are strongly encouraged to
776	request new builtin functions.)reST";
777
778	static const char AttrDoc_AssertCapability[] = R"reST(Marks a function that dynamically tests whether a capability is held, and halts
779	the program if it is not held.)reST";
780
781	static const char AttrDoc_AssertExclusiveLock[] = R"reST(No documentation.)reST";
782
783	static const char AttrDoc_AssertSharedLock[] = R"reST(No documentation.)reST";
784
785	static const char AttrDoc_AssumeAligned[] = R"reST(Use ``__attribute__((assume_aligned(<alignment>[,<offset>]))`` on a function
786	declaration to specify that the return value of the function (which must be a
787	pointer type) has the specified offset, in bytes, from an address with the
788	specified alignment. The offset is taken to be zero if omitted.
789
790	.. code-block:: c++
791
792	// The returned pointer value has 32-byte alignment.
793	void *a() __attribute__((assume_aligned (32)));
794
795	// The returned pointer value is 4 bytes greater than an address having
796	// 32-byte alignment.
797	void *b() __attribute__((assume_aligned (32, 4)));
798
799	Note that this attribute provides information to the compiler regarding a
800	condition that the code already ensures is true. It does not cause the compiler
801	to enforce the provided alignment assumption.)reST";
802
803	static const char AttrDoc_Availability[] = R"reST(The ``availability`` attribute can be placed on declarations to describe the
804	lifecycle of that declaration relative to operating system versions. Consider
805	the function declaration for a hypothetical function ``f``:
806
807	.. code-block:: c++
808
809	void f(void) __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
810
811	The availability attribute states that ``f`` was introduced in macOS 10.4,
812	deprecated in macOS 10.6, and obsoleted in macOS 10.7. This information
813	is used by Clang to determine when it is safe to use ``f``: for example, if
814	Clang is instructed to compile code for macOS 10.5, a call to ``f()``
815	succeeds. If Clang is instructed to compile code for macOS 10.6, the call
816	succeeds but Clang emits a warning specifying that the function is deprecated.
817	Finally, if Clang is instructed to compile code for macOS 10.7, the call
818	fails because ``f()`` is no longer available.
819
820	The availability attribute is a comma-separated list starting with the
821	platform name and then including clauses specifying important milestones in the
822	declaration's lifetime (in any order) along with additional information. Those
823	clauses can be:
824
825	introduced=\ version
826	The first version in which this declaration was introduced.
827
828	deprecated=\ version
829	The first version in which this declaration was deprecated, meaning that
830	users should migrate away from this API.
831
832	obsoleted=\ version
833	The first version in which this declaration was obsoleted, meaning that it
834	was removed completely and can no longer be used.
835
836	unavailable
837	This declaration is never available on this platform.
838
839	message=\ string-literal
840	Additional message text that Clang will provide when emitting a warning or
841	error about use of a deprecated or obsoleted declaration. Useful to direct
842	users to replacement APIs.
843
844	replacement=\ string-literal
845	Additional message text that Clang will use to provide Fix-It when emitting
846	a warning about use of a deprecated declaration. The Fix-It will replace
847	the deprecated declaration with the new declaration specified.
848
849	environment=\ identifier
850	Target environment in which this declaration is available. If present,
851	the availability attribute applies only to targets with the same platform
852	and environment. The parameter is currently supported only in HLSL.
853
854	Multiple availability attributes can be placed on a declaration, which may
855	correspond to different platforms. For most platforms, the availability
856	attribute with the platform corresponding to the target platform will be used;
857	any others will be ignored. However, the availability for ``watchOS`` and
858	``tvOS`` can be implicitly inferred from an ``iOS`` availability attribute.
859	Any explicit availability attributes for those platforms are still preferred over
860	the implicitly inferred availability attributes. If no availability attribute
861	specifies availability for the current target platform, the availability
862	attributes are ignored. Supported platforms are:
863
864	``ios``
865	Apple's iOS operating system. The minimum deployment target is specified
866	as part of the ``-target arch-apple-iosversion`` command line argument.
867	Alternatively, it can be specified by the ``-mtargetos=iosversion``
868	command-line argument.
869
870	``macos``
871	Apple's macOS operating system. The minimum deployment target is specified
872	as part of the ``-target arch-apple-macosversion`` command line argument.
873	Alternatively, it can be specified by the ``-mtargetos=macosversion``
874	command-line argument. ``macosx`` is supported for
875	backward-compatibility reasons, but it is deprecated.
876
877	``tvos``
878	Apple's tvOS operating system. The minimum deployment target is specified
879	as part of the ``-target arch-apple-tvosversion`` command line argument.
880	Alternatively, it can be specified by the ``-mtargetos=tvosversion``
881	command-line argument.
882
883	``watchos``
884	Apple's watchOS operating system. The minimum deployment target is specified
885	as part of the ``-target arch-apple-watchosversion`` command line argument.
886	Alternatively, it can be specified by the ``-mtargetos=watchosversion``
887	command-line argument.
888
889	``visionos``
890	Apple's visionOS operating system. The minimum deployment target is specified
891	as part of the ``-target arch-apple-visionosversion`` command line argument.
892	Alternatively, it can be specified by the ``-mtargetos=visionosversion``
893	command-line argument.
894
895	``driverkit``
896	Apple's DriverKit userspace kernel extensions. The minimum deployment target
897	is specified as part of the ``-target arch-apple-driverkitversion``
898	command line argument.
899
900	A declaration can typically be used even when deploying back to a platform
901	version prior to when the declaration was introduced. When this happens, the
902	declaration is `weakly linked
903	<https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,
904	as if the ``weak_import`` attribute were added to the declaration. A
905	weakly-linked declaration may or may not be present a run-time, and a program
906	can determine whether the declaration is present by checking whether the
907	address of that declaration is non-NULL.
908
909	The flag ``strict`` disallows using API when deploying back to a
910	platform version prior to when the declaration was introduced. An
911	attempt to use such API before its introduction causes a hard error.
912	Weakly-linking is almost always a better API choice, since it allows
913	users to query availability at runtime.
914
915	If there are multiple declarations of the same entity, the availability
916	attributes must either match on a per-platform basis or later
917	declarations must not have availability attributes for that
918	platform. For example:
919
920	.. code-block:: c
921
922	void g(void) __attribute__((availability(macos,introduced=10.4)));
923	void g(void) __attribute__((availability(macos,introduced=10.4))); // okay, matches
924	void g(void) __attribute__((availability(ios,introduced=4.0))); // okay, adds a new platform
925	void g(void); // okay, inherits both macos and ios availability from above.
926	void g(void) __attribute__((availability(macos,introduced=10.5))); // error: mismatch
927
928	When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,:
929
930	.. code-block:: objc
931
932	@interface A
933	- (id)method __attribute__((availability(macos,introduced=10.4)));
934	- (id)method2 __attribute__((availability(macos,introduced=10.4)));
935	@end
936
937	@interface B : A
938	- (id)method __attribute__((availability(macos,introduced=10.3))); // okay: method moved into base class later
939	- (id)method __attribute__((availability(macos,introduced=10.5))); // error: this method was available via the base class in 10.4
940	@end
941
942	Starting with the macOS 10.12 SDK, the ``API_AVAILABLE`` macro from
943	``<os/availability.h>`` can simplify the spelling:
944
945	.. code-block:: objc
946
947	@interface A
948	- (id)method API_AVAILABLE(macos(10.11)));
949	- (id)otherMethod API_AVAILABLE(macos(10.11), ios(11.0));
950	@end
951
952	Availability attributes can also be applied using a ``#pragma clang attribute``.
953	Any explicit availability attribute whose platform corresponds to the target
954	platform is applied to a declaration regardless of the availability attributes
955	specified in the pragma. For example, in the code below,
956	``hasExplicitAvailabilityAttribute`` will use the ``macOS`` availability
957	attribute that is specified with the declaration, whereas
958	``getsThePragmaAvailabilityAttribute`` will use the ``macOS`` availability
959	attribute that is applied by the pragma.
960
961	.. code-block:: c
962
963	#pragma clang attribute push (__attribute__((availability(macOS, introduced=10.12))), apply_to=function)
964	void getsThePragmaAvailabilityAttribute(void);
965	void hasExplicitAvailabilityAttribute(void) __attribute__((availability(macos,introduced=10.4)));
966	#pragma clang attribute pop
967
968	For platforms like ``watchOS`` and ``tvOS``, whose availability attributes can
969	be implicitly inferred from an ``iOS`` availability attribute, the logic is
970	slightly more complex. The explicit and the pragma-applied availability
971	attributes whose platform corresponds to the target platform are applied as
972	described in the previous paragraph. However, the implicitly inferred attributes
973	are applied to a declaration only when there is no explicit or pragma-applied
974	availability attribute whose platform corresponds to the target platform. For
975	example, the function below will receive the ``tvOS`` availability from the
976	pragma rather than using the inferred ``iOS`` availability from the declaration:
977
978	.. code-block:: c
979
980	#pragma clang attribute push (__attribute__((availability(tvOS, introduced=12.0))), apply_to=function)
981	void getsThePragmaTVOSAvailabilityAttribute(void) __attribute__((availability(iOS,introduced=11.0)));
982	#pragma clang attribute pop
983
984	The compiler is also able to apply implicitly inferred attributes from a pragma
985	as well. For example, when targeting ``tvOS``, the function below will receive
986	a ``tvOS`` availability attribute that is implicitly inferred from the ``iOS``
987	availability attribute applied by the pragma:
988
989	.. code-block:: c
990
991	#pragma clang attribute push (__attribute__((availability(iOS, introduced=12.0))), apply_to=function)
992	void infersTVOSAvailabilityFromPragma(void);
993	#pragma clang attribute pop
994
995	The implicit attributes that are inferred from explicitly specified attributes
996	whose platform corresponds to the target platform are applied to the declaration
997	even if there is an availability attribute that can be inferred from a pragma.
998	For example, the function below will receive the ``tvOS, introduced=11.0``
999	availability that is inferred from the attribute on the declaration rather than
1000	inferring availability from the pragma:
1001
1002	.. code-block:: c
1003
1004	#pragma clang attribute push (__attribute__((availability(iOS, unavailable))), apply_to=function)
1005	void infersTVOSAvailabilityFromAttributeNextToDeclaration(void)
1006	__attribute__((availability(iOS,introduced=11.0)));
1007	#pragma clang attribute pop
1008
1009	Also see the documentation for `@available
1010	<http://clang.llvm.org/docs/LanguageExtensions.html#objective-c-available>`_)reST";
1011
1012	static const char AttrDoc_AvailableOnlyInDefaultEvalMethod[] = R"reST(No documentation.)reST";
1013
1014	static const char AttrDoc_BPFPreserveAccessIndex[] = R"reST(Clang supports the ``__attribute__((preserve_access_index))``
1015	attribute for the BPF target. This attribute may be attached to a
1016	struct or union declaration, where if -g is specified, it enables
1017	preserving struct or union member access debuginfo indices of this
1018	struct or union, similar to clang ``__builtin_preserve_access_index()``.)reST";
1019
1020	static const char AttrDoc_BPFPreserveStaticOffset[] = R"reST(Clang supports the ``__attribute__((preserve_static_offset))``
1021	attribute for the BPF target. This attribute may be attached to a
1022	struct or union declaration. Reading or writing fields of types having
1023	such annotation is guaranteed to generate LDX/ST/STX instruction with
1024	offset corresponding to the field.
1025
1026	For example:
1027
1028	.. code-block:: c
1029
1030	struct foo {
1031	int a;
1032	int b;
1033	};
1034
1035	struct bar {
1036	int a;
1037	struct foo b;
1038	} __attribute__((preserve_static_offset));
1039
1040	void buz(struct bar *g) {
1041	g->b.a = 42;
1042	}
1043
1044	The assignment to ``g``'s field would produce an ST instruction with
1045	offset 8: ``*(u32)(r1 + 8) = 42;``.
1046
1047	Without this attribute generated instructions might be different,
1048	depending on optimizations behavior. E.g. the example above could be
1049	rewritten as ``r1 += 8; *(u32)(r1 + 0) = 42;``.)reST";
1050
1051	static const char AttrDoc_BTFDeclTag[] = R"reST(Clang supports the ``__attribute__((btf_decl_tag("ARGUMENT")))`` attribute for
1052	all targets. This attribute may be attached to a struct/union, struct/union
1053	field, function, function parameter, variable or typedef declaration. If -g is
1054	specified, the ``ARGUMENT`` info will be preserved in IR and be emitted to
1055	dwarf. For BPF targets, the ``ARGUMENT`` info will be emitted to .BTF ELF
1056	section too.)reST";
1057
1058	static const char AttrDoc_BTFTypeTag[] = R"reST(Clang supports the ``__attribute__((btf_type_tag("ARGUMENT")))`` attribute for
1059	all targets. It only has effect when ``-g`` is specified on the command line and
1060	is currently silently ignored when not applied to a pointer type (note: this
1061	scenario may be diagnosed in the future).
1062
1063	The ``ARGUMENT`` string will be preserved in IR and emitted to DWARF for the
1064	types used in variable declarations, function declarations, or typedef
1065	declarations.
1066
1067	For BPF targets, the ``ARGUMENT`` string will also be emitted to .BTF ELF
1068	section.)reST";
1069
1070	static const char AttrDoc_Blocking[] = R"reST(Declares that a function potentially blocks, and prevents any potential inference of ``nonblocking``
1071	by the compiler.)reST";
1072
1073	static const char AttrDoc_Blocks[] = R"reST(No documentation.)reST";
1074
1075	static const char AttrDoc_Builtin[] = R"reST()reST";
1076
1077	static const char AttrDoc_BuiltinAlias[] = R"reST(This attribute is used in the implementation of the C intrinsics.
1078	It allows the C intrinsic functions to be declared using the names defined
1079	in target builtins, and still be recognized as clang builtins equivalent to the
1080	underlying name. For example, ``riscv_vector.h`` declares the function ``vadd``
1081	with ``__attribute__((clang_builtin_alias(__builtin_rvv_vadd_vv_i8m1)))``.
1082	This ensures that both functions are recognized as that clang builtin,
1083	and in the latter case, the choice of which builtin to identify the
1084	function as can be deferred until after overload resolution.
1085
1086	This attribute can only be used to set up the aliases for certain ARM/RISC-V
1087	C intrinsic functions; it is intended for use only inside ``arm_*.h`` and
1088	``riscv_*.h`` and is not a general mechanism for declaring arbitrary aliases
1089	for clang builtin functions.)reST";
1090
1091	static const char AttrDoc_C11NoReturn[] = R"reST(A function declared as ``_Noreturn`` shall not return to its caller. The
1092	compiler will generate a diagnostic for a function declared as ``_Noreturn``
1093	that appears to be capable of returning to its caller. Despite being a type
1094	specifier, the ``_Noreturn`` attribute cannot be specified on a function
1095	pointer type.)reST";
1096
1097	static const char AttrDoc_CDecl[] = R"reST(No documentation.)reST";
1098
1099	static const char AttrDoc_CFAuditedTransfer[] = R"reST(No documentation.)reST";
1100
1101	static const char AttrDoc_CFConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1102	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1103	convention (e.g. functions starting with "get" are assumed to return at
1104	``+0``).
1105
1106	It can be overridden using a family of the following attributes. In
1107	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1108	a function communicates that the object is returned at ``+1``, and the caller
1109	is responsible for freeing it.
1110	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1111	specifies that the object is returned at ``+0`` and the ownership remains with
1112	the callee.
1113	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1114	the Objective-C method call consumes the reference to ``self``, e.g. by
1115	attaching it to a supplied parameter.
1116	Additionally, parameters can have an annotation
1117	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1118	as that parameter effectively transfers the ownership, and the caller is no
1119	longer responsible for it.
1120	These attributes affect code generation when interacting with ARC code, and
1121	they are used by the Clang Static Analyzer.
1122
1123	In C programs using CoreFoundation, a similar set of attributes:
1124	``__attribute__((cf_returns_not_retained))``,
1125	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1126	have the same respective semantics when applied to CoreFoundation objects.
1127	These attributes affect code generation when interacting with ARC code, and
1128	they are used by the Clang Static Analyzer.
1129
1130	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1131	the same attribute family is present:
1132	``__attribute__((os_returns_not_retained))``,
1133	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1134	with the same respective semantics.
1135	Similar to ``__attribute__((ns_consumes_self))``,
1136	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1137	the reference to "this" (e.g., when attaching it to a different object supplied
1138	as a parameter).
1139	Out parameters (parameters the function is meant to write into,
1140	either via pointers-to-pointers or references-to-pointers)
1141	may be annotated with ``__attribute__((os_returns_retained))``
1142	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1143	written into the out parameter should (or respectively should not) be released
1144	after use.
1145	Since often out parameters may or may not be written depending on the exit
1146	code of the function,
1147	annotations ``__attribute__((os_returns_retained_on_zero))``
1148	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1149	an out parameter at ``+1`` is written if and only if the function returns a zero
1150	(respectively non-zero) error code.
1151	Observe that return-code-dependent out parameter annotations are only
1152	available for retained out parameters, as non-retained object do not have to be
1153	released by the callee.
1154	These attributes are only used by the Clang Static Analyzer.
1155
1156	The family of attributes ``X_returns_X_retained`` can be added to functions,
1157	C++ methods, and Objective-C methods and properties.
1158	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1159	and Objective-C methods.)reST";
1160
1161	static const char AttrDoc_CFGuard[] = R"reST(Code can indicate CFG checks are not wanted with the ``__declspec(guard(nocf))``
1162	attribute. This directs the compiler to not insert any CFG checks for the entire
1163	function. This approach is typically used only sparingly in specific situations
1164	where the programmer has manually inserted "CFG-equivalent" protection. The
1165	programmer knows that they are calling through some read-only function table
1166	whose address is obtained through read-only memory references and for which the
1167	index is masked to the function table limit. This approach may also be applied
1168	to small wrapper functions that are not inlined and that do nothing more than
1169	make a call through a function pointer. Since incorrect usage of this directive
1170	can compromise the security of CFG, the programmer must be very careful using
1171	the directive. Typically, this usage is limited to very small functions that
1172	only call one function.
1173
1174	`Control Flow Guard documentation <https://docs.microsoft.com/en-us/windows/win32/secbp/pe-metadata>`)reST";
1175
1176	static const char AttrDoc_CFICanonicalJumpTable[] = R"reST(.. _langext-cfi_canonical_jump_table:
1177
1178	Use ``__attribute__((cfi_canonical_jump_table))`` on a function declaration to
1179	make the function's CFI jump table canonical. See :ref:`the CFI documentation
1180	<cfi-canonical-jump-tables>` for more details.)reST";
1181
1182	static const char AttrDoc_CFReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1183	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1184	convention (e.g. functions starting with "get" are assumed to return at
1185	``+0``).
1186
1187	It can be overridden using a family of the following attributes. In
1188	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1189	a function communicates that the object is returned at ``+1``, and the caller
1190	is responsible for freeing it.
1191	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1192	specifies that the object is returned at ``+0`` and the ownership remains with
1193	the callee.
1194	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1195	the Objective-C method call consumes the reference to ``self``, e.g. by
1196	attaching it to a supplied parameter.
1197	Additionally, parameters can have an annotation
1198	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1199	as that parameter effectively transfers the ownership, and the caller is no
1200	longer responsible for it.
1201	These attributes affect code generation when interacting with ARC code, and
1202	they are used by the Clang Static Analyzer.
1203
1204	In C programs using CoreFoundation, a similar set of attributes:
1205	``__attribute__((cf_returns_not_retained))``,
1206	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1207	have the same respective semantics when applied to CoreFoundation objects.
1208	These attributes affect code generation when interacting with ARC code, and
1209	they are used by the Clang Static Analyzer.
1210
1211	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1212	the same attribute family is present:
1213	``__attribute__((os_returns_not_retained))``,
1214	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1215	with the same respective semantics.
1216	Similar to ``__attribute__((ns_consumes_self))``,
1217	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1218	the reference to "this" (e.g., when attaching it to a different object supplied
1219	as a parameter).
1220	Out parameters (parameters the function is meant to write into,
1221	either via pointers-to-pointers or references-to-pointers)
1222	may be annotated with ``__attribute__((os_returns_retained))``
1223	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1224	written into the out parameter should (or respectively should not) be released
1225	after use.
1226	Since often out parameters may or may not be written depending on the exit
1227	code of the function,
1228	annotations ``__attribute__((os_returns_retained_on_zero))``
1229	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1230	an out parameter at ``+1`` is written if and only if the function returns a zero
1231	(respectively non-zero) error code.
1232	Observe that return-code-dependent out parameter annotations are only
1233	available for retained out parameters, as non-retained object do not have to be
1234	released by the callee.
1235	These attributes are only used by the Clang Static Analyzer.
1236
1237	The family of attributes ``X_returns_X_retained`` can be added to functions,
1238	C++ methods, and Objective-C methods and properties.
1239	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1240	and Objective-C methods.)reST";
1241
1242	static const char AttrDoc_CFReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
1243	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
1244	convention (e.g. functions starting with "get" are assumed to return at
1245	``+0``).
1246
1247	It can be overridden using a family of the following attributes. In
1248	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
1249	a function communicates that the object is returned at ``+1``, and the caller
1250	is responsible for freeing it.
1251	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
1252	specifies that the object is returned at ``+0`` and the ownership remains with
1253	the callee.
1254	The annotation ``__attribute__((ns_consumes_self))`` specifies that
1255	the Objective-C method call consumes the reference to ``self``, e.g. by
1256	attaching it to a supplied parameter.
1257	Additionally, parameters can have an annotation
1258	``__attribute__((ns_consumed))``, which specifies that passing an owned object
1259	as that parameter effectively transfers the ownership, and the caller is no
1260	longer responsible for it.
1261	These attributes affect code generation when interacting with ARC code, and
1262	they are used by the Clang Static Analyzer.
1263
1264	In C programs using CoreFoundation, a similar set of attributes:
1265	``__attribute__((cf_returns_not_retained))``,
1266	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
1267	have the same respective semantics when applied to CoreFoundation objects.
1268	These attributes affect code generation when interacting with ARC code, and
1269	they are used by the Clang Static Analyzer.
1270
1271	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
1272	the same attribute family is present:
1273	``__attribute__((os_returns_not_retained))``,
1274	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
1275	with the same respective semantics.
1276	Similar to ``__attribute__((ns_consumes_self))``,
1277	``__attribute__((os_consumes_this))`` specifies that the method call consumes
1278	the reference to "this" (e.g., when attaching it to a different object supplied
1279	as a parameter).
1280	Out parameters (parameters the function is meant to write into,
1281	either via pointers-to-pointers or references-to-pointers)
1282	may be annotated with ``__attribute__((os_returns_retained))``
1283	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
1284	written into the out parameter should (or respectively should not) be released
1285	after use.
1286	Since often out parameters may or may not be written depending on the exit
1287	code of the function,
1288	annotations ``__attribute__((os_returns_retained_on_zero))``
1289	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
1290	an out parameter at ``+1`` is written if and only if the function returns a zero
1291	(respectively non-zero) error code.
1292	Observe that return-code-dependent out parameter annotations are only
1293	available for retained out parameters, as non-retained object do not have to be
1294	released by the callee.
1295	These attributes are only used by the Clang Static Analyzer.
1296
1297	The family of attributes ``X_returns_X_retained`` can be added to functions,
1298	C++ methods, and Objective-C methods and properties.
1299	Attributes ``X_consumed`` can be added to parameters of methods, functions,
1300	and Objective-C methods.)reST";
1301
1302	static const char AttrDoc_CFUnknownTransfer[] = R"reST(No documentation.)reST";
1303
1304	static const char AttrDoc_CPUDispatch[] = R"reST(The ``cpu_specific`` and ``cpu_dispatch`` attributes are used to define and
1305	resolve multiversioned functions. This form of multiversioning provides a
1306	mechanism for declaring versions across translation units and manually
1307	specifying the resolved function list. A specified CPU defines a set of minimum
1308	features that are required for the function to be called. The result of this is
1309	that future processors execute the most restrictive version of the function the
1310	new processor can execute.
1311
1312	In addition, unlike the ICC implementation of this feature, the selection of the
1313	version does not consider the manufacturer or microarchitecture of the processor.
1314	It tests solely the list of features that are both supported by the specified
1315	processor and present in the compiler-rt library. This can be surprising at times,
1316	as the runtime processor may be from a completely different manufacturer, as long
1317	as it supports the same feature set.
1318
1319	This can additionally be surprising, as some processors are indistringuishable from
1320	others based on the list of testable features. When this happens, the variant
1321	is selected in an unspecified manner.
1322
1323	Function versions are defined with ``cpu_specific``, which takes one or more CPU
1324	names as a parameter. For example:
1325
1326	.. code-block:: c
1327
1328	// Declares and defines the ivybridge version of single_cpu.
1329	__attribute__((cpu_specific(ivybridge)))
1330	void single_cpu(void){}
1331
1332	// Declares and defines the atom version of single_cpu.
1333	__attribute__((cpu_specific(atom)))
1334	void single_cpu(void){}
1335
1336	// Declares and defines both the ivybridge and atom version of multi_cpu.
1337	__attribute__((cpu_specific(ivybridge, atom)))
1338	void multi_cpu(void){}
1339
1340	A dispatching (or resolving) function can be declared anywhere in a project's
1341	source code with ``cpu_dispatch``. This attribute takes one or more CPU names
1342	as a parameter (like ``cpu_specific``). Functions marked with ``cpu_dispatch``
1343	are not expected to be defined, only declared. If such a marked function has a
1344	definition, any side effects of the function are ignored; trivial function
1345	bodies are permissible for ICC compatibility.
1346
1347	.. code-block:: c
1348
1349	// Creates a resolver for single_cpu above.
1350	__attribute__((cpu_dispatch(ivybridge, atom)))
1351	void single_cpu(void){}
1352
1353	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1354	// translation unit.
1355	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1356	void multi_cpu(void){}
1357
1358	Note that it is possible to have a resolving function that dispatches based on
1359	more or fewer options than are present in the program. Specifying fewer will
1360	result in the omitted options not being considered during resolution. Specifying
1361	a version for resolution that isn't defined in the program will result in a
1362	linking failure.
1363
1364	It is also possible to specify a CPU name of ``generic`` which will be resolved
1365	if the executing processor doesn't satisfy the features required in the CPU
1366	name. The behavior of a program executing on a processor that doesn't satisfy
1367	any option of a multiversioned function is undefined.)reST";
1368
1369	static const char AttrDoc_CPUSpecific[] = R"reST(The ``cpu_specific`` and ``cpu_dispatch`` attributes are used to define and
1370	resolve multiversioned functions. This form of multiversioning provides a
1371	mechanism for declaring versions across translation units and manually
1372	specifying the resolved function list. A specified CPU defines a set of minimum
1373	features that are required for the function to be called. The result of this is
1374	that future processors execute the most restrictive version of the function the
1375	new processor can execute.
1376
1377	In addition, unlike the ICC implementation of this feature, the selection of the
1378	version does not consider the manufacturer or microarchitecture of the processor.
1379	It tests solely the list of features that are both supported by the specified
1380	processor and present in the compiler-rt library. This can be surprising at times,
1381	as the runtime processor may be from a completely different manufacturer, as long
1382	as it supports the same feature set.
1383
1384	This can additionally be surprising, as some processors are indistringuishable from
1385	others based on the list of testable features. When this happens, the variant
1386	is selected in an unspecified manner.
1387
1388	Function versions are defined with ``cpu_specific``, which takes one or more CPU
1389	names as a parameter. For example:
1390
1391	.. code-block:: c
1392
1393	// Declares and defines the ivybridge version of single_cpu.
1394	__attribute__((cpu_specific(ivybridge)))
1395	void single_cpu(void){}
1396
1397	// Declares and defines the atom version of single_cpu.
1398	__attribute__((cpu_specific(atom)))
1399	void single_cpu(void){}
1400
1401	// Declares and defines both the ivybridge and atom version of multi_cpu.
1402	__attribute__((cpu_specific(ivybridge, atom)))
1403	void multi_cpu(void){}
1404
1405	A dispatching (or resolving) function can be declared anywhere in a project's
1406	source code with ``cpu_dispatch``. This attribute takes one or more CPU names
1407	as a parameter (like ``cpu_specific``). Functions marked with ``cpu_dispatch``
1408	are not expected to be defined, only declared. If such a marked function has a
1409	definition, any side effects of the function are ignored; trivial function
1410	bodies are permissible for ICC compatibility.
1411
1412	.. code-block:: c
1413
1414	// Creates a resolver for single_cpu above.
1415	__attribute__((cpu_dispatch(ivybridge, atom)))
1416	void single_cpu(void){}
1417
1418	// Creates a resolver for multi_cpu, but adds a 3rd version defined in another
1419	// translation unit.
1420	__attribute__((cpu_dispatch(ivybridge, atom, sandybridge)))
1421	void multi_cpu(void){}
1422
1423	Note that it is possible to have a resolving function that dispatches based on
1424	more or fewer options than are present in the program. Specifying fewer will
1425	result in the omitted options not being considered during resolution. Specifying
1426	a version for resolution that isn't defined in the program will result in a
1427	linking failure.
1428
1429	It is also possible to specify a CPU name of ``generic`` which will be resolved
1430	if the executing processor doesn't satisfy the features required in the CPU
1431	name. The behavior of a program executing on a processor that doesn't satisfy
1432	any option of a multiversioned function is undefined.)reST";
1433
1434	static const char AttrDoc_CUDAConstant[] = R"reST(No documentation.)reST";
1435
1436	static const char AttrDoc_CUDADevice[] = R"reST(No documentation.)reST";
1437
1438	static const char AttrDoc_CUDADeviceBuiltinSurfaceType[] = R"reST(The ``device_builtin_surface_type`` attribute can be applied to a class
1439	template when declaring the surface reference. A surface reference variable
1440	could be accessed on the host side and, on the device side, might be translated
1441	into an internal surface object, which is established through surface bind and
1442	unbind runtime APIs.)reST";
1443
1444	static const char AttrDoc_CUDADeviceBuiltinTextureType[] = R"reST(The ``device_builtin_texture_type`` attribute can be applied to a class
1445	template when declaring the texture reference. A texture reference variable
1446	could be accessed on the host side and, on the device side, might be translated
1447	into an internal texture object, which is established through texture bind and
1448	unbind runtime APIs.)reST";
1449
1450	static const char AttrDoc_CUDAGlobal[] = R"reST(No documentation.)reST";
1451
1452	static const char AttrDoc_CUDAHost[] = R"reST(No documentation.)reST";
1453
1454	static const char AttrDoc_CUDAInvalidTarget[] = R"reST()reST";
1455
1456	static const char AttrDoc_CUDALaunchBounds[] = R"reST(No documentation.)reST";
1457
1458	static const char AttrDoc_CUDAShared[] = R"reST(No documentation.)reST";
1459
1460	static const char AttrDoc_CXX11NoReturn[] = R"reST(A function declared as ``[[noreturn]]`` shall not return to its caller. The
1461	compiler will generate a diagnostic for a function declared as ``[[noreturn]]``
1462	that appears to be capable of returning to its caller.
1463
1464	The ``[[_Noreturn]]`` spelling is deprecated and only exists to ease code
1465	migration for code using ``[[noreturn]]`` after including ``<stdnoreturn.h>``.)reST";
1466
1467	static const char AttrDoc_CXXAssume[] = R"reST(The ``assume`` attribute is used to indicate to the optimizer that a
1468	certain condition is assumed to be true at a certain point in the
1469	program. If this condition is violated at runtime, the behavior is
1470	undefined. ``assume`` can only be applied to a null statement.
1471
1472	Different optimisers are likely to react differently to the presence of
1473	this attribute; in some cases, adding ``assume`` may affect performance
1474	negatively. It should be used with parsimony and care.
1475
1476	Example:
1477
1478	.. code-block:: c++
1479
1480	int f(int x, int y) {
1481	[[assume(x == 27)]];
1482	[[assume(x == y)]];
1483	return y + 1; // May be optimised to `return 28`.
1484	})reST";
1485
1486	static const char AttrDoc_CallableWhen[] = R"reST(Use ``__attribute__((callable_when(...)))`` to indicate what states a method
1487	may be called in. Valid states are unconsumed, consumed, or unknown. Each
1488	argument to this attribute must be a quoted string. E.g.:
1489
1490	``__attribute__((callable_when("unconsumed", "unknown")))``)reST";
1491
1492	static const char AttrDoc_Callback[] = R"reST(The ``callback`` attribute specifies that the annotated function may invoke the
1493	specified callback zero or more times. The callback, as well as the passed
1494	arguments, are identified by their parameter name or position (starting with
1495	1!) in the annotated function. The first position in the attribute identifies
1496	the callback callee, the following positions declare describe its arguments.
1497	The callback callee is required to be callable with the number, and order, of
1498	the specified arguments. The index ``0``, or the identifier ``this``, is used to
1499	represent an implicit "this" pointer in class methods. If there is no implicit
1500	"this" pointer it shall not be referenced. The index '-1', or the name "__",
1501	represents an unknown callback callee argument. This can be a value which is
1502	not present in the declared parameter list, or one that is, but is potentially
1503	inspected, captured, or modified. Parameter names and indices can be mixed in
1504	the callback attribute.
1505
1506	The ``callback`` attribute, which is directly translated to ``callback``
1507	metadata <http://llvm.org/docs/LangRef.html#callback-metadata>, make the
1508	connection between the call to the annotated function and the callback callee.
1509	This can enable interprocedural optimizations which were otherwise impossible.
1510	If a function parameter is mentioned in the ``callback`` attribute, through its
1511	position, it is undefined if that parameter is used for anything other than the
1512	actual callback. Inspected, captured, or modified parameters shall not be
1513	listed in the ``callback`` metadata.
1514
1515	Example encodings for the callback performed by ``pthread_create`` are shown
1516	below. The explicit attribute annotation indicates that the third parameter
1517	(``start_routine``) is called zero or more times by the ``pthread_create`` function,
1518	and that the fourth parameter (``arg``) is passed along. Note that the callback
1519	behavior of ``pthread_create`` is automatically recognized by Clang. In addition,
1520	the declarations of ``__kmpc_fork_teams`` and ``__kmpc_fork_call``, generated for
1521	``#pragma omp target teams`` and ``#pragma omp parallel``, respectively, are also
1522	automatically recognized as broker functions. Further functions might be added
1523	in the future.
1524
1525	.. code-block:: c
1526
1527	__attribute__((callback (start_routine, arg)))
1528	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1529	void (start_routine) (void ), void arg);
1530
1531	__attribute__((callback (3, 4)))
1532	int pthread_create(pthread_t thread, const pthread_attr_t attr,
1533	void (start_routine) (void ), void arg);)reST";
1534
1535	static const char AttrDoc_CalledOnce[] = R"reST(The ``called_once`` attribute specifies that the annotated function or method
1536	parameter is invoked exactly once on all execution paths. It only applies
1537	to parameters with function-like types, i.e. function pointers or blocks. This
1538	concept is particularly useful for asynchronous programs.
1539
1540	Clang implements a check for ``called_once`` parameters,
1541	``-Wcalled-once-parameter``. It is on by default and finds the following
1542	violations:
1543
1544	* Parameter is not called at all.
1545
1546	* Parameter is called more than once.
1547
1548	* Parameter is not called on one of the execution paths.
1549
1550	In the latter case, Clang pinpoints the path where parameter is not invoked
1551	by showing the control-flow statement where the path diverges.
1552
1553	.. code-block:: objc
1554
1555	void fooWithCallback(void (^callback)(void) __attribute__((called_once))) {
1556	if (somePredicate()) {
1557	...
1558	callback();
1559	} else {
1560	callback(); // OK: callback is called on every path
1561	}
1562	}
1563
1564	void barWithCallback(void (^callback)(void) __attribute__((called_once))) {
1565	if (somePredicate()) {
1566	...
1567	callback(); // note: previous call is here
1568	}
1569	callback(); // warning: callback is called twice
1570	}
1571
1572	void foobarWithCallback(void (^callback)(void) __attribute__((called_once))) {
1573	if (somePredicate()) { // warning: callback is not called when condition is false
1574	...
1575	callback();
1576	}
1577	}
1578
1579	This attribute is useful for API developers who want to double-check if they
1580	implemented their method correctly.)reST";
1581
1582	static const char AttrDoc_Capability[] = R"reST(No documentation.)reST";
1583
1584	static const char AttrDoc_CapturedRecord[] = R"reST()reST";
1585
1586	static const char AttrDoc_CarriesDependency[] = R"reST(The ``carries_dependency`` attribute specifies dependency propagation into and
1587	out of functions.
1588
1589	When specified on a function or Objective-C method, the ``carries_dependency``
1590	attribute means that the return value carries a dependency out of the function,
1591	so that the implementation need not constrain ordering upon return from that
1592	function. Implementations of the function and its caller may choose to preserve
1593	dependencies instead of emitting memory ordering instructions such as fences.
1594
1595	Note, this attribute does not change the meaning of the program, but may result
1596	in generation of more efficient code.)reST";
1597
1598	static const char AttrDoc_Cleanup[] = R"reST(This attribute allows a function to be run when a local variable goes out of
1599	scope. The attribute takes the identifier of a function with a parameter type
1600	that is a pointer to the type with the attribute.
1601
1602	.. code-block:: c
1603
1604	static void foo (int *) { ... }
1605	static void bar (int *) { ... }
1606	void baz (void) {
1607	int x __attribute__((cleanup(foo)));
1608	{
1609	int y __attribute__((cleanup(bar)));
1610	}
1611	}
1612
1613	The above example will result in a call to ``bar`` being passed the address of
1614	`y`` when ``y`` goes out of scope, then a call to ``foo`` being passed the
1615	address of ``x`` when ``x`` goes out of scope. If two or more variables share
1616	the same scope, their ``cleanup`` callbacks are invoked in the reverse order
1617	the variables were declared in. It is not possible to check the return value
1618	(if any) of these ``cleanup`` callback functions.)reST";
1619
1620	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).
1621
1622	.. code-block:: c
1623
1624	void __attribute__((clspv_libclc_builtin)) libclc_builtin() {}
1625
1626	.. _`clspv`: https://github.com/google/clspv
1627	.. _`libclc`: https://libclc.llvm.org)reST";
1628
1629	static const char AttrDoc_CmseNSCall[] = R"reST(This attribute declares a non-secure function type. When compiling for secure
1630	state, a call to such a function would switch from secure to non-secure state.
1631	All non-secure function calls must happen only through a function pointer, and
1632	a non-secure function type should only be used as a base type of a pointer.
1633	See `ARMv8-M Security Extensions: Requirements on Development
1634	Tools - Engineering Specification Documentation
1635	<https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.)reST";
1636
1637	static const char AttrDoc_CmseNSEntry[] = R"reST(This attribute declares a function that can be called from non-secure state, or
1638	from secure state. Entering from and returning to non-secure state would switch
1639	to and from secure state, respectively, and prevent flow of information
1640	to non-secure state, except via return values. See `ARMv8-M Security Extensions:
1641	Requirements on Development Tools - Engineering Specification Documentation
1642	<https://developer.arm.com/docs/ecm0359818/latest/>`_ for more information.)reST";
1643
1644	static const char AttrDoc_CodeAlign[] = R"reST(The ``clang::code_align(N)`` attribute applies to a loop and specifies the byte
1645	alignment for a loop. The attribute accepts a positive integer constant
1646	initialization expression indicating the number of bytes for the minimum
1647	alignment boundary. Its value must be a power of 2, between 1 and 4096
1648	(inclusive).
1649
1650	.. code-block:: c++
1651
1652	void foo() {
1653	int var = 0;
1654	[[clang::code_align(16)]] for (int i = 0; i < 10; ++i) var++;
1655	}
1656
1657	void Array(int *array, size_t n) {
1658	[[clang::code_align(64)]] for (int i = 0; i < n; ++i) array[i] = 0;
1659	}
1660
1661	void count () {
1662	int a1[10], int i = 0;
1663	[[clang::code_align(32)]] while (i < 10) { a1[i] += 3; }
1664	}
1665
1666	void check() {
1667	int a = 10;
1668	[[clang::code_align(8)]] do {
1669	a = a + 1;
1670	} while (a < 20);
1671	}
1672
1673	template<int A>
1674	void func() {
1675	[[clang::code_align(A)]] for(;;) { }
1676	})reST";
1677
1678	static const char AttrDoc_CodeModel[] = R"reST(The ``model`` attribute allows overriding the translation unit's
1679	code model (specified by ``-mcmodel``) for a specific global variable.)reST";
1680
1681	static const char AttrDoc_CodeSeg[] = R"reST(The ``__declspec(code_seg)`` attribute enables the placement of code into separate
1682	named segments that can be paged or locked in memory individually. This attribute
1683	is used to control the placement of instantiated templates and compiler-generated
1684	code. See the documentation for `__declspec(code_seg)`_ on MSDN.
1685
1686	.. _`__declspec(code_seg)`: http://msdn.microsoft.com/en-us/library/dn636922.aspx)reST";
1687
1688	static const char AttrDoc_Cold[] = R"reST(``__attribute__((cold))`` marks a function as cold, as a manual alternative to PGO hotness data.
1689	If PGO data is available, the profile count based hotness overrides the ``__attribute__((cold))`` annotation (unlike ``__attribute__((hot))``).)reST";
1690
1691	static const char AttrDoc_Common[] = R"reST(No documentation.)reST";
1692
1693	static const char AttrDoc_Const[] = R"reST(No documentation.)reST";
1694
1695	static const char AttrDoc_ConstInit[] = R"reST(This attribute specifies that the variable to which it is attached is intended
1696	to have a `constant initializer <http://en.cppreference.com/w/cpp/language/constant_initialization>`_
1697	according to the rules of [basic.start.static]. The variable is required to
1698	have static or thread storage duration. If the initialization of the variable
1699	is not a constant initializer an error will be produced. This attribute may
1700	only be used in C++; the ``constinit`` spelling is only accepted in C++20
1701	onwards.
1702
1703	Note that in C++03 strict constant expression checking is not done. Instead
1704	the attribute reports if Clang can emit the variable as a constant, even if it's
1705	not technically a 'constant initializer'. This behavior is non-portable.
1706
1707	Static storage duration variables with constant initializers avoid hard-to-find
1708	bugs caused by the indeterminate order of dynamic initialization. They can also
1709	be safely used during dynamic initialization across translation units.
1710
1711	This attribute acts as a compile time assertion that the requirements
1712	for constant initialization have been met. Since these requirements change
1713	between dialects and have subtle pitfalls it's important to fail fast instead
1714	of silently falling back on dynamic initialization.
1715
1716	The first use of the attribute on a variable must be part of, or precede, the
1717	initializing declaration of the variable. C++20 requires the ``constinit``
1718	spelling of the attribute to be present on the initializing declaration if it
1719	is used anywhere. The other spellings can be specified on a forward declaration
1720	and omitted on a later initializing declaration.
1721
1722	.. code-block:: c++
1723
1724	// -std=c++14
1725	#define SAFE_STATIC [[clang::require_constant_initialization]]
1726	struct T {
1727	constexpr T(int) {}
1728	~T(); // non-trivial
1729	};
1730	SAFE_STATIC T x = {42}; // Initialization OK. Doesn't check destructor.
1731	SAFE_STATIC T y = 42; // error: variable does not have a constant initializer
1732	// copy initialization is not a constant expression on a non-literal type.)reST";
1733
1734	static const char AttrDoc_Constructor[] = R"reST(The ``constructor`` attribute causes the function to be called before entering
1735	``main()``, and the ``destructor`` attribute causes the function to be called
1736	after returning from ``main()`` or when the ``exit()`` function has been
1737	called. Note, ``quick_exit()``, ``_Exit()``, and ``abort()`` prevent a function
1738	marked ``destructor`` from being called.
1739
1740	The constructor or destructor function should not accept any arguments and its
1741	return type should be ``void``.
1742
1743	The attributes accept an optional argument used to specify the priority order
1744	in which to execute constructor and destructor functions. The priority is
1745	given as an integer constant expression between 101 and 65535 (inclusive).
1746	Priorities outside of that range are reserved for use by the implementation. A
1747	lower value indicates a higher priority of initialization. Note that only the
1748	relative ordering of values is important. For example:
1749
1750	.. code-block:: c++
1751
1752	__attribute__((constructor(200))) void foo(void);
1753	__attribute__((constructor(101))) void bar(void);
1754
1755	``bar()`` will be called before ``foo()``, and both will be called before
1756	``main()``. If no argument is given to the ``constructor`` or ``destructor``
1757	attribute, they default to the value ``65535``.)reST";
1758
1759	static const char AttrDoc_Consumable[] = R"reST(Each ``class`` that uses any of the typestate annotations must first be marked
1760	using the ``consumable`` attribute. Failure to do so will result in a warning.
1761
1762	This attribute accepts a single parameter that must be one of the following:
1763	``unknown``, ``consumed``, or ``unconsumed``.)reST";
1764
1765	static const char AttrDoc_ConsumableAutoCast[] = R"reST(No documentation.)reST";
1766
1767	static const char AttrDoc_ConsumableSetOnRead[] = R"reST(No documentation.)reST";
1768
1769	static const char AttrDoc_Convergent[] = R"reST(The ``convergent`` attribute can be placed on a function declaration. It is
1770	translated into the LLVM ``convergent`` attribute, which indicates that the call
1771	instructions of a function with this attribute cannot be made control-dependent
1772	on any additional values.
1773
1774	In languages designed for SPMD/SIMT programming model, e.g. OpenCL or CUDA,
1775	the call instructions of a function with this attribute must be executed by
1776	all work items or threads in a work group or sub group.
1777
1778	This attribute is different from ``noduplicate`` because it allows duplicating
1779	function calls if it can be proved that the duplicated function calls are
1780	not made control-dependent on any additional values, e.g., unrolling a loop
1781	executed by all work items.
1782
1783	Sample usage:
1784
1785	.. code-block:: c
1786
1787	void convfunc(void) __attribute__((convergent));
1788	// Setting it as a C++11 attribute is also valid in a C++ program.
1789	// void convfunc(void) [[clang::convergent]];)reST";
1790
1791	static const char AttrDoc_CoroDisableLifetimeBound[] = R"reST(The ``[[clang::coro_lifetimebound]]`` is a class attribute which can be applied
1792	to a coroutine return type (`CRT`_) (i.e.
1793	it should also be annotated with ``[[clang::coro_return_type]]``).
1794
1795	All parameters of a function are considered to be lifetime bound if the function returns a
1796	coroutine return type (CRT) annotated with ``[[clang::coro_lifetimebound]]``.
1797	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
1798	with ``[[clang::coro_disable_lifetimebound]]`` function attribute .
1799	See `documentation`_ of ``[[clang::lifetimebound]]`` for details about lifetime bound analysis.
1800
1801
1802	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
1803
1804	For example,
1805
1806	.. code-block:: c++
1807
1808	task<int> coro(const int& a) { co_return a + 1; }
1809	task<int> dangling_refs(int a) {
1810	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
1811	auto foo = coro(1);
1812	// `coro` captures reference to local variable `a` which is destroyed after the return.
1813	return coro(a);
1814	}
1815
1816	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
1817	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
1818	``[[clang::coro_lifetimebound]]``, then lifetime bound analysis would detect capturing reference to
1819	temporaries or return address of a local variable.
1820
1821	Both coroutines and coroutine wrappers are part of this analysis.
1822
1823	.. code-block:: c++
1824
1825	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
1826	using promise_type = some_promise_type;
1827	};
1828
1829	Task<int> coro(const int& a) { co_return a + 1; }
1830	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
1831	return a > b ? coro(a) : coro(b);
1832	}
1833	Task<int> temporary_reference() {
1834	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
1835
1836	int a = 1;
1837	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
1838
1839	co_return co_await coro(1); // fine.
1840	}
1841	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
1842	return coro(a); // warning: returning address of stack variable `a`.
1843	}
1844
1845	This analysis can be disabled for all calls to a particular function by annotating the function
1846	with function attribute ``[[clang::coro_disable_lifetimebound]]``.
1847	For example, this could be useful for coroutine wrappers which accept reference parameters
1848	but do not pass them to the underlying coroutine or pass them by value.
1849
1850	.. code-block:: c++
1851
1852	Task<int> coro(int a) { co_return a + 1; }
1853	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
1854	return coro(a + 1);
1855	}
1856	void use() {
1857	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
1858	}
1859
1860	.. _`documentation`: https://clang.llvm.org/docs/AttributeReference.html#lifetimebound
1861	.. _`CRT`: https://clang.llvm.org/docs/AttributeReference.html#coro-return-type)reST";
1862
1863	static const char AttrDoc_CoroLifetimeBound[] = R"reST(The ``[[clang::coro_lifetimebound]]`` is a class attribute which can be applied
1864	to a coroutine return type (`CRT`_) (i.e.
1865	it should also be annotated with ``[[clang::coro_return_type]]``).
1866
1867	All parameters of a function are considered to be lifetime bound if the function returns a
1868	coroutine return type (CRT) annotated with ``[[clang::coro_lifetimebound]]``.
1869	This lifetime bound analysis can be disabled for a coroutine wrapper or a coroutine by annotating the function
1870	with ``[[clang::coro_disable_lifetimebound]]`` function attribute .
1871	See `documentation`_ of ``[[clang::lifetimebound]]`` for details about lifetime bound analysis.
1872
1873
1874	Reference parameters of a coroutine are susceptible to capturing references to temporaries or local variables.
1875
1876	For example,
1877
1878	.. code-block:: c++
1879
1880	task<int> coro(const int& a) { co_return a + 1; }
1881	task<int> dangling_refs(int a) {
1882	// `coro` captures reference to a temporary. `foo` would now contain a dangling reference to `a`.
1883	auto foo = coro(1);
1884	// `coro` captures reference to local variable `a` which is destroyed after the return.
1885	return coro(a);
1886	}
1887
1888	Lifetime bound static analysis can be used to detect such instances when coroutines capture references
1889	which may die earlier than the coroutine frame itself. In the above example, if the CRT `task` is annotated with
1890	``[[clang::coro_lifetimebound]]``, then lifetime bound analysis would detect capturing reference to
1891	temporaries or return address of a local variable.
1892
1893	Both coroutines and coroutine wrappers are part of this analysis.
1894
1895	.. code-block:: c++
1896
1897	template <typename T> struct [[clang::coro_return_type, clang::coro_lifetimebound]] Task {
1898	using promise_type = some_promise_type;
1899	};
1900
1901	Task<int> coro(const int& a) { co_return a + 1; }
1902	[[clang::coro_wrapper]] Task<int> coro_wrapper(const int& a, const int& b) {
1903	return a > b ? coro(a) : coro(b);
1904	}
1905	Task<int> temporary_reference() {
1906	auto foo = coro(1); // warning: capturing reference to a temporary which would die after the expression.
1907
1908	int a = 1;
1909	auto bar = coro_wrapper(a, 0); // warning: `b` captures reference to a temporary.
1910
1911	co_return co_await coro(1); // fine.
1912	}
1913	[[clang::coro_wrapper]] Task<int> stack_reference(int a) {
1914	return coro(a); // warning: returning address of stack variable `a`.
1915	}
1916
1917	This analysis can be disabled for all calls to a particular function by annotating the function
1918	with function attribute ``[[clang::coro_disable_lifetimebound]]``.
1919	For example, this could be useful for coroutine wrappers which accept reference parameters
1920	but do not pass them to the underlying coroutine or pass them by value.
1921
1922	.. code-block:: c++
1923
1924	Task<int> coro(int a) { co_return a + 1; }
1925	[[clang::coro_wrapper, clang::coro_disable_lifetimebound]] Task<int> coro_wrapper(const int& a) {
1926	return coro(a + 1);
1927	}
1928	void use() {
1929	auto task = coro_wrapper(1); // use of temporary is fine as the argument is not lifetime bound.
1930	}
1931
1932	.. _`documentation`: https://clang.llvm.org/docs/AttributeReference.html#lifetimebound
1933	.. _`CRT`: https://clang.llvm.org/docs/AttributeReference.html#coro-return-type)reST";
1934
1935	static const char AttrDoc_CoroOnlyDestroyWhenComplete[] = R"reST(The `coro_only_destroy_when_complete` attribute should be marked on a C++ class. The coroutines
1936	whose return type is marked with the attribute are assumed to be destroyed only after the coroutine has
1937	reached the final suspend point.
1938
1939	This is helpful for the optimizers to reduce the size of the destroy function for the coroutines.
1940
1941	For example,
1942
1943	.. code-block:: c++
1944
1945	A foo() {
1946	dtor d;
1947	co_await something();
1948	dtor d1;
1949	co_await something();
1950	dtor d2;
1951	co_return 43;
1952	}
1953
1954	The compiler may generate the following pseudocode:
1955
1956	.. code-block:: c++
1957
1958	void foo.destroy(foo.Frame *frame) {
1959	switch(frame->suspend_index()) {
1960	case 1:
1961	frame->d.~dtor();
1962	break;
1963	case 2:
1964	frame->d.~dtor();
1965	frame->d1.~dtor();
1966	break;
1967	case 3:
1968	frame->d.~dtor();
1969	frame->d1.~dtor();
1970	frame->d2.~dtor();
1971	break;
1972	default: // coroutine completed or haven't started
1973	break;
1974	}
1975
1976	frame->promise.~promise_type();
1977	delete frame;
1978	}
1979
1980	The `foo.destroy()` function's purpose is to release all of the resources
1981	initialized for the coroutine when it is destroyed in a suspended state.
1982	However, if the coroutine is only ever destroyed at the final suspend state,
1983	the rest of the conditions are superfluous.
1984
1985	The user can use the `coro_only_destroy_when_complete` attributo suppress
1986	generation of the other destruction cases, optimizing the above `foo.destroy` to:
1987
1988	.. code-block:: c++
1989
1990	void foo.destroy(foo.Frame *frame) {
1991	frame->promise.~promise_type();
1992	delete frame;
1993	})reST";
1994
1995	static const char AttrDoc_CoroReturnType[] = R"reST(The ``[[clang::coro_return_type]]`` attribute is used to help static analyzers to recognize
1996	coroutines from the function signatures.
1997
1998	The ``coro_return_type`` attribute should be marked on a C++ class to mark it as
1999	a coroutine return type (CRT).
2000
2001	A function ``R func(P1, .., PN)`` has a coroutine return type (CRT) ``R`` if ``R``
2002	is marked by ``[[clang::coro_return_type]]`` and ``R`` has a promise type associated to it
2003	(i.e., std::coroutine_traits<R, P1, .., PN>::promise_type is a valid promise type).
2004
2005	If the return type of a function is a ``CRT`` then the function must be a coroutine.
2006	Otherwise the program is invalid. It is allowed for a non-coroutine to return a ``CRT``
2007	if the function is marked with ``[[clang::coro_wrapper]]``.
2008
2009	The ``[[clang::coro_wrapper]]`` attribute should be marked on a C++ function to mark it as
2010	a coroutine wrapper. A coroutine wrapper is a function which returns a ``CRT``,
2011	is not a coroutine itself and is marked with ``[[clang::coro_wrapper]]``.
2012
2013	Clang will enforce that all functions that return a ``CRT`` are either coroutines or marked
2014	with ``[[clang::coro_wrapper]]``. Clang will enforce this with an error.
2015
2016	From a language perspective, it is not possible to differentiate between a coroutine and a
2017	function returning a CRT by merely looking at the function signature.
2018
2019	Coroutine wrappers, in particular, are susceptible to capturing
2020	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2021	issues with coroutine wrappers.
2022
2023	For example,
2024
2025	.. code-block:: c++
2026
2027	// This is a CRT.
2028	template <typename T> struct [[clang::coro_return_type]] Task {
2029	using promise_type = some_promise_type;
2030	};
2031
2032	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2033	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2034
2035	// Fine for a coroutine wrapper to return a CRT.
2036	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2037
2038	void bar() {
2039	// Invalid. This intantiates a function which returns a CRT but is not marked as
2040	// a coroutine wrapper.
2041	std::function<Task<int>(int)> f = increment;
2042	}
2043
2044	Note: ``a_promise_type::get_return_object`` is exempted from this analysis as it is a necessary
2045	implementation detail of any coroutine library.)reST";
2046
2047	static const char AttrDoc_CoroWrapper[] = R"reST(The ``[[clang::coro_return_type]]`` attribute is used to help static analyzers to recognize
2048	coroutines from the function signatures.
2049
2050	The ``coro_return_type`` attribute should be marked on a C++ class to mark it as
2051	a coroutine return type (CRT).
2052
2053	A function ``R func(P1, .., PN)`` has a coroutine return type (CRT) ``R`` if ``R``
2054	is marked by ``[[clang::coro_return_type]]`` and ``R`` has a promise type associated to it
2055	(i.e., std::coroutine_traits<R, P1, .., PN>::promise_type is a valid promise type).
2056
2057	If the return type of a function is a ``CRT`` then the function must be a coroutine.
2058	Otherwise the program is invalid. It is allowed for a non-coroutine to return a ``CRT``
2059	if the function is marked with ``[[clang::coro_wrapper]]``.
2060
2061	The ``[[clang::coro_wrapper]]`` attribute should be marked on a C++ function to mark it as
2062	a coroutine wrapper. A coroutine wrapper is a function which returns a ``CRT``,
2063	is not a coroutine itself and is marked with ``[[clang::coro_wrapper]]``.
2064
2065	Clang will enforce that all functions that return a ``CRT`` are either coroutines or marked
2066	with ``[[clang::coro_wrapper]]``. Clang will enforce this with an error.
2067
2068	From a language perspective, it is not possible to differentiate between a coroutine and a
2069	function returning a CRT by merely looking at the function signature.
2070
2071	Coroutine wrappers, in particular, are susceptible to capturing
2072	references to temporaries and other lifetime issues. This allows to avoid such lifetime
2073	issues with coroutine wrappers.
2074
2075	For example,
2076
2077	.. code-block:: c++
2078
2079	// This is a CRT.
2080	template <typename T> struct [[clang::coro_return_type]] Task {
2081	using promise_type = some_promise_type;
2082	};
2083
2084	Task<int> increment(int a) { co_return a + 1; } // Fine. This is a coroutine.
2085	Task<int> foo() { return increment(1); } // Error. foo is not a coroutine.
2086
2087	// Fine for a coroutine wrapper to return a CRT.
2088	[[clang::coro_wrapper]] Task<int> foo() { return increment(1); }
2089
2090	void bar() {
2091	// Invalid. This intantiates a function which returns a CRT but is not marked as
2092	// a coroutine wrapper.
2093	std::function<Task<int>(int)> f = increment;
2094	}
2095
2096	Note: ``a_promise_type::get_return_object`` is exempted from this analysis as it is a necessary
2097	implementation detail of any coroutine library.)reST";
2098
2099	static const char AttrDoc_CountedBy[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
2100	structure in C. The argument for the attribute is the name of a field member
2101	holding the count of elements in the flexible array. This information can be
2102	used to improve the results of the array bound sanitizer and the
2103	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
2104	within the same non-anonymous, enclosing struct as the flexible array member.
2105
2106	This example specifies that the flexible array member ``array`` has the number
2107	of elements allocated for it in ``count``:
2108
2109	.. code-block:: c
2110
2111	struct bar;
2112
2113	struct foo {
2114	size_t count;
2115	char other;
2116	struct bar *array[] __attribute__((counted_by(count)));
2117	};
2118
2119	This establishes a relationship between ``array`` and ``count``. Specifically,
2120	``array`` must have at least ``count`` number of elements available. It's the
2121	user's responsibility to ensure that this relationship is maintained through
2122	changes to the structure.
2123
2124	In the following example, the allocated array erroneously has fewer elements
2125	than what's specified by ``p->count``. This would result in an out-of-bounds
2126	access not being detected.
2127
2128	.. code-block:: c
2129
2130	#define SIZE_INCR 42
2131
2132	struct foo *p;
2133
2134	void foo_alloc(size_t count) {
2135	p = malloc(MAX(sizeof(struct foo),
2136	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2137	p->count = count + SIZE_INCR;
2138	}
2139
2140	The next example updates ``p->count``, but breaks the relationship requirement
2141	that ``p->array`` must have at least ``p->count`` number of elements available:
2142
2143	.. code-block:: c
2144
2145	#define SIZE_INCR 42
2146
2147	struct foo *p;
2148
2149	void foo_alloc(size_t count) {
2150	p = malloc(MAX(sizeof(struct foo),
2151	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2152	p->count = count;
2153	}
2154
2155	void use_foo(int index, int val) {
2156	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
2157	p->array[index] = val; /* The sanitizer can't properly check this access. */
2158	}
2159
2160	In this example, an update to ``p->count`` maintains the relationship
2161	requirement:
2162
2163	.. code-block:: c
2164
2165	void use_foo(int index, int val) {
2166	if (p->count == 0)
2167	return;
2168	--p->count;
2169	p->array[index] = val;
2170	})reST";
2171
2172	static const char AttrDoc_CountedByOrNull[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
2173	structure in C. The argument for the attribute is the name of a field member
2174	holding the count of elements in the flexible array. This information can be
2175	used to improve the results of the array bound sanitizer and the
2176	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
2177	within the same non-anonymous, enclosing struct as the flexible array member.
2178
2179	This example specifies that the flexible array member ``array`` has the number
2180	of elements allocated for it in ``count``:
2181
2182	.. code-block:: c
2183
2184	struct bar;
2185
2186	struct foo {
2187	size_t count;
2188	char other;
2189	struct bar *array[] __attribute__((counted_by(count)));
2190	};
2191
2192	This establishes a relationship between ``array`` and ``count``. Specifically,
2193	``array`` must have at least ``count`` number of elements available. It's the
2194	user's responsibility to ensure that this relationship is maintained through
2195	changes to the structure.
2196
2197	In the following example, the allocated array erroneously has fewer elements
2198	than what's specified by ``p->count``. This would result in an out-of-bounds
2199	access not being detected.
2200
2201	.. code-block:: c
2202
2203	#define SIZE_INCR 42
2204
2205	struct foo *p;
2206
2207	void foo_alloc(size_t count) {
2208	p = malloc(MAX(sizeof(struct foo),
2209	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2210	p->count = count + SIZE_INCR;
2211	}
2212
2213	The next example updates ``p->count``, but breaks the relationship requirement
2214	that ``p->array`` must have at least ``p->count`` number of elements available:
2215
2216	.. code-block:: c
2217
2218	#define SIZE_INCR 42
2219
2220	struct foo *p;
2221
2222	void foo_alloc(size_t count) {
2223	p = malloc(MAX(sizeof(struct foo),
2224	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
2225	p->count = count;
2226	}
2227
2228	void use_foo(int index, int val) {
2229	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
2230	p->array[index] = val; /* The sanitizer can't properly check this access. */
2231	}
2232
2233	In this example, an update to ``p->count`` maintains the relationship
2234	requirement:
2235
2236	.. code-block:: c
2237
2238	void use_foo(int index, int val) {
2239	if (p->count == 0)
2240	return;
2241	--p->count;
2242	p->array[index] = val;
2243	})reST";
2244
2245	static const char AttrDoc_DLLExport[] = R"reST(The ``__declspec(dllexport)`` attribute declares a variable, function, or
2246	Objective-C interface to be exported from the module. It is available under the
2247	``-fdeclspec`` flag for compatibility with various compilers. The primary use
2248	is for COFF object files which explicitly specify what interfaces are available
2249	for external use. See the dllexport_ documentation on MSDN for more
2250	information.
2251
2252	.. _dllexport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2253
2254	static const char AttrDoc_DLLExportStaticLocal[] = R"reST()reST";
2255
2256	static const char AttrDoc_DLLImport[] = R"reST(The ``__declspec(dllimport)`` attribute declares a variable, function, or
2257	Objective-C interface to be imported from an external module. It is available
2258	under the ``-fdeclspec`` flag for compatibility with various compilers. The
2259	primary use is for COFF object files which explicitly specify what interfaces
2260	are imported from external modules. See the dllimport_ documentation on MSDN
2261	for more information.
2262
2263	Note that a dllimport function may still be inlined, if its definition is
2264	available and it doesn't reference any non-dllimport functions or global
2265	variables.
2266
2267	.. _dllimport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx)reST";
2268
2269	static const char AttrDoc_DLLImportStaticLocal[] = R"reST()reST";
2270
2271	static const char AttrDoc_Deprecated[] = R"reST(The ``deprecated`` attribute can be applied to a function, a variable, or a
2272	type. This is useful when identifying functions, variables, or types that are
2273	expected to be removed in a future version of a program.
2274
2275	Consider the function declaration for a hypothetical function ``f``:
2276
2277	.. code-block:: c++
2278
2279	void f(void) __attribute__((deprecated("message", "replacement")));
2280
2281	When spelled as ``__attribute__((deprecated))``, the deprecated attribute can have
2282	two optional string arguments. The first one is the message to display when
2283	emitting the warning; the second one enables the compiler to provide a Fix-It
2284	to replace the deprecated name with a new name. Otherwise, when spelled as
2285	``[[gnu::deprecated]]`` or ``[[deprecated]]``, the attribute can have one optional
2286	string argument which is the message to display when emitting the warning.)reST";
2287
2288	static const char AttrDoc_Destructor[] = R"reST(The ``constructor`` attribute causes the function to be called before entering
2289	``main()``, and the ``destructor`` attribute causes the function to be called
2290	after returning from ``main()`` or when the ``exit()`` function has been
2291	called. Note, ``quick_exit()``, ``_Exit()``, and ``abort()`` prevent a function
2292	marked ``destructor`` from being called.
2293
2294	The constructor or destructor function should not accept any arguments and its
2295	return type should be ``void``.
2296
2297	The attributes accept an optional argument used to specify the priority order
2298	in which to execute constructor and destructor functions. The priority is
2299	given as an integer constant expression between 101 and 65535 (inclusive).
2300	Priorities outside of that range are reserved for use by the implementation. A
2301	lower value indicates a higher priority of initialization. Note that only the
2302	relative ordering of values is important. For example:
2303
2304	.. code-block:: c++
2305
2306	__attribute__((constructor(200))) void foo(void);
2307	__attribute__((constructor(101))) void bar(void);
2308
2309	``bar()`` will be called before ``foo()``, and both will be called before
2310	``main()``. If no argument is given to the ``constructor`` or ``destructor``
2311	attribute, they default to the value ``65535``.)reST";
2312
2313	static const char AttrDoc_DiagnoseAsBuiltin[] = R"reST(The ``diagnose_as_builtin`` attribute indicates that Fortify diagnostics are to
2314	be applied to the declared function as if it were the function specified by the
2315	attribute. The builtin function whose diagnostics are to be mimicked should be
2316	given. In addition, the order in which arguments should be applied must also
2317	be given.
2318
2319	For example, the attribute can be used as follows.
2320
2321	.. code-block:: c
2322
2323	__attribute__((diagnose_as_builtin(__builtin_memset, 3, 2, 1)))
2324	void mymemset(int n, int c, void s) {
2325	// ...
2326	}
2327
2328	This indicates that calls to ``mymemset`` should be diagnosed as if they were
2329	calls to ``__builtin_memset``. The arguments ``3, 2, 1`` indicate by index the
2330	order in which arguments of ``mymemset`` should be applied to
2331	``__builtin_memset``. The third argument should be applied first, then the
2332	second, and then the first. Thus (when Fortify warnings are enabled) the call
2333	``mymemset(n, c, s)`` will diagnose overflows as if it were the call
2334	``__builtin_memset(s, c, n)``.
2335
2336	For variadic functions, the variadic arguments must come in the same order as
2337	they would to the builtin function, after all normal arguments. For instance,
2338	to diagnose a new function as if it were `sscanf`, we can use the attribute as
2339	follows.
2340
2341	.. code-block:: c
2342
2343	__attribute__((diagnose_as_builtin(sscanf, 1, 2)))
2344	int mysscanf(const char str, const char format, ...) {
2345	// ...
2346	}
2347
2348	Then the call `mysscanf("abc def", "%4s %4s", buf1, buf2)` will be diagnosed as
2349	if it were the call `sscanf("abc def", "%4s %4s", buf1, buf2)`.
2350
2351	This attribute cannot be applied to non-static member functions.)reST";
2352
2353	static const char AttrDoc_DiagnoseIf[] = R"reST(The ``diagnose_if`` attribute can be placed on function declarations to emit
2354	warnings or errors at compile-time if calls to the attributed function meet
2355	certain user-defined criteria. For example:
2356
2357	.. code-block:: c
2358
2359	int abs(int a)
2360	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "warning")));
2361	int must_abs(int a)
2362	__attribute__((diagnose_if(a >= 0, "Redundant abs call", "error")));
2363
2364	int val = abs(1); // warning: Redundant abs call
2365	int val2 = must_abs(1); // error: Redundant abs call
2366	int val3 = abs(val);
2367	int val4 = must_abs(val); // Because run-time checks are not emitted for
2368	// diagnose_if attributes, this executes without
2369	// issue.
2370
2371
2372	``diagnose_if`` is closely related to ``enable_if``, with a few key differences:
2373
2374	* Overload resolution is not aware of ``diagnose_if`` attributes: they're
2375	considered only after we select the best candidate from a given candidate set.
2376	* Function declarations that differ only in their ``diagnose_if`` attributes are
2377	considered to be redeclarations of the same function (not overloads).
2378	* If the condition provided to ``diagnose_if`` cannot be evaluated, no
2379	diagnostic will be emitted.
2380
2381	Otherwise, ``diagnose_if`` is essentially the logical negation of ``enable_if``.
2382
2383	As a result of bullet number two, ``diagnose_if`` attributes will stack on the
2384	same function. For example:
2385
2386	.. code-block:: c
2387
2388	int foo() __attribute__((diagnose_if(1, "diag1", "warning")));
2389	int foo() __attribute__((diagnose_if(1, "diag2", "warning")));
2390
2391	int bar = foo(); // warning: diag1
2392	// warning: diag2
2393	int (*fooptr)(void) = foo; // warning: diag1
2394	// warning: diag2
2395
2396	constexpr int supportsAPILevel(int N) { return N < 5; }
2397	int baz(int a)
2398	__attribute__((diagnose_if(!supportsAPILevel(10),
2399	"Upgrade to API level 10 to use baz", "error")));
2400	int baz(int a)
2401	__attribute__((diagnose_if(!a, "0 is not recommended.", "warning")));
2402
2403	int (*bazptr)(int) = baz; // error: Upgrade to API level 10 to use baz
2404	int v = baz(0); // error: Upgrade to API level 10 to use baz
2405
2406	Query for this feature with ``__has_attribute(diagnose_if)``.)reST";
2407
2408	static const char AttrDoc_DisableSanitizerInstrumentation[] = R"reST(Use the ``disable_sanitizer_instrumentation`` attribute on a function,
2409	Objective-C method, or global variable, to specify that no sanitizer
2410	instrumentation should be applied.
2411
2412	This is not the same as ``__attribute__((no_sanitize(...)))``, which depending
2413	on the tool may still insert instrumentation to prevent false positive reports.)reST";
2414
2415	static const char AttrDoc_DisableTailCalls[] = R"reST(The ``disable_tail_calls`` attribute instructs the backend to not perform tail
2416	call optimization inside the marked function.
2417
2418	For example:
2419
2420	.. code-block:: c
2421
2422	int callee(int);
2423
2424	int foo(int a) __attribute__((disable_tail_calls)) {
2425	return callee(a); // This call is not tail-call optimized.
2426	}
2427
2428	Marking virtual functions as ``disable_tail_calls`` is legal.
2429
2430	.. code-block:: c++
2431
2432	int callee(int);
2433
2434	class Base {
2435	public:
2436	[[clang::disable_tail_calls]] virtual int foo1() {
2437	return callee(); // This call is not tail-call optimized.
2438	}
2439	};
2440
2441	class Derived1 : public Base {
2442	public:
2443	int foo1() override {
2444	return callee(); // This call is tail-call optimized.
2445	}
2446	};)reST";
2447
2448	static const char AttrDoc_EmptyBases[] = R"reST(The empty_bases attribute permits the compiler to utilize the
2449	empty-base-optimization more frequently.
2450	This attribute only applies to struct, class, and union types.
2451	It is only supported when using the Microsoft C++ ABI.)reST";
2452
2453	static const char AttrDoc_EnableIf[] = R"reST(.. Note:: Some features of this attribute are experimental. The meaning of
2454	multiple enable_if attributes on a single declaration is subject to change in
2455	a future version of clang. Also, the ABI is not standardized and the name
2456	mangling may change in future versions. To avoid that, use asm labels.
2457
2458	The ``enable_if`` attribute can be placed on function declarations to control
2459	which overload is selected based on the values of the function's arguments.
2460	When combined with the ``overloadable`` attribute, this feature is also
2461	available in C.
2462
2463	.. code-block:: c++
2464
2465	int isdigit(int c);
2466	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")));
2467
2468	void foo(char c) {
2469	isdigit(c);
2470	isdigit(10);
2471	isdigit(-10); // results in a compile-time error.
2472	}
2473
2474	The enable_if attribute takes two arguments, the first is an expression written
2475	in terms of the function parameters, the second is a string explaining why this
2476	overload candidate could not be selected to be displayed in diagnostics. The
2477	expression is part of the function signature for the purposes of determining
2478	whether it is a redeclaration (following the rules used when determining
2479	whether a C++ template specialization is ODR-equivalent), but is not part of
2480	the type.
2481
2482	The enable_if expression is evaluated as if it were the body of a
2483	bool-returning constexpr function declared with the arguments of the function
2484	it is being applied to, then called with the parameters at the call site. If the
2485	result is false or could not be determined through constant expression
2486	evaluation, then this overload will not be chosen and the provided string may
2487	be used in a diagnostic if the compile fails as a result.
2488
2489	Because the enable_if expression is an unevaluated context, there are no global
2490	state changes, nor the ability to pass information from the enable_if
2491	expression to the function body. For example, suppose we want calls to
2492	strnlen(strbuf, maxlen) to resolve to strnlen_chk(strbuf, maxlen, size of
2493	strbuf) only if the size of strbuf can be determined:
2494
2495	.. code-block:: c++
2496
2497	__attribute__((always_inline))
2498	static inline size_t strnlen(const char *s, size_t maxlen)
2499	__attribute__((overloadable))
2500	__attribute__((enable_if(__builtin_object_size(s, 0) != -1))),
2501	"chosen when the buffer size is known but 'maxlen' is not")))
2502	{
2503	return strnlen_chk(s, maxlen, __builtin_object_size(s, 0));
2504	}
2505
2506	Multiple enable_if attributes may be applied to a single declaration. In this
2507	case, the enable_if expressions are evaluated from left to right in the
2508	following manner. First, the candidates whose enable_if expressions evaluate to
2509	false or cannot be evaluated are discarded. If the remaining candidates do not
2510	share ODR-equivalent enable_if expressions, the overload resolution is
2511	ambiguous. Otherwise, enable_if overload resolution continues with the next
2512	enable_if attribute on the candidates that have not been discarded and have
2513	remaining enable_if attributes. In this way, we pick the most specific
2514	overload out of a number of viable overloads using enable_if.
2515
2516	.. code-block:: c++
2517
2518	void f() __attribute__((enable_if(true, ""))); // #1
2519	void f() __attribute__((enable_if(true, ""))) __attribute__((enable_if(true, ""))); // #2
2520
2521	void g(int i, int j) __attribute__((enable_if(i, ""))); // #1
2522	void g(int i, int j) __attribute__((enable_if(j, ""))) __attribute__((enable_if(true))); // #2
2523
2524	In this example, a call to f() is always resolved to #2, as the first enable_if
2525	expression is ODR-equivalent for both declarations, but #1 does not have another
2526	enable_if expression to continue evaluating, so the next round of evaluation has
2527	only a single candidate. In a call to g(1, 1), the call is ambiguous even though
2528	#2 has more enable_if attributes, because the first enable_if expressions are
2529	not ODR-equivalent.
2530
2531	Query for this feature with ``__has_attribute(enable_if)``.
2532
2533	Note that functions with one or more ``enable_if`` attributes may not have
2534	their address taken, unless all of the conditions specified by said
2535	``enable_if`` are constants that evaluate to ``true``. For example:
2536
2537	.. code-block:: c
2538
2539	const int TrueConstant = 1;
2540	const int FalseConstant = 0;
2541	int f(int a) __attribute__((enable_if(a > 0, "")));
2542	int g(int a) __attribute__((enable_if(a == 0 \|\| a != 0, "")));
2543	int h(int a) __attribute__((enable_if(1, "")));
2544	int i(int a) __attribute__((enable_if(TrueConstant, "")));
2545	int j(int a) __attribute__((enable_if(FalseConstant, "")));
2546
2547	void fn() {
2548	int (*ptr)(int);
2549	ptr = &f; // error: 'a > 0' is not always true
2550	ptr = &g; // error: 'a == 0 \|\| a != 0' is not a truthy constant
2551	ptr = &h; // OK: 1 is a truthy constant
2552	ptr = &i; // OK: 'TrueConstant' is a truthy constant
2553	ptr = &j; // error: 'FalseConstant' is a constant, but not truthy
2554	}
2555
2556	Because ``enable_if`` evaluation happens during overload resolution,
2557	``enable_if`` may give unintuitive results when used with templates, depending
2558	on when overloads are resolved. In the example below, clang will emit a
2559	diagnostic about no viable overloads for ``foo`` in ``bar``, but not in ``baz``:
2560
2561	.. code-block:: c++
2562
2563	double foo(int i) __attribute__((enable_if(i > 0, "")));
2564	void *foo(int i) __attribute__((enable_if(i <= 0, "")));
2565	template <int I>
2566	auto bar() { return foo(I); }
2567
2568	template <typename T>
2569	auto baz() { return foo(T::number); }
2570
2571	struct WithNumber { constexpr static int number = 1; };
2572	void callThem() {
2573	bar<sizeof(WithNumber)>();
2574	baz<WithNumber>();
2575	}
2576
2577	This is because, in ``bar``, ``foo`` is resolved prior to template
2578	instantiation, so the value for ``I`` isn't known (thus, both ``enable_if``
2579	conditions for ``foo`` fail). However, in ``baz``, ``foo`` is resolved during
2580	template instantiation, so the value for ``T::number`` is known.)reST";
2581
2582	static const char AttrDoc_EnforceTCB[] = R"reST(The ``enforce_tcb`` attribute can be placed on functions to enforce that a
2583	trusted compute base (TCB) does not call out of the TCB. This generates a
2584	warning every time a function not marked with an ``enforce_tcb`` attribute is
2585	called from a function with the ``enforce_tcb`` attribute. A function may be a
2586	part of multiple TCBs. Invocations through function pointers are currently
2587	not checked. Builtins are considered to a part of every TCB.
2588
2589	- ``enforce_tcb(Name)`` indicates that this function is a part of the TCB named ``Name``)reST";
2590
2591	static const char AttrDoc_EnforceTCBLeaf[] = R"reST(The ``enforce_tcb_leaf`` attribute satisfies the requirement enforced by
2592	``enforce_tcb`` for the marked function to be in the named TCB but does not
2593	continue to check the functions called from within the leaf function.
2594
2595	- ``enforce_tcb_leaf(Name)`` indicates that this function is a part of the TCB named ``Name``)reST";
2596
2597	static const char AttrDoc_EnumExtensibility[] = R"reST(Attribute ``enum_extensibility`` is used to distinguish between enum definitions
2598	that are extensible and those that are not. The attribute can take either
2599	``closed`` or ``open`` as an argument. ``closed`` indicates a variable of the
2600	enum type takes a value that corresponds to one of the enumerators listed in the
2601	enum definition or, when the enum is annotated with ``flag_enum``, a value that
2602	can be constructed using values corresponding to the enumerators. ``open``
2603	indicates a variable of the enum type can take any values allowed by the
2604	standard and instructs clang to be more lenient when issuing warnings.
2605
2606	.. code-block:: c
2607
2608	enum __attribute__((enum_extensibility(closed))) ClosedEnum {
2609	A0, A1
2610	};
2611
2612	enum __attribute__((enum_extensibility(open))) OpenEnum {
2613	B0, B1
2614	};
2615
2616	enum __attribute__((enum_extensibility(closed),flag_enum)) ClosedFlagEnum {
2617	C0 = 1 << 0, C1 = 1 << 1
2618	};
2619
2620	enum __attribute__((enum_extensibility(open),flag_enum)) OpenFlagEnum {
2621	D0 = 1 << 0, D1 = 1 << 1
2622	};
2623
2624	void foo1() {
2625	enum ClosedEnum ce;
2626	enum OpenEnum oe;
2627	enum ClosedFlagEnum cfe;
2628	enum OpenFlagEnum ofe;
2629
2630	ce = A1; // no warnings
2631	ce = 100; // warning issued
2632	oe = B1; // no warnings
2633	oe = 100; // no warnings
2634	cfe = C0 \| C1; // no warnings
2635	cfe = C0 \| C1 \| 4; // warning issued
2636	ofe = D0 \| D1; // no warnings
2637	ofe = D0 \| D1 \| 4; // no warnings
2638	})reST";
2639
2640	static const char AttrDoc_Error[] = R"reST(The ``error`` and ``warning`` function attributes can be used to specify a
2641	custom diagnostic to be emitted when a call to such a function is not
2642	eliminated via optimizations. This can be used to create compile time
2643	assertions that depend on optimizations, while providing diagnostics
2644	pointing to precise locations of the call site in the source.
2645
2646	.. code-block:: c++
2647
2648	__attribute__((warning("oh no"))) void dontcall();
2649	void foo() {
2650	if (someCompileTimeAssertionThatsTrue)
2651	dontcall(); // Warning
2652
2653	dontcall(); // Warning
2654
2655	if (someCompileTimeAssertionThatsFalse)
2656	dontcall(); // No Warning
2657	sizeof(dontcall()); // No Warning
2658	})reST";
2659
2660	static const char AttrDoc_ExcludeFromExplicitInstantiation[] = R"reST(The ``exclude_from_explicit_instantiation`` attribute opts-out a member of a
2661	class template from being part of explicit template instantiations of that
2662	class template. This means that an explicit instantiation will not instantiate
2663	members of the class template marked with the attribute, but also that code
2664	where an extern template declaration of the enclosing class template is visible
2665	will not take for granted that an external instantiation of the class template
2666	would provide those members (which would otherwise be a link error, since the
2667	explicit instantiation won't provide those members). For example, let's say we
2668	don't want the ``data()`` method to be part of libc++'s ABI. To make sure it
2669	is not exported from the dylib, we give it hidden visibility:
2670
2671	.. code-block:: c++
2672
2673	// in <string>
2674	template <class CharT>
2675	class basic_string {
2676	public:
2677	__attribute__((__visibility__("hidden")))
2678	const value_type* data() const noexcept { ... }
2679	};
2680
2681	template class basic_string<char>;
2682
2683	Since an explicit template instantiation declaration for ``basic_string<char>``
2684	is provided, the compiler is free to assume that ``basic_string<char>::data()``
2685	will be provided by another translation unit, and it is free to produce an
2686	external call to this function. However, since ``data()`` has hidden visibility
2687	and the explicit template instantiation is provided in a shared library (as
2688	opposed to simply another translation unit), ``basic_string<char>::data()``
2689	won't be found and a link error will ensue. This happens because the compiler
2690	assumes that ``basic_string<char>::data()`` is part of the explicit template
2691	instantiation declaration, when it really isn't. To tell the compiler that
2692	``data()`` is not part of the explicit template instantiation declaration, the
2693	``exclude_from_explicit_instantiation`` attribute can be used:
2694
2695	.. code-block:: c++
2696
2697	// in <string>
2698	template <class CharT>
2699	class basic_string {
2700	public:
2701	__attribute__((__visibility__("hidden")))
2702	__attribute__((exclude_from_explicit_instantiation))
2703	const value_type* data() const noexcept { ... }
2704	};
2705
2706	template class basic_string<char>;
2707
2708	Now, the compiler won't assume that ``basic_string<char>::data()`` is provided
2709	externally despite there being an explicit template instantiation declaration:
2710	the compiler will implicitly instantiate ``basic_string<char>::data()`` in the
2711	TUs where it is used.
2712
2713	This attribute can be used on static and non-static member functions of class
2714	templates, static data members of class templates and member classes of class
2715	templates.)reST";
2716
2717	static const char AttrDoc_ExclusiveTrylockFunction[] = R"reST(No documentation.)reST";
2718
2719	static const char AttrDoc_ExternalSourceSymbol[] = R"reST(The ``external_source_symbol`` attribute specifies that a declaration originates
2720	from an external source and describes the nature of that source.
2721
2722	The fact that Clang is capable of recognizing declarations that were defined
2723	externally can be used to provide better tooling support for mixed-language
2724	projects or projects that rely on auto-generated code. For instance, an IDE that
2725	uses Clang and that supports mixed-language projects can use this attribute to
2726	provide a correct 'jump-to-definition' feature. For a concrete example,
2727	consider a protocol that's defined in a Swift file:
2728
2729	.. code-block:: swift
2730
2731	@objc public protocol SwiftProtocol {
2732	func method()
2733	}
2734
2735	This protocol can be used from Objective-C code by including a header file that
2736	was generated by the Swift compiler. The declarations in that header can use
2737	the ``external_source_symbol`` attribute to make Clang aware of the fact
2738	that ``SwiftProtocol`` actually originates from a Swift module:
2739
2740	.. code-block:: objc
2741
2742	__attribute__((external_source_symbol(language="Swift",defined_in="module")))
2743	@protocol SwiftProtocol
2744	@required
2745	- (void) method;
2746	@end
2747
2748	Consequently, when 'jump-to-definition' is performed at a location that
2749	references ``SwiftProtocol``, the IDE can jump to the original definition in
2750	the Swift source file rather than jumping to the Objective-C declaration in the
2751	auto-generated header file.
2752
2753	The ``external_source_symbol`` attribute is a comma-separated list that includes
2754	clauses that describe the origin and the nature of the particular declaration.
2755	Those clauses can be:
2756
2757	language=\ string-literal
2758	The name of the source language in which this declaration was defined.
2759
2760	defined_in=\ string-literal
2761	The name of the source container in which the declaration was defined. The
2762	exact definition of source container is language-specific, e.g. Swift's
2763	source containers are modules, so ``defined_in`` should specify the Swift
2764	module name.
2765
2766	USR=\ string-literal
2767	String that specifies a unified symbol resolution (USR) value for this
2768	declaration. USR string uniquely identifies this particular declaration, and
2769	is typically used when constructing an index of a codebase.
2770	The USR value in this attribute is expected to be generated by an external
2771	compiler that compiled the native declaration using its original source
2772	language. The exact format of the USR string and its other attributes
2773	are determined by the specification of this declaration's source language.
2774	When not specified, Clang's indexer will use the Clang USR for this symbol.
2775	User can query to see if Clang supports the use of the ``USR`` clause in
2776	the ``external_source_symbol`` attribute with
2777	``__has_attribute(external_source_symbol) >= 20230206``.
2778
2779	generated_declaration
2780	This declaration was automatically generated by some tool.
2781
2782	The clauses can be specified in any order. The clauses that are listed above are
2783	all optional, but the attribute has to have at least one clause.)reST";
2784
2785	static const char AttrDoc_FallThrough[] = R"reST(The ``fallthrough`` (or ``clang::fallthrough``) attribute is used
2786	to annotate intentional fall-through
2787	between switch labels. It can only be applied to a null statement placed at a
2788	point of execution between any statement and the next switch label. It is
2789	common to mark these places with a specific comment, but this attribute is
2790	meant to replace comments with a more strict annotation, which can be checked
2791	by the compiler. This attribute doesn't change semantics of the code and can
2792	be used wherever an intended fall-through occurs. It is designed to mimic
2793	control-flow statements like ``break;``, so it can be placed in most places
2794	where ``break;`` can, but only if there are no statements on the execution path
2795	between it and the next switch label.
2796
2797	By default, Clang does not warn on unannotated fallthrough from one ``switch``
2798	case to another. Diagnostics on fallthrough without a corresponding annotation
2799	can be enabled with the ``-Wimplicit-fallthrough`` argument.
2800
2801	Here is an example:
2802
2803	.. code-block:: c++
2804
2805	// compile with -Wimplicit-fallthrough
2806	switch (n) {
2807	case 22:
2808	case 33: // no warning: no statements between case labels
2809	f();
2810	case 44: // warning: unannotated fall-through
2811	g();
2812	[[clang::fallthrough]];
2813	case 55: // no warning
2814	if (x) {
2815	h();
2816	break;
2817	}
2818	else {
2819	i();
2820	[[clang::fallthrough]];
2821	}
2822	case 66: // no warning
2823	p();
2824	[[clang::fallthrough]]; // warning: fallthrough annotation does not
2825	// directly precede case label
2826	q();
2827	case 77: // warning: unannotated fall-through
2828	r();
2829	})reST";
2830
2831	static const char AttrDoc_FastCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
2832	function to use ECX and EDX as register parameters and clear parameters off of
2833	the stack on return. This convention does not support variadic calls or
2834	unprototyped functions in C, and has no effect on x86_64 targets. This calling
2835	convention is supported primarily for compatibility with existing code. Users
2836	seeking register parameters should use the ``regparm`` attribute, which does
2837	not require callee-cleanup. See the documentation for `__fastcall`_ on MSDN.
2838
2839	.. _`__fastcall`: http://msdn.microsoft.com/en-us/library/6xa169sk.aspx)reST";
2840
2841	static const char AttrDoc_Final[] = R"reST()reST";
2842
2843	static const char AttrDoc_FlagEnum[] = R"reST(This attribute can be added to an enumerator to signal to the compiler that it
2844	is intended to be used as a flag type. This will cause the compiler to assume
2845	that the range of the type includes all of the values that you can get by
2846	manipulating bits of the enumerator when issuing warnings.)reST";
2847
2848	static const char AttrDoc_Flatten[] = R"reST(The ``flatten`` attribute causes calls within the attributed function to
2849	be inlined unless it is impossible to do so, for example if the body of the
2850	callee is unavailable or if the callee has the ``noinline`` attribute.)reST";
2851
2852	static const char AttrDoc_Format[] = R"reST(Clang supports the ``format`` attribute, which indicates that the function
2853	accepts (among other possibilities) a ``printf`` or ``scanf``-like format string
2854	and corresponding arguments or a ``va_list`` that contains these arguments.
2855
2856	Please see `GCC documentation about format attribute
2857	<http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>`_ to find details
2858	about attribute syntax.
2859
2860	Clang implements two kinds of checks with this attribute.
2861
2862	#. Clang checks that the function with the ``format`` attribute is called with
2863	a format string that uses format specifiers that are allowed, and that
2864	arguments match the format string. This is the ``-Wformat`` warning, it is
2865	on by default.
2866
2867	#. Clang checks that the format string argument is a literal string. This is
2868	the ``-Wformat-nonliteral`` warning, it is off by default.
2869
2870	Clang implements this mostly the same way as GCC, but there is a difference
2871	for functions that accept a ``va_list`` argument (for example, ``vprintf``).
2872	GCC does not emit ``-Wformat-nonliteral`` warning for calls to such
2873	functions. Clang does not warn if the format string comes from a function
2874	parameter, where the function is annotated with a compatible attribute,
2875	otherwise it warns. For example:
2876
2877	.. code-block:: c
2878
2879	__attribute__((__format__ (__scanf__, 1, 3)))
2880	void foo(const char* s, char *buf, ...) {
2881	va_list ap;
2882	va_start(ap, buf);
2883
2884	vprintf(s, ap); // warning: format string is not a string literal
2885	}
2886
2887	In this case we warn because ``s`` contains a format string for a
2888	``scanf``-like function, but it is passed to a ``printf``-like function.
2889
2890	If the attribute is removed, clang still warns, because the format string is
2891	not a string literal.
2892
2893	Another example:
2894
2895	.. code-block:: c
2896
2897	__attribute__((__format__ (__printf__, 1, 3)))
2898	void foo(const char* s, char *buf, ...) {
2899	va_list ap;
2900	va_start(ap, buf);
2901
2902	vprintf(s, ap); // warning
2903	}
2904
2905	In this case Clang does not warn because the format string ``s`` and
2906	the corresponding arguments are annotated. If the arguments are
2907	incorrect, the caller of ``foo`` will receive a warning.
2908
2909	As an extension to GCC's behavior, Clang accepts the ``format`` attribute on
2910	non-variadic functions. Clang checks non-variadic format functions for the same
2911	classes of issues that can be found on variadic functions, as controlled by the
2912	same warning flags, except that the types of formatted arguments is forced by
2913	the function signature. For example:
2914
2915	.. code-block:: c
2916
2917	__attribute__((__format__(__printf__, 1, 2)))
2918	void fmt(const char s, const char a, int b);
2919
2920	void bar(void) {
2921	fmt("%s %i", "hello", 123); // OK
2922	fmt("%i %g", "hello", 123); // warning: arguments don't match format
2923	extern const char *fmt;
2924	fmt(fmt, "hello", 123); // warning: format string is not a string literal
2925	}
2926
2927	When using the format attribute on a variadic function, the first data parameter
2928	_must_ be the index of the ellipsis in the parameter list. Clang will generate
2929	a diagnostic otherwise, as it wouldn't be possible to forward that argument list
2930	to `printf`-family functions. For instance, this is an error:
2931
2932	.. code-block:: c
2933
2934	__attribute__((__format__(__printf__, 1, 2)))
2935	void fmt(const char *s, int b, ...);
2936	// ^ error: format attribute parameter 3 is out of bounds
2937	// (must be __printf__, 1, 3)
2938
2939	Using the ``format`` attribute on a non-variadic function emits a GCC
2940	compatibility diagnostic.)reST";
2941
2942	static const char AttrDoc_FormatArg[] = R"reST(No documentation.)reST";
2943
2944	static const char AttrDoc_FunctionReturnThunks[] = R"reST(The attribute ``function_return`` can replace return instructions with jumps to
2945	target-specific symbols. This attribute supports 2 possible values,
2946	corresponding to the values supported by the ``-mfunction-return=`` command
2947	line flag:
2948
2949	* ``__attribute__((function_return("keep")))`` to disable related transforms.
2950	This is useful for undoing global setting from ``-mfunction-return=`` locally
2951	for individual functions.
2952	* ``__attribute__((function_return("thunk-extern")))`` to replace returns with
2953	jumps, while NOT emitting the thunk.
2954
2955	The values ``thunk`` and ``thunk-inline`` from GCC are not supported.
2956
2957	The symbol used for ``thunk-extern`` is target specific:
2958	* X86: ``__x86_return_thunk``
2959
2960	As such, this function attribute is currently only supported on X86 targets.)reST";
2961
2962	static const char AttrDoc_GNUInline[] = R"reST(The ``gnu_inline`` changes the meaning of ``extern inline`` to use GNU inline
2963	semantics, meaning:
2964
2965	* If any declaration that is declared ``inline`` is not declared ``extern``,
2966	then the ``inline`` keyword is just a hint. In particular, an out-of-line
2967	definition is still emitted for a function with external linkage, even if all
2968	call sites are inlined, unlike in C99 and C++ inline semantics.
2969
2970	* If all declarations that are declared ``inline`` are also declared
2971	``extern``, then the function body is present only for inlining and no
2972	out-of-line version is emitted.
2973
2974	Some important consequences: ``static inline`` emits an out-of-line
2975	version if needed, a plain ``inline`` definition emits an out-of-line version
2976	always, and an ``extern inline`` definition (in a header) followed by a
2977	(non-``extern``) ``inline`` declaration in a source file emits an out-of-line
2978	version of the function in that source file but provides the function body for
2979	inlining to all includers of the header.
2980
2981	Either ``__GNUC_GNU_INLINE__`` (GNU inline semantics) or
2982	``__GNUC_STDC_INLINE__`` (C99 semantics) will be defined (they are mutually
2983	exclusive). If ``__GNUC_STDC_INLINE__`` is defined, then the ``gnu_inline``
2984	function attribute can be used to get GNU inline semantics on a per function
2985	basis. If ``__GNUC_GNU_INLINE__`` is defined, then the translation unit is
2986	already being compiled with GNU inline semantics as the implied default. It is
2987	unspecified which macro is defined in a C++ compilation.
2988
2989	GNU inline semantics are the default behavior with ``-std=gnu89``,
2990	``-std=c89``, ``-std=c94``, or ``-fgnu89-inline``.)reST";
2991
2992	static const char AttrDoc_GuardedBy[] = R"reST(No documentation.)reST";
2993
2994	static const char AttrDoc_GuardedVar[] = R"reST(No documentation.)reST";
2995
2996	static const char AttrDoc_HIPManaged[] = R"reST(The ``__managed__`` attribute can be applied to a global variable declaration in HIP.
2997	A managed variable is emitted as an undefined global symbol in the device binary and is
2998	registered by ``__hipRegisterManagedVariable`` in init functions. The HIP runtime allocates
2999	managed memory and uses it to define the symbol when loading the device binary.
3000	A managed variable can be accessed in both device and host code.)reST";
3001
3002	static const char AttrDoc_HLSLGroupSharedAddressSpace[] = R"reST(HLSL enables threads of a compute shader to exchange values via shared memory.
3003	HLSL provides barrier primitives such as GroupMemoryBarrierWithGroupSync,
3004	and so on to ensure the correct ordering of reads and writes to shared memory
3005	in the shader and to avoid data races.
3006	Here's an example to declare a groupshared variable.
3007	.. code-block:: c++
3008
3009	groupshared GSData data[551];
3010
3011	The full documentation is available here: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-syntax#group-shared)reST";
3012
3013	static const char AttrDoc_HLSLLoopHint[] = R"reST(The ``[loop]`` directive allows loop optimization hints to be
3014	specified for the subsequent loop. The directive allows unrolling to
3015	be disabled and is not compatible with [unroll(x)].
3016
3017	Specifying the parameter, ``[loop]``, directs the
3018	unroller to not unroll the loop.
3019
3020	.. code-block:: hlsl
3021
3022	[loop]
3023	for (...) {
3024	...
3025	}
3026
3027	.. code-block:: hlsl
3028
3029	[loop]
3030	while (...) {
3031	...
3032	}
3033
3034	.. code-block:: hlsl
3035
3036	[loop]
3037	do {
3038	...
3039	} while (...)
3040
3041	See `hlsl loop extensions <https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-for>`_
3042	for details.)reST";
3043
3044	static const char AttrDoc_HLSLNumThreads[] = R"reST(The ``numthreads`` attribute applies to HLSL shaders where explcit thread counts
3045	are required. The ``X``, ``Y``, and ``Z`` values provided to the attribute
3046	dictate the thread id. Total number of threads executed is ``X * Y * Z``.
3047
3048	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sm5-attributes-numthreads)reST";
3049
3050	static const char AttrDoc_HLSLPackOffset[] = R"reST(The packoffset attribute is used to change the layout of a cbuffer.
3051	Attribute spelling in HLSL is: ``packoffset( c[Subcomponent][.component] )``.
3052	A subcomponent is a register number, which is an integer. A component is in the form of [.xyzw].
3053
3054	Examples:
3055
3056	.. code-block:: hlsl
3057
3058	cbuffer A {
3059	float3 a : packoffset(c0.y);
3060	float4 b : packoffset(c4);
3061	}
3062
3063	The full documentation is available here: https://learn.microsoft.com/en-us/windows/win32/direct3dhlsl/dx-graphics-hlsl-variable-packoffset)reST";
3064
3065	static const char AttrDoc_HLSLParamModifier[] = R"reST(HLSL function parameters are passed by value. Parameter declarations support
3066	three qualifiers to denote parameter passing behavior. The three qualifiers are
3067	`in`, `out` and `inout`.
3068
3069	Parameters annotated with `in` or with no annotation are passed by value from
3070	the caller to the callee.
3071
3072	Parameters annotated with `out` are written to the argument after the callee
3073	returns (Note: arguments values passed into `out` parameters are not copied
3074	into the callee).
3075
3076	Parameters annotated with `inout` are copied into the callee via a temporary,
3077	and copied back to the argument after the callee returns.)reST";
3078
3079	static const char AttrDoc_HLSLResource[] = R"reST()reST";
3080
3081	static const char AttrDoc_HLSLResourceBinding[] = R"reST(The resource binding attribute sets the virtual register and logical register space for a resource.
3082	Attribute spelling in HLSL is: ``register(slot [, space])``.
3083	``slot`` takes the format ``[type][number]``,
3084	where ``type`` is a single character specifying the resource type and ``number`` is the virtual register number.
3085
3086	Register types are:
3087	t for shader resource views (SRV),
3088	s for samplers,
3089	u for unordered access views (UAV),
3090	b for constant buffer views (CBV).
3091
3092	Register space is specified in the format ``space[number]`` and defaults to ``space0`` if omitted.
3093	Here're resource binding examples with and without space:
3094
3095	.. code-block:: hlsl
3096
3097	RWBuffer<float> Uav : register(u3, space1);
3098	Buffer<float> Buf : register(t1);
3099
3100	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl)reST";
3101
3102	static const char AttrDoc_HLSLResourceClass[] = R"reST()reST";
3103
3104	static const char AttrDoc_HLSLSV_DispatchThreadID[] = R"reST(The ``SV_DispatchThreadID`` semantic, when applied to an input parameter,
3105	specifies a data binding to map the global thread offset within the Dispatch
3106	call (per dimension of the group) to the specified parameter.
3107	When applied to a field of a struct, the data binding is specified to the field
3108	when the struct is used as a parameter type.
3109	The semantic on the field is ignored when not used as a parameter.
3110	This attribute is only supported in compute shaders.
3111
3112	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sv-dispatchthreadid)reST";
3113
3114	static const char AttrDoc_HLSLSV_GroupIndex[] = R"reST(The ``SV_GroupIndex`` semantic, when applied to an input parameter, specifies a
3115	data binding to map the group index to the specified parameter. This attribute
3116	is only supported in compute shaders.
3117
3118	The full documentation is available here: https://docs.microsoft.com/en-us/windows/win32/direct3dhlsl/sv-groupindex)reST";
3119
3120	static const char AttrDoc_HLSLShader[] = R"reST(The ``shader`` type attribute applies to HLSL shader entry functions to
3121	identify the shader type for the entry function.
3122	The syntax is:
3123
3124	.. code-block:: text
3125
3126	``[shader(string-literal)]``
3127
3128	where the string literal is one of: "pixel", "vertex", "geometry", "hull",
3129	"domain", "compute", "raygeneration", "intersection", "anyhit", "closesthit",
3130	"miss", "callable", "mesh", "amplification". Normally the shader type is set
3131	by shader target with the ``-T`` option like ``-Tps_6_1``. When compiling to a
3132	library target like ``lib_6_3``, the shader type attribute can help the
3133	compiler to identify the shader type. It is mostly used by Raytracing shaders
3134	where shaders must be compiled into a library and linked at runtime.)reST";
3135
3136	static const char AttrDoc_Hot[] = R"reST(``__attribute__((hot))`` marks a function as hot, as a manual alternative to PGO hotness data.
3137	If PGO data is available, the annotation ``__attribute__((hot))`` overrides the profile count based hotness (unlike ``__attribute__((cold))``).)reST";
3138
3139	static const char AttrDoc_HybridPatchable[] = R"reST(The ``hybrid_patchable`` attribute declares an ARM64EC function with an additional
3140	x86-64 thunk, which may be patched at runtime.
3141
3142	For more information see
3143	`ARM64EC ABI documentation <https://learn.microsoft.com/en-us/windows/arm/arm64ec-abi>`_.)reST";
3144
3145	static const char AttrDoc_IBAction[] = R"reST(No documentation.)reST";
3146
3147	static const char AttrDoc_IBOutlet[] = R"reST(No documentation.)reST";
3148
3149	static const char AttrDoc_IBOutletCollection[] = R"reST(No documentation.)reST";
3150
3151	static const char AttrDoc_IFunc[] = R"reST(``__attribute__((ifunc("resolver")))`` is used to mark that the address of a
3152	declaration should be resolved at runtime by calling a resolver function.
3153
3154	The symbol name of the resolver function is given in quotes. A function with
3155	this name (after mangling) must be defined in the current translation unit; it
3156	may be ``static``. The resolver function should return a pointer.
3157
3158	The ``ifunc`` attribute may only be used on a function declaration. A function
3159	declaration with an ``ifunc`` attribute is considered to be a definition of the
3160	declared entity. The entity must not have weak linkage; for example, in C++,
3161	it cannot be applied to a declaration if a definition at that location would be
3162	considered inline.
3163
3164	Not all targets support this attribute. ELF target support depends on both the
3165	linker and runtime linker, and is available in at least lld 4.0 and later,
3166	binutils 2.20.1 and later, glibc v2.11.1 and later, and FreeBSD 9.1 and later.
3167	Mach-O targets support it, but with slightly different semantics: the resolver
3168	is run at first call, instead of at load time by the runtime linker. Targets
3169	other than ELF and Mach-O currently do not support this attribute.)reST";
3170
3171	static const char AttrDoc_InitPriority[] = R"reST(In C++, the order in which global variables are initialized across translation
3172	units is unspecified, unlike the ordering within a single translation unit. The
3173	``init_priority`` attribute allows you to specify a relative ordering for the
3174	initialization of objects declared at namespace scope in C++. The priority is
3175	given as an integer constant expression between 101 and 65535 (inclusive).
3176	Priorities outside of that range are reserved for use by the implementation. A
3177	lower value indicates a higher priority of initialization. Note that only the
3178	relative ordering of values is important. For example:
3179
3180	.. code-block:: c++
3181
3182	struct SomeType { SomeType(); };
3183	__attribute__((init_priority(200))) SomeType Obj1;
3184	__attribute__((init_priority(101))) SomeType Obj2;
3185
3186	``Obj2`` will be initialized before ``Obj1`` despite the usual order of
3187	initialization being the opposite.
3188
3189	On Windows, ``init_seg(compiler)`` is represented with a priority of 200 and
3190	``init_seg(library)`` is represented with a priority of 400. ``init_seg(user)``
3191	uses the default 65535 priority.
3192
3193	This attribute is only supported for C++ and Objective-C++ and is ignored in
3194	other language modes. Currently, this attribute is not implemented on z/OS.)reST";
3195
3196	static const char AttrDoc_InitSeg[] = R"reST(The attribute applied by ``pragma init_seg()`` controls the section into
3197	which global initialization function pointers are emitted. It is only
3198	available with ``-fms-extensions``. Typically, this function pointer is
3199	emitted into ``.CRT$XCU`` on Windows. The user can change the order of
3200	initialization by using a different section name with the same
3201	``.CRT$XC`` prefix and a suffix that sorts lexicographically before or
3202	after the standard ``.CRT$XCU`` sections. See the init_seg_
3203	documentation on MSDN for more information.
3204
3205	.. _init_seg: http://msdn.microsoft.com/en-us/library/7977wcck(v=vs.110).aspx)reST";
3206
3207	static const char AttrDoc_IntelOclBicc[] = R"reST(No documentation.)reST";
3208
3209	static const char AttrDoc_InternalLinkage[] = R"reST(The ``internal_linkage`` attribute changes the linkage type of the declaration
3210	to internal. This is similar to C-style ``static``, but can be used on classes
3211	and class methods. When applied to a class definition, this attribute affects
3212	all methods and static data members of that class. This can be used to contain
3213	the ABI of a C++ library by excluding unwanted class methods from the export
3214	tables.)reST";
3215
3216	static const char AttrDoc_LTOVisibilityPublic[] = R"reST(See :doc:`LTOVisibility`.)reST";
3217
3218	static const char AttrDoc_LayoutVersion[] = R"reST(The layout_version attribute requests that the compiler utilize the class
3219	layout rules of a particular compiler version.
3220	This attribute only applies to struct, class, and union types.
3221	It is only supported when using the Microsoft C++ ABI.)reST";
3222
3223	static const char AttrDoc_Leaf[] = R"reST(The ``leaf`` attribute is used as a compiler hint to improve dataflow analysis
3224	in library functions. Functions marked with the ``leaf`` attribute are not allowed
3225	to jump back into the caller's translation unit, whether through invoking a
3226	callback function, an external function call, use of ``longjmp``, or other means.
3227	Therefore, they cannot use or modify any data that does not escape the caller function's
3228	compilation unit.
3229
3230	For more information see
3231	`gcc documentation <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html>`)reST";
3232
3233	static const char AttrDoc_LifetimeBound[] = R"reST(The ``lifetimebound`` attribute on a function parameter or implicit object
3234	parameter indicates that objects that are referred to by that parameter may
3235	also be referred to by the return value of the annotated function (or, for a
3236	parameter of a constructor, by the value of the constructed object). It is only
3237	supported in C++.
3238
3239	By default, a reference is considered to refer to its referenced object, a
3240	pointer is considered to refer to its pointee, a ``std::initializer_list<T>``
3241	is considered to refer to its underlying array, and aggregates (arrays and
3242	simple ``struct``\s) are considered to refer to all objects that their
3243	transitive subobjects refer to.
3244
3245	Clang warns if it is able to detect that an object or reference refers to
3246	another object with a shorter lifetime. For example, Clang will warn if a
3247	function returns a reference to a local variable, or if a reference is bound to
3248	a temporary object whose lifetime is not extended. By using the
3249	``lifetimebound`` attribute, this determination can be extended to look through
3250	user-declared functions. For example:
3251
3252	.. code-block:: c++
3253
3254	// Returns m[key] if key is present, or default_value if not.
3255	template<typename T, typename U>
3256	const U &get_or_default(const std::map<T, U> &m [[clang::lifetimebound]],
3257	const T &key, /* note, not lifetimebound */
3258	const U &default_value [[clang::lifetimebound]]);
3259
3260	std::map<std::string, std::string> m;
3261	// warning: temporary "bar"s that might be bound to local reference 'val'
3262	// will be destroyed at the end of the full-expression
3263	const std::string &val = get_or_default(m, "foo"s, "bar"s);
3264
3265	// No warning in this case.
3266	std::string def_val = "bar"s;
3267	const std::string &val = get_or_default(m, "foo"s, def_val);
3268
3269	The attribute can be applied to the implicit ``this`` parameter of a member
3270	function by writing the attribute after the function type:
3271
3272	.. code-block:: c++
3273
3274	struct string {
3275	// The returned pointer should not outlive ``*this``.
3276	const char *data() const [[clang::lifetimebound]];
3277	};
3278
3279	This attribute is inspired by the C++ committee paper `P0936R0
3280	<http://wg21.link/p0936r0>`_, but does not affect whether temporary objects
3281	have their lifetimes extended.)reST";
3282
3283	static const char AttrDoc_Likely[] = R"reST(The ``likely`` and ``unlikely`` attributes are used as compiler hints.
3284	The attributes are used to aid the compiler to determine which branch is
3285	likely or unlikely to be taken. This is done by marking the branch substatement
3286	with one of the two attributes.
3287
3288	It isn't allowed to annotate a single statement with both ``likely`` and
3289	``unlikely``. Annotating the ``true`` and ``false`` branch of an ``if``
3290	statement with the same likelihood attribute will result in a diagnostic and
3291	the attributes are ignored on both branches.
3292
3293	In a ``switch`` statement it's allowed to annotate multiple ``case`` labels
3294	or the ``default`` label with the same likelihood attribute. This makes
3295	* all labels without an attribute have a neutral likelihood,
3296	* all labels marked ``[[likely]]`` have an equally positive likelihood, and
3297	* all labels marked ``[[unlikely]]`` have an equally negative likelihood.
3298	The neutral likelihood is the more likely of path execution than the negative
3299	likelihood. The positive likelihood is the more likely of path of execution
3300	than the neutral likelihood.
3301
3302	These attributes have no effect on the generated code when using
3303	PGO (Profile-Guided Optimization) or at optimization level 0.
3304
3305	In Clang, the attributes will be ignored if they're not placed on
3306	* the ``case`` or ``default`` label of a ``switch`` statement,
3307	* or on the substatement of an ``if`` or ``else`` statement,
3308	* or on the substatement of an ``for`` or ``while`` statement.
3309	The C++ Standard recommends to honor them on every statement in the
3310	path of execution, but that can be confusing:
3311
3312	.. code-block:: c++
3313
3314	if (b) {
3315	[[unlikely]] --b; // In the path of execution,
3316	// this branch is considered unlikely.
3317	}
3318
3319	if (b) {
3320	--b;
3321	if(b)
3322	return;
3323	[[unlikely]] --b; // Not in the path of execution,
3324	} // the branch has no likelihood information.
3325
3326	if (b) {
3327	--b;
3328	foo(b);
3329	// Whether or not the next statement is in the path of execution depends
3330	// on the declaration of foo():
3331	// In the path of execution: void foo(int);
3332	// Not in the path of execution: [[noreturn]] void foo(int);
3333	// This means the likelihood of the branch depends on the declaration
3334	// of foo().
3335	[[unlikely]] --b;
3336	}
3337
3338
3339	Below are some example usages of the likelihood attributes and their effects:
3340
3341	.. code-block:: c++
3342
3343	if (b) [[likely]] { // Placement on the first statement in the branch.
3344	// The compiler will optimize to execute the code here.
3345	} else {
3346	}
3347
3348	if (b)
3349	[[unlikely]] b++; // Placement on the first statement in the branch.
3350	else {
3351	// The compiler will optimize to execute the code here.
3352	}
3353
3354	if (b) {
3355	[[unlikely]] b++; // Placement on the second statement in the branch.
3356	} // The attribute will be ignored.
3357
3358	if (b) [[likely]] {
3359	[[unlikely]] b++; // No contradiction since the second attribute
3360	} // is ignored.
3361
3362	if (b)
3363	;
3364	else [[likely]] {
3365	// The compiler will optimize to execute the code here.
3366	}
3367
3368	if (b)
3369	;
3370	else
3371	// The compiler will optimize to execute the next statement.
3372	[[likely]] b = f();
3373
3374	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
3375	else [[likely]]; // and the attributes are ignored.
3376
3377	if (b)
3378	[[likely]] int i = 5; // Issues a diagnostic since the attribute
3379	// isn't allowed on a declaration.
3380
3381	switch (i) {
3382	[[likely]] case 1: // This value is likely
3383	...
3384	break;
3385
3386	[[unlikely]] case 2: // This value is unlikely
3387	...
3388	[[fallthrough]];
3389
3390	case 3: // No likelihood attribute
3391	...
3392	[[likely]] break; // No effect
3393
3394	case 4: [[likely]] { // attribute on substatement has no effect
3395	...
3396	break;
3397	}
3398
3399	[[unlikely]] default: // All other values are unlikely
3400	...
3401	break;
3402	}
3403
3404	switch (i) {
3405	[[likely]] case 0: // This value and code path is likely
3406	...
3407	[[fallthrough]];
3408
3409	case 1: // No likelihood attribute, code path is neutral
3410	break; // falling through has no effect on the likelihood
3411
3412	case 2: // No likelihood attribute, code path is neutral
3413	[[fallthrough]];
3414
3415	[[unlikely]] default: // This value and code path are both unlikely
3416	break;
3417	}
3418
3419	for(int i = 0; i != size; ++i) [[likely]] {
3420	... // The loop is the likely path of execution
3421	}
3422
3423	for(const auto &E : Elements) [[likely]] {
3424	... // The loop is the likely path of execution
3425	}
3426
3427	while(i != size) [[unlikely]] {
3428	... // The loop is the unlikely path of execution
3429	} // The generated code will optimize to skip the loop body
3430
3431	while(true) [[unlikely]] {
3432	... // The attribute has no effect
3433	} // Clang elides the comparison and generates an infinite
3434	// loop)reST";
3435
3436	static const char AttrDoc_LoaderUninitialized[] = R"reST(The ``loader_uninitialized`` attribute can be placed on global variables to
3437	indicate that the variable does not need to be zero initialized by the loader.
3438	On most targets, zero-initialization does not incur any additional cost.
3439	For example, most general purpose operating systems deliberately ensure
3440	that all memory is properly initialized in order to avoid leaking privileged
3441	information from the kernel or other programs. However, some targets
3442	do not make this guarantee, and on these targets, avoiding an unnecessary
3443	zero-initialization can have a significant impact on load times and/or code
3444	size.
3445
3446	A declaration with this attribute is a non-tentative definition just as if it
3447	provided an initializer. Variables with this attribute are considered to be
3448	uninitialized in the same sense as a local variable, and the programs must
3449	write to them before reading from them. If the variable's type is a C++ class
3450	type with a non-trivial default constructor, or an array thereof, this attribute
3451	only suppresses the static zero-initialization of the variable, not the dynamic
3452	initialization provided by executing the default constructor.)reST";
3453
3454	static const char AttrDoc_LockReturned[] = R"reST(No documentation.)reST";
3455
3456	static const char AttrDoc_LocksExcluded[] = R"reST(No documentation.)reST";
3457
3458	static const char AttrDoc_LoopHint[] = R"reST(The ``#pragma clang loop`` directive allows loop optimization hints to be
3459	specified for the subsequent loop. The directive allows pipelining to be
3460	disabled, or vectorization, vector predication, interleaving, and unrolling to
3461	be enabled or disabled. Vector width, vector predication, interleave count,
3462	unrolling count, and the initiation interval for pipelining can be explicitly
3463	specified. See `language extensions
3464	<http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>`_
3465	for details.)reST";
3466
3467	static const char AttrDoc_M68kInterrupt[] = R"reST(No documentation.)reST";
3468
3469	static const char AttrDoc_M68kRTD[] = R"reST(On M68k targets, this attribute changes the calling convention of a function
3470	to clear parameters off the stack on return. In other words, callee is
3471	responsible for cleaning out the stack space allocated for incoming paramters.
3472	This convention does not support variadic calls or unprototyped functions in C.
3473	When targeting M68010 or newer CPUs, this calling convention is implemented
3474	using the `rtd` instruction.)reST";
3475
3476	static const char AttrDoc_MIGServerRoutine[] = R"reST(The Mach Interface Generator release-on-success convention dictates
3477	functions that follow it to only release arguments passed to them when they
3478	return "success" (a ``kern_return_t`` error code that indicates that
3479	no errors have occurred). Otherwise the release is performed by the MIG client
3480	that called the function. The annotation ``__attribute__((mig_server_routine))``
3481	is applied in order to specify which functions are expected to follow the
3482	convention. This allows the Static Analyzer to find bugs caused by violations of
3483	that convention. The attribute would normally appear on the forward declaration
3484	of the actual server routine in the MIG server header, but it may also be
3485	added to arbitrary functions that need to follow the same convention - for
3486	example, a user can add them to auxiliary functions called by the server routine
3487	that have their return value of type ``kern_return_t`` unconditionally returned
3488	from the routine. The attribute can be applied to C++ methods, and in this case
3489	it will be automatically applied to overrides if the method is virtual. The
3490	attribute can also be written using C++11 syntax: ``[[mig::server_routine]]``.)reST";
3491
3492	static const char AttrDoc_MSABI[] = R"reST(On non-Windows x86_64 targets, this attribute changes the calling convention of
3493	a function to match the default convention used on Windows x86_64. This
3494	attribute has no effect on Windows targets or non-x86_64 targets.)reST";
3495
3496	static const char AttrDoc_MSAllocator[] = R"reST(The ``__declspec(allocator)`` attribute is applied to functions that allocate
3497	memory, such as operator new in C++. When CodeView debug information is emitted
3498	(enabled by ``clang -gcodeview`` or ``clang-cl /Z7``), Clang will attempt to
3499	record the code offset of heap allocation call sites in the debug info. It will
3500	also record the type being allocated using some local heuristics. The Visual
3501	Studio debugger uses this information to `profile memory usage`_.
3502
3503	.. _profile memory usage: https://docs.microsoft.com/en-us/visualstudio/profiling/memory-usage
3504
3505	This attribute does not affect optimizations in any way, unlike GCC's
3506	``__attribute__((malloc))``.)reST";
3507
3508	static const char AttrDoc_MSConstexpr[] = R"reST(The ``[[msvc::constexpr]]`` attribute can be applied only to a function
3509	definition or a ``return`` statement. It does not impact function declarations.
3510	A ``[[msvc::constexpr]]`` function cannot be ``constexpr`` or ``consteval``.
3511	A ``[[msvc::constexpr]]`` function is treated as if it were a ``constexpr`` function
3512	when it is evaluated in a constant context of ``[[msvc::constexpr]] return`` statement.
3513	Otherwise, it is treated as a regular function.
3514
3515	Semantics of this attribute are enabled only under MSVC compatibility
3516	(``-fms-compatibility-version``) 19.33 and later.)reST";
3517
3518	static const char AttrDoc_MSInheritance[] = R"reST(This collection of keywords is enabled under ``-fms-extensions`` and controls
3519	the pointer-to-member representation used on ``--win32`` targets.
3520
3521	The ``--win32`` targets utilize a pointer-to-member representation which
3522	varies in size and alignment depending on the definition of the underlying
3523	class.
3524
3525	However, this is problematic when a forward declaration is only available and
3526	no definition has been made yet. In such cases, Clang is forced to utilize the
3527	most general representation that is available to it.
3528
3529	These keywords make it possible to use a pointer-to-member representation other
3530	than the most general one regardless of whether or not the definition will ever
3531	be present in the current translation unit.
3532
3533	This family of keywords belong between the ``class-key`` and ``class-name``:
3534
3535	.. code-block:: c++
3536
3537	struct __single_inheritance S;
3538	int S::*i;
3539	struct S {};
3540
3541	This keyword can be applied to class templates but only has an effect when used
3542	on full specializations:
3543
3544	.. code-block:: c++
3545
3546	template <typename T, typename U> struct __single_inheritance A; // warning: inheritance model ignored on primary template
3547	template <typename T> struct __multiple_inheritance A<T, T>; // warning: inheritance model ignored on partial specialization
3548	template <> struct __single_inheritance A<int, float>;
3549
3550	Note that choosing an inheritance model less general than strictly necessary is
3551	an error:
3552
3553	.. code-block:: c++
3554
3555	struct __multiple_inheritance S; // error: inheritance model does not match definition
3556	int S::*i;
3557	struct S {};)reST";
3558
3559	static const char AttrDoc_MSNoVTable[] = R"reST(This attribute can be added to a class declaration or definition to signal to
3560	the compiler that constructors and destructors will not reference the virtual
3561	function table. It is only supported when using the Microsoft C++ ABI.)reST";
3562
3563	static const char AttrDoc_MSP430Interrupt[] = R"reST(No documentation.)reST";
3564
3565	static const char AttrDoc_MSStruct[] = R"reST(No documentation.)reST";
3566
3567	static const char AttrDoc_MSVtorDisp[] = R"reST()reST";
3568
3569	static const char AttrDoc_MaxFieldAlignment[] = R"reST()reST";
3570
3571	static const char AttrDoc_MayAlias[] = R"reST(No documentation.)reST";
3572
3573	static const char AttrDoc_MaybeUndef[] = R"reST(The ``maybe_undef`` attribute can be placed on a function parameter. It indicates
3574	that the parameter is allowed to use undef values. It informs the compiler
3575	to insert a freeze LLVM IR instruction on the function parameter.
3576	Please note that this is an attribute that is used as an internal
3577	implementation detail and not intended to be used by external users.
3578
3579	In languages HIP, CUDA etc., some functions have multi-threaded semantics and
3580	it is enough for only one or some threads to provide defined arguments.
3581	Depending on semantics, undef arguments in some threads don't produce
3582	undefined results in the function call. Since, these functions accept undefined
3583	arguments, ``maybe_undef`` attribute can be placed.
3584
3585	Sample usage:
3586	.. code-block:: c
3587
3588	void maybeundeffunc(int __attribute__((maybe_undef))param);)reST";
3589
3590	static const char AttrDoc_MicroMips[] = R"reST(Clang supports the GNU style ``__attribute__((micromips))`` and
3591	``__attribute__((nomicromips))`` attributes on MIPS targets. These attributes
3592	may be attached to a function definition and instructs the backend to generate
3593	or not to generate microMIPS code for that function.
3594
3595	These attributes override the ``-mmicromips`` and ``-mno-micromips`` options
3596	on the command line.)reST";
3597
3598	static const char AttrDoc_MinSize[] = R"reST(This function attribute indicates that optimization passes and code generator passes
3599	make choices that keep the function code size as small as possible. Optimizations may
3600	also sacrifice runtime performance in order to minimize the size of the generated code.)reST";
3601
3602	static const char AttrDoc_MinVectorWidth[] = R"reST(Clang supports the ``__attribute__((min_vector_width(width)))`` attribute. This
3603	attribute may be attached to a function and informs the backend that this
3604	function desires vectors of at least this width to be generated. Target-specific
3605	maximum vector widths still apply. This means even if you ask for something
3606	larger than the target supports, you will only get what the target supports.
3607	This attribute is meant to be a hint to control target heuristics that may
3608	generate narrower vectors than what the target hardware supports.
3609
3610	This is currently used by the X86 target to allow some CPUs that support 512-bit
3611	vectors to be limited to using 256-bit vectors to avoid frequency penalties.
3612	This is currently enabled with the ``-prefer-vector-width=256`` command line
3613	option. The ``min_vector_width`` attribute can be used to prevent the backend
3614	from trying to split vector operations to match the ``prefer-vector-width``. All
3615	X86 vector intrinsics from x86intrin.h already set this attribute. Additionally,
3616	use of any of the X86-specific vector builtins will implicitly set this
3617	attribute on the calling function. The intent is that explicitly writing vector
3618	code using the X86 intrinsics will prevent ``prefer-vector-width`` from
3619	affecting the code.)reST";
3620
3621	static const char AttrDoc_Mips16[] = R"reST(No documentation.)reST";
3622
3623	static const char AttrDoc_MipsInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt("ARGUMENT")))`` attribute on
3624	MIPS targets. This attribute may be attached to a function definition and instructs
3625	the backend to generate appropriate function entry/exit code so that it can be used
3626	directly as an interrupt service routine.
3627
3628	By default, the compiler will produce a function prologue and epilogue suitable for
3629	an interrupt service routine that handles an External Interrupt Controller (eic)
3630	generated interrupt. This behavior can be explicitly requested with the "eic"
3631	argument.
3632
3633	Otherwise, for use with vectored interrupt mode, the argument passed should be
3634	of the form "vector=LEVEL" where LEVEL is one of the following values:
3635	"sw0", "sw1", "hw0", "hw1", "hw2", "hw3", "hw4", "hw5". The compiler will
3636	then set the interrupt mask to the corresponding level which will mask all
3637	interrupts up to and including the argument.
3638
3639	The semantics are as follows:
3640
3641	- The prologue is modified so that the Exception Program Counter (EPC) and
3642	Status coprocessor registers are saved to the stack. The interrupt mask is
3643	set so that the function can only be interrupted by a higher priority
3644	interrupt. The epilogue will restore the previous values of EPC and Status.
3645
3646	- The prologue and epilogue are modified to save and restore all non-kernel
3647	registers as necessary.
3648
3649	- The FPU is disabled in the prologue, as the floating pointer registers are not
3650	spilled to the stack.
3651
3652	- The function return sequence is changed to use an exception return instruction.
3653
3654	- The parameter sets the interrupt mask for the function corresponding to the
3655	interrupt level specified. If no mask is specified the interrupt mask
3656	defaults to "eic".)reST";
3657
3658	static const char AttrDoc_MipsLongCall[] = R"reST(Clang supports the ``__attribute__((long_call))``, ``__attribute__((far))``,
3659	and ``__attribute__((near))`` attributes on MIPS targets. These attributes may
3660	only be added to function declarations and change the code generated
3661	by the compiler when directly calling the function. The ``near`` attribute
3662	allows calls to the function to be made using the ``jal`` instruction, which
3663	requires the function to be located in the same naturally aligned 256MB
3664	segment as the caller. The ``long_call`` and ``far`` attributes are synonyms
3665	and require the use of a different call sequence that works regardless
3666	of the distance between the functions.
3667
3668	These attributes have no effect for position-independent code.
3669
3670	These attributes take priority over command line switches such
3671	as ``-mlong-calls`` and ``-mno-long-calls``.)reST";
3672
3673	static const char AttrDoc_MipsShortCall[] = R"reST(Clang supports the ``__attribute__((long_call))``, ``__attribute__((far))``,
3674	``__attribute__((short__call))``, and ``__attribute__((near))`` attributes
3675	on MIPS targets. These attributes may only be added to function declarations
3676	and change the code generated by the compiler when directly calling
3677	the function. The ``short_call`` and ``near`` attributes are synonyms and
3678	allow calls to the function to be made using the ``jal`` instruction, which
3679	requires the function to be located in the same naturally aligned 256MB segment
3680	as the caller. The ``long_call`` and ``far`` attributes are synonyms and
3681	require the use of a different call sequence that works regardless
3682	of the distance between the functions.
3683
3684	These attributes have no effect for position-independent code.
3685
3686	These attributes take priority over command line switches such
3687	as ``-mlong-calls`` and ``-mno-long-calls``.)reST";
3688
3689	static const char AttrDoc_Mode[] = R"reST(No documentation.)reST";
3690
3691	static const char AttrDoc_MustTail[] = R"reST(If a ``return`` statement is marked ``musttail``, this indicates that the
3692	compiler must generate a tail call for the program to be correct, even when
3693	optimizations are disabled. This guarantees that the call will not cause
3694	unbounded stack growth if it is part of a recursive cycle in the call graph.
3695
3696	If the callee is a virtual function that is implemented by a thunk, there is
3697	no guarantee in general that the thunk tail-calls the implementation of the
3698	virtual function, so such a call in a recursive cycle can still result in
3699	unbounded stack growth.
3700
3701	``clang::musttail`` can only be applied to a ``return`` statement whose value
3702	is the result of a function call (even functions returning void must use
3703	``return``, although no value is returned). The target function must have the
3704	same number of arguments as the caller. The types of the return value and all
3705	arguments must be similar according to C++ rules (differing only in cv
3706	qualifiers or array size), including the implicit "this" argument, if any.
3707	Any variables in scope, including all arguments to the function and the
3708	return value must be trivially destructible. The calling convention of the
3709	caller and callee must match, and they must not be variadic functions or have
3710	old style K&R C function declarations.
3711
3712	``clang::musttail`` provides assurances that the tail call can be optimized on
3713	all targets, not just one.)reST";
3714
3715	static const char AttrDoc_NSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
3716	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
3717	convention (e.g. functions starting with "get" are assumed to return at
3718	``+0``).
3719
3720	It can be overridden using a family of the following attributes. In
3721	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
3722	a function communicates that the object is returned at ``+1``, and the caller
3723	is responsible for freeing it.
3724	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
3725	specifies that the object is returned at ``+0`` and the ownership remains with
3726	the callee.
3727	The annotation ``__attribute__((ns_consumes_self))`` specifies that
3728	the Objective-C method call consumes the reference to ``self``, e.g. by
3729	attaching it to a supplied parameter.
3730	Additionally, parameters can have an annotation
3731	``__attribute__((ns_consumed))``, which specifies that passing an owned object
3732	as that parameter effectively transfers the ownership, and the caller is no
3733	longer responsible for it.
3734	These attributes affect code generation when interacting with ARC code, and
3735	they are used by the Clang Static Analyzer.
3736
3737	In C programs using CoreFoundation, a similar set of attributes:
3738	``__attribute__((cf_returns_not_retained))``,
3739	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
3740	have the same respective semantics when applied to CoreFoundation objects.
3741	These attributes affect code generation when interacting with ARC code, and
3742	they are used by the Clang Static Analyzer.
3743
3744	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
3745	the same attribute family is present:
3746	``__attribute__((os_returns_not_retained))``,
3747	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
3748	with the same respective semantics.
3749	Similar to ``__attribute__((ns_consumes_self))``,
3750	``__attribute__((os_consumes_this))`` specifies that the method call consumes
3751	the reference to "this" (e.g., when attaching it to a different object supplied
3752	as a parameter).
3753	Out parameters (parameters the function is meant to write into,
3754	either via pointers-to-pointers or references-to-pointers)
3755	may be annotated with ``__attribute__((os_returns_retained))``
3756	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
3757	written into the out parameter should (or respectively should not) be released
3758	after use.
3759	Since often out parameters may or may not be written depending on the exit
3760	code of the function,
3761	annotations ``__attribute__((os_returns_retained_on_zero))``
3762	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
3763	an out parameter at ``+1`` is written if and only if the function returns a zero
3764	(respectively non-zero) error code.
3765	Observe that return-code-dependent out parameter annotations are only
3766	available for retained out parameters, as non-retained object do not have to be
3767	released by the callee.
3768	These attributes are only used by the Clang Static Analyzer.
3769
3770	The family of attributes ``X_returns_X_retained`` can be added to functions,
3771	C++ methods, and Objective-C methods and properties.
3772	Attributes ``X_consumed`` can be added to parameters of methods, functions,
3773	and Objective-C methods.)reST";
3774
3775	static const char AttrDoc_NSConsumesSelf[] = R"reST(The behavior of a function with respect to reference counting for Foundation
3776	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
3777	convention (e.g. functions starting with "get" are assumed to return at
3778	``+0``).
3779
3780	It can be overridden using a family of the following attributes. In
3781	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
3782	a function communicates that the object is returned at ``+1``, and the caller
3783	is responsible for freeing it.
3784	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
3785	specifies that the object is returned at ``+0`` and the ownership remains with
3786	the callee.
3787	The annotation ``__attribute__((ns_consumes_self))`` specifies that
3788	the Objective-C method call consumes the reference to ``self``, e.g. by
3789	attaching it to a supplied parameter.
3790	Additionally, parameters can have an annotation
3791	``__attribute__((ns_consumed))``, which specifies that passing an owned object
3792	as that parameter effectively transfers the ownership, and the caller is no
3793	longer responsible for it.
3794	These attributes affect code generation when interacting with ARC code, and
3795	they are used by the Clang Static Analyzer.
3796
3797	In C programs using CoreFoundation, a similar set of attributes:
3798	``__attribute__((cf_returns_not_retained))``,
3799	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
3800	have the same respective semantics when applied to CoreFoundation objects.
3801	These attributes affect code generation when interacting with ARC code, and
3802	they are used by the Clang Static Analyzer.
3803
3804	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
3805	the same attribute family is present:
3806	``__attribute__((os_returns_not_retained))``,
3807	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
3808	with the same respective semantics.
3809	Similar to ``__attribute__((ns_consumes_self))``,
3810	``__attribute__((os_consumes_this))`` specifies that the method call consumes
3811	the reference to "this" (e.g., when attaching it to a different object supplied
3812	as a parameter).
3813	Out parameters (parameters the function is meant to write into,
3814	either via pointers-to-pointers or references-to-pointers)
3815	may be annotated with ``__attribute__((os_returns_retained))``
3816	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
3817	written into the out parameter should (or respectively should not) be released
3818	after use.
3819	Since often out parameters may or may not be written depending on the exit
3820	code of the function,
3821	annotations ``__attribute__((os_returns_retained_on_zero))``
3822	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
3823	an out parameter at ``+1`` is written if and only if the function returns a zero
3824	(respectively non-zero) error code.
3825	Observe that return-code-dependent out parameter annotations are only
3826	available for retained out parameters, as non-retained object do not have to be
3827	released by the callee.
3828	These attributes are only used by the Clang Static Analyzer.
3829
3830	The family of attributes ``X_returns_X_retained`` can be added to functions,
3831	C++ methods, and Objective-C methods and properties.
3832	Attributes ``X_consumed`` can be added to parameters of methods, functions,
3833	and Objective-C methods.)reST";
3834
3835	static const char AttrDoc_NSErrorDomain[] = R"reST(In Cocoa frameworks in Objective-C, one can group related error codes in enums
3836	and categorize these enums with error domains.
3837
3838	The ``ns_error_domain`` attribute indicates a global ``NSString`` or
3839	``CFString`` constant representing the error domain that an error code belongs
3840	to. For pointer uniqueness and code size this is a constant symbol, not a
3841	literal.
3842
3843	The domain and error code need to be used together. The ``ns_error_domain``
3844	attribute links error codes to their domain at the source level.
3845
3846	This metadata is useful for documentation purposes, for static analysis, and for
3847	improving interoperability between Objective-C and Swift. It is not used for
3848	code generation in Objective-C.
3849
3850	For example:
3851
3852	.. code-block:: objc
3853
3854	#define NS_ERROR_ENUM(_type, _name, _domain) \
3855	enum _name : _type _name; enum __attribute__((ns_error_domain(_domain))) _name : _type
3856
3857	extern NSString *const MyErrorDomain;
3858	typedef NS_ERROR_ENUM(unsigned char, MyErrorEnum, MyErrorDomain) {
3859	MyErrFirst,
3860	MyErrSecond,
3861	};)reST";
3862
3863	static const char AttrDoc_NSReturnsAutoreleased[] = R"reST(The behavior of a function with respect to reference counting for Foundation
3864	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
3865	convention (e.g. functions starting with "get" are assumed to return at
3866	``+0``).
3867
3868	It can be overridden using a family of the following attributes. In
3869	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
3870	a function communicates that the object is returned at ``+1``, and the caller
3871	is responsible for freeing it.
3872	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
3873	specifies that the object is returned at ``+0`` and the ownership remains with
3874	the callee.
3875	The annotation ``__attribute__((ns_consumes_self))`` specifies that
3876	the Objective-C method call consumes the reference to ``self``, e.g. by
3877	attaching it to a supplied parameter.
3878	Additionally, parameters can have an annotation
3879	``__attribute__((ns_consumed))``, which specifies that passing an owned object
3880	as that parameter effectively transfers the ownership, and the caller is no
3881	longer responsible for it.
3882	These attributes affect code generation when interacting with ARC code, and
3883	they are used by the Clang Static Analyzer.
3884
3885	In C programs using CoreFoundation, a similar set of attributes:
3886	``__attribute__((cf_returns_not_retained))``,
3887	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
3888	have the same respective semantics when applied to CoreFoundation objects.
3889	These attributes affect code generation when interacting with ARC code, and
3890	they are used by the Clang Static Analyzer.
3891
3892	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
3893	the same attribute family is present:
3894	``__attribute__((os_returns_not_retained))``,
3895	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
3896	with the same respective semantics.
3897	Similar to ``__attribute__((ns_consumes_self))``,
3898	``__attribute__((os_consumes_this))`` specifies that the method call consumes
3899	the reference to "this" (e.g., when attaching it to a different object supplied
3900	as a parameter).
3901	Out parameters (parameters the function is meant to write into,
3902	either via pointers-to-pointers or references-to-pointers)
3903	may be annotated with ``__attribute__((os_returns_retained))``
3904	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
3905	written into the out parameter should (or respectively should not) be released
3906	after use.
3907	Since often out parameters may or may not be written depending on the exit
3908	code of the function,
3909	annotations ``__attribute__((os_returns_retained_on_zero))``
3910	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
3911	an out parameter at ``+1`` is written if and only if the function returns a zero
3912	(respectively non-zero) error code.
3913	Observe that return-code-dependent out parameter annotations are only
3914	available for retained out parameters, as non-retained object do not have to be
3915	released by the callee.
3916	These attributes are only used by the Clang Static Analyzer.
3917
3918	The family of attributes ``X_returns_X_retained`` can be added to functions,
3919	C++ methods, and Objective-C methods and properties.
3920	Attributes ``X_consumed`` can be added to parameters of methods, functions,
3921	and Objective-C methods.)reST";
3922
3923	static const char AttrDoc_NSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
3924	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
3925	convention (e.g. functions starting with "get" are assumed to return at
3926	``+0``).
3927
3928	It can be overridden using a family of the following attributes. In
3929	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
3930	a function communicates that the object is returned at ``+1``, and the caller
3931	is responsible for freeing it.
3932	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
3933	specifies that the object is returned at ``+0`` and the ownership remains with
3934	the callee.
3935	The annotation ``__attribute__((ns_consumes_self))`` specifies that
3936	the Objective-C method call consumes the reference to ``self``, e.g. by
3937	attaching it to a supplied parameter.
3938	Additionally, parameters can have an annotation
3939	``__attribute__((ns_consumed))``, which specifies that passing an owned object
3940	as that parameter effectively transfers the ownership, and the caller is no
3941	longer responsible for it.
3942	These attributes affect code generation when interacting with ARC code, and
3943	they are used by the Clang Static Analyzer.
3944
3945	In C programs using CoreFoundation, a similar set of attributes:
3946	``__attribute__((cf_returns_not_retained))``,
3947	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
3948	have the same respective semantics when applied to CoreFoundation objects.
3949	These attributes affect code generation when interacting with ARC code, and
3950	they are used by the Clang Static Analyzer.
3951
3952	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
3953	the same attribute family is present:
3954	``__attribute__((os_returns_not_retained))``,
3955	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
3956	with the same respective semantics.
3957	Similar to ``__attribute__((ns_consumes_self))``,
3958	``__attribute__((os_consumes_this))`` specifies that the method call consumes
3959	the reference to "this" (e.g., when attaching it to a different object supplied
3960	as a parameter).
3961	Out parameters (parameters the function is meant to write into,
3962	either via pointers-to-pointers or references-to-pointers)
3963	may be annotated with ``__attribute__((os_returns_retained))``
3964	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
3965	written into the out parameter should (or respectively should not) be released
3966	after use.
3967	Since often out parameters may or may not be written depending on the exit
3968	code of the function,
3969	annotations ``__attribute__((os_returns_retained_on_zero))``
3970	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
3971	an out parameter at ``+1`` is written if and only if the function returns a zero
3972	(respectively non-zero) error code.
3973	Observe that return-code-dependent out parameter annotations are only
3974	available for retained out parameters, as non-retained object do not have to be
3975	released by the callee.
3976	These attributes are only used by the Clang Static Analyzer.
3977
3978	The family of attributes ``X_returns_X_retained`` can be added to functions,
3979	C++ methods, and Objective-C methods and properties.
3980	Attributes ``X_consumed`` can be added to parameters of methods, functions,
3981	and Objective-C methods.)reST";
3982
3983	static const char AttrDoc_NSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
3984	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
3985	convention (e.g. functions starting with "get" are assumed to return at
3986	``+0``).
3987
3988	It can be overridden using a family of the following attributes. In
3989	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
3990	a function communicates that the object is returned at ``+1``, and the caller
3991	is responsible for freeing it.
3992	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
3993	specifies that the object is returned at ``+0`` and the ownership remains with
3994	the callee.
3995	The annotation ``__attribute__((ns_consumes_self))`` specifies that
3996	the Objective-C method call consumes the reference to ``self``, e.g. by
3997	attaching it to a supplied parameter.
3998	Additionally, parameters can have an annotation
3999	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4000	as that parameter effectively transfers the ownership, and the caller is no
4001	longer responsible for it.
4002	These attributes affect code generation when interacting with ARC code, and
4003	they are used by the Clang Static Analyzer.
4004
4005	In C programs using CoreFoundation, a similar set of attributes:
4006	``__attribute__((cf_returns_not_retained))``,
4007	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4008	have the same respective semantics when applied to CoreFoundation objects.
4009	These attributes affect code generation when interacting with ARC code, and
4010	they are used by the Clang Static Analyzer.
4011
4012	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4013	the same attribute family is present:
4014	``__attribute__((os_returns_not_retained))``,
4015	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4016	with the same respective semantics.
4017	Similar to ``__attribute__((ns_consumes_self))``,
4018	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4019	the reference to "this" (e.g., when attaching it to a different object supplied
4020	as a parameter).
4021	Out parameters (parameters the function is meant to write into,
4022	either via pointers-to-pointers or references-to-pointers)
4023	may be annotated with ``__attribute__((os_returns_retained))``
4024	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4025	written into the out parameter should (or respectively should not) be released
4026	after use.
4027	Since often out parameters may or may not be written depending on the exit
4028	code of the function,
4029	annotations ``__attribute__((os_returns_retained_on_zero))``
4030	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4031	an out parameter at ``+1`` is written if and only if the function returns a zero
4032	(respectively non-zero) error code.
4033	Observe that return-code-dependent out parameter annotations are only
4034	available for retained out parameters, as non-retained object do not have to be
4035	released by the callee.
4036	These attributes are only used by the Clang Static Analyzer.
4037
4038	The family of attributes ``X_returns_X_retained`` can be added to functions,
4039	C++ methods, and Objective-C methods and properties.
4040	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4041	and Objective-C methods.)reST";
4042
4043	static const char AttrDoc_NVPTXKernel[] = R"reST(No documentation.)reST";
4044
4045	static const char AttrDoc_Naked[] = R"reST(No documentation.)reST";
4046
4047	static const char AttrDoc_NoAlias[] = R"reST(The ``noalias`` attribute indicates that the only memory accesses inside
4048	function are loads and stores from objects pointed to by its pointer-typed
4049	arguments, with arbitrary offsets.)reST";
4050
4051	static const char AttrDoc_NoBuiltin[] = R"reST(The ``__attribute__((no_builtin))`` is similar to the ``-fno-builtin`` flag
4052	except it is specific to the body of a function. The attribute may also be
4053	applied to a virtual function but has no effect on the behavior of overriding
4054	functions in a derived class.
4055
4056	It accepts one or more strings corresponding to the specific names of the
4057	builtins to disable (e.g. "memcpy", "memset").
4058	If the attribute is used without parameters it will disable all buitins at
4059	once.
4060
4061	.. code-block:: c++
4062
4063	// The compiler is not allowed to add any builtin to foo's body.
4064	void foo(char* data, size_t count) __attribute__((no_builtin)) {
4065	// The compiler is not allowed to convert the loop into
4066	// `__builtin_memset(data, 0xFE, count);`.
4067	for (size_t i = 0; i < count; ++i)
4068	data[i] = 0xFE;
4069	}
4070
4071	// The compiler is not allowed to add the `memcpy` builtin to bar's body.
4072	void bar(char* data, size_t count) __attribute__((no_builtin("memcpy"))) {
4073	// The compiler is allowed to convert the loop into
4074	// `__builtin_memset(data, 0xFE, count);` but cannot generate any
4075	// `__builtin_memcpy`
4076	for (size_t i = 0; i < count; ++i)
4077	data[i] = 0xFE;
4078	})reST";
4079
4080	static const char AttrDoc_NoCommon[] = R"reST(No documentation.)reST";
4081
4082	static const char AttrDoc_NoDebug[] = R"reST(The ``nodebug`` attribute allows you to suppress debugging information for a
4083	function or method, for a variable that is not a parameter or a non-static
4084	data member, or for a typedef or using declaration.)reST";
4085
4086	static const char AttrDoc_NoDeref[] = R"reST(The ``noderef`` attribute causes clang to diagnose dereferences of annotated pointer types.
4087	This is ideally used with pointers that point to special memory which cannot be read
4088	from or written to, but allowing for the pointer to be used in pointer arithmetic.
4089	The following are examples of valid expressions where dereferences are diagnosed:
4090
4091	.. code-block:: c
4092
4093	int __attribute__((noderef)) *p;
4094	int x = *p; // warning
4095
4096	int __attribute__((noderef)) **p2;
4097	x = **p2; // warning
4098
4099	int * __attribute__((noderef)) *p3;
4100	p = *p3; // warning
4101
4102	struct S {
4103	int a;
4104	};
4105	struct S __attribute__((noderef)) *s;
4106	x = s->a; // warning
4107	x = (*s).a; // warning
4108
4109	Not all dereferences may diagnose a warning if the value directed by the pointer may not be
4110	accessed. The following are examples of valid expressions where may not be diagnosed:
4111
4112	.. code-block:: c
4113
4114	int *q;
4115	int __attribute__((noderef)) *p;
4116	q = &*p;
4117	q = *&p;
4118
4119	struct S {
4120	int a;
4121	};
4122	struct S __attribute__((noderef)) *s;
4123	p = &s->a;
4124	p = &(*s).a;
4125
4126	``noderef`` is currently only supported for pointers and arrays and not usable
4127	for references or Objective-C object pointers.
4128
4129	.. code-block:: c++
4130
4131	int x = 2;
4132	int __attribute__((noderef)) &y = x; // warning: 'noderef' can only be used on an array or pointer type
4133
4134	.. code-block:: objc
4135
4136	id __attribute__((noderef)) obj = [NSObject new]; // warning: 'noderef' can only be used on an array or pointer type)reST";
4137
4138	static const char AttrDoc_NoDestroy[] = R"reST(The ``no_destroy`` attribute specifies that a variable with static or thread
4139	storage duration shouldn't have its exit-time destructor run. Annotating every
4140	static and thread duration variable with this attribute is equivalent to
4141	invoking clang with -fno-c++-static-destructors.
4142
4143	If a variable is declared with this attribute, clang doesn't access check or
4144	generate the type's destructor. If you have a type that you only want to be
4145	annotated with ``no_destroy``, you can therefore declare the destructor private:
4146
4147	.. code-block:: c++
4148
4149	struct only_no_destroy {
4150	only_no_destroy();
4151	private:
4152	~only_no_destroy();
4153	};
4154
4155	[[clang::no_destroy]] only_no_destroy global; // fine!
4156
4157	Note that destructors are still required for subobjects of aggregates annotated
4158	with this attribute. This is because previously constructed subobjects need to
4159	be destroyed if an exception gets thrown before the initialization of the
4160	complete object is complete. For instance:
4161
4162	.. code-block:: c++
4163
4164	void f() {
4165	try {
4166	[[clang::no_destroy]]
4167	static only_no_destroy array[10]; // error, only_no_destroy has a private destructor.
4168	} catch (...) {
4169	// Handle the error
4170	}
4171	}
4172
4173	Here, if the construction of ``array[9]`` fails with an exception, ``array[0..8]``
4174	will be destroyed, so the element's destructor needs to be accessible.)reST";
4175
4176	static const char AttrDoc_NoDuplicate[] = R"reST(The ``noduplicate`` attribute can be placed on function declarations to control
4177	whether function calls to this function can be duplicated or not as a result of
4178	optimizations. This is required for the implementation of functions with
4179	certain special requirements, like the OpenCL "barrier" function, that might
4180	need to be run concurrently by all the threads that are executing in lockstep
4181	on the hardware. For example this attribute applied on the function
4182	"nodupfunc" in the code below avoids that:
4183
4184	.. code-block:: c
4185
4186	void nodupfunc() __attribute__((noduplicate));
4187	// Setting it as a C++11 attribute is also valid
4188	// void nodupfunc() [[clang::noduplicate]];
4189	void foo();
4190	void bar();
4191
4192	nodupfunc();
4193	if (a > n) {
4194	foo();
4195	} else {
4196	bar();
4197	}
4198
4199	gets possibly modified by some optimizations into code similar to this:
4200
4201	.. code-block:: c
4202
4203	if (a > n) {
4204	nodupfunc();
4205	foo();
4206	} else {
4207	nodupfunc();
4208	bar();
4209	}
4210
4211	where the call to "nodupfunc" is duplicated and sunk into the two branches
4212	of the condition.)reST";
4213
4214	static const char AttrDoc_NoEscape[] = R"reST(``noescape`` placed on a function parameter of a pointer type is used to inform
4215	the compiler that the pointer cannot escape: that is, no reference to the object
4216	the pointer points to that is derived from the parameter value will survive
4217	after the function returns. Users are responsible for making sure parameters
4218	annotated with ``noescape`` do not actually escape. Calling ``free()`` on such
4219	a parameter does not constitute an escape.
4220
4221	For example:
4222
4223	.. code-block:: c
4224
4225	int *gp;
4226
4227	void nonescapingFunc(__attribute__((noescape)) int *p) {
4228	*p += 100; // OK.
4229	}
4230
4231	void escapingFunc(__attribute__((noescape)) int *p) {
4232	gp = p; // Not OK.
4233	}
4234
4235	Additionally, when the parameter is a `block pointer
4236	<https://clang.llvm.org/docs/BlockLanguageSpec.html>`, the same restriction
4237	applies to copies of the block. For example:
4238
4239	.. code-block:: c
4240
4241	typedef void (^BlockTy)();
4242	BlockTy g0, g1;
4243
4244	void nonescapingFunc(__attribute__((noescape)) BlockTy block) {
4245	block(); // OK.
4246	}
4247
4248	void escapingFunc(__attribute__((noescape)) BlockTy block) {
4249	g0 = block; // Not OK.
4250	g1 = Block_copy(block); // Not OK either.
4251	})reST";
4252
4253	static const char AttrDoc_NoInline[] = R"reST(This function attribute suppresses the inlining of a function at the call sites
4254	of the function.
4255
4256	``[[clang::noinline]]`` spelling can be used as a statement attribute; other
4257	spellings of the attribute are not supported on statements. If a statement is
4258	marked ``[[clang::noinline]]`` and contains calls, those calls inside the
4259	statement will not be inlined by the compiler.
4260
4261	``__noinline__`` can be used as a keyword in CUDA/HIP languages. This is to
4262	avoid diagnostics due to usage of ``__attribute__((__noinline__))``
4263	with ``__noinline__`` defined as a macro as ``__attribute__((noinline))``.
4264
4265	.. code-block:: c
4266
4267	int example(void) {
4268	int r;
4269	[[clang::noinline]] foo();
4270	[[clang::noinline]] r = bar();
4271	return r;
4272	})reST";
4273
4274	static const char AttrDoc_NoInstrumentFunction[] = R"reST(No documentation.)reST";
4275
4276	static const char AttrDoc_NoMerge[] = R"reST(If a statement is marked ``nomerge`` and contains call expressions, those call
4277	expressions inside the statement will not be merged during optimization. This
4278	attribute can be used to prevent the optimizer from obscuring the source
4279	location of certain calls. For example, it will prevent tail merging otherwise
4280	identical code sequences that raise an exception or terminate the program. Tail
4281	merging normally reduces the precision of source location information, making
4282	stack traces less useful for debugging. This attribute gives the user control
4283	over the tradeoff between code size and debug information precision.
4284
4285	``nomerge`` attribute can also be used as function attribute to prevent all
4286	calls to the specified function from merging. It has no effect on indirect
4287	calls to such functions. For example:
4288
4289	.. code-block:: c++
4290
4291	[[clang::nomerge]] void foo(int) {}
4292
4293	void bar(int x) {
4294	auto *ptr = foo;
4295	if (x) foo(1); else foo(2); // will not be merged
4296	if (x) ptr(1); else ptr(2); // indirect call, can be merged
4297	}
4298
4299	``nomerge`` attribute can also be used for pointers to functions to
4300	prevent calls through such pointer from merging. In such case the
4301	effect applies only to a specific function pointer. For example:
4302
4303	.. code-block:: c++
4304
4305	[[clang::nomerge]] void (*foo)(int);
4306
4307	void bar(int x) {
4308	auto *ptr = foo;
4309	if (x) foo(1); else foo(2); // will not be merged
4310	if (x) ptr(1); else ptr(2); // 'ptr' has no 'nomerge' attribute, can be merged
4311	})reST";
4312
4313	static const char AttrDoc_NoMicroMips[] = R"reST(Clang supports the GNU style ``__attribute__((micromips))`` and
4314	``__attribute__((nomicromips))`` attributes on MIPS targets. These attributes
4315	may be attached to a function definition and instructs the backend to generate
4316	or not to generate microMIPS code for that function.
4317
4318	These attributes override the ``-mmicromips`` and ``-mno-micromips`` options
4319	on the command line.)reST";
4320
4321	static const char AttrDoc_NoMips16[] = R"reST(No documentation.)reST";
4322
4323	static const char AttrDoc_NoProfileFunction[] = R"reST(Use the ``no_profile_instrument_function`` attribute on a function declaration
4324	to denote that the compiler should not instrument the function with
4325	profile-related instrumentation, such as via the
4326	``-fprofile-generate`` / ``-fprofile-instr-generate`` /
4327	``-fcs-profile-generate`` / ``-fprofile-arcs`` flags.)reST";
4328
4329	static const char AttrDoc_NoRandomizeLayout[] = R"reST(The attribute ``randomize_layout``, when attached to a C structure, selects it
4330	for structure layout field randomization; a compile-time hardening technique. A
4331	"seed" value, is specified via the ``-frandomize-layout-seed=`` command line flag.
4332	For example:
4333
4334	.. code-block:: bash
4335
4336	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
4337	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
4338
4339	You can also supply the seed in a file with ``-frandomize-layout-seed-file=``.
4340	For example:
4341
4342	.. code-block:: bash
4343
4344	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
4345	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
4346
4347	The randomization is deterministic based for a given seed, so the entire
4348	program should be compiled with the same seed, but keep the seed safe
4349	otherwise.
4350
4351	The attribute ``no_randomize_layout``, when attached to a C structure,
4352	instructs the compiler that this structure should not have its field layout
4353	randomized.)reST";
4354
4355	static const char AttrDoc_NoReturn[] = R"reST(No documentation.)reST";
4356
4357	static const char AttrDoc_NoSanitize[] = R"reST(Use the ``no_sanitize`` attribute on a function or a global variable
4358	declaration to specify that a particular instrumentation or set of
4359	instrumentations should not be applied.
4360
4361	The attribute takes a list of string literals with the following accepted
4362	values:
4363	* all values accepted by ``-fno-sanitize=``;
4364	* ``coverage``, to disable SanitizerCoverage instrumentation.
4365
4366	For example, ``__attribute__((no_sanitize("address", "thread")))`` specifies
4367	that AddressSanitizer and ThreadSanitizer should not be applied to the function
4368	or variable. Using ``__attribute__((no_sanitize("coverage")))`` specifies that
4369	SanitizerCoverage should not be applied to the function.
4370
4371	See :ref:`Controlling Code Generation <controlling-code-generation>` for a
4372	full list of supported sanitizer flags.)reST";
4373
4374	static const char AttrDoc_NoSpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
4375	that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
4376	is not needed for the function body. This can also be applied to a method
4377	in Objective C. This attribute will take precedence over the command line flag in
4378	the case where `-mspeculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
4379
4380	Warning: This attribute may not prevent Speculative Load Hardening from being
4381	enabled for a function which inlines a function that has the
4382	'speculative_load_hardening' attribute. This is intended to provide a
4383	maximally conservative model where the code that is marked with the
4384	'speculative_load_hardening' attribute will always (even when inlined)
4385	be hardened. A user of this attribute may want to mark functions called by
4386	a function they do not want to be hardened with the 'noinline' attribute.
4387
4388	For example:
4389
4390	.. code-block:: c
4391
4392	__attribute__((speculative_load_hardening))
4393	int foo(int i) {
4394	return i;
4395	}
4396
4397	// Note: bar() may still have speculative load hardening enabled if
4398	// foo() is inlined into bar(). Mark foo() with __attribute__((noinline))
4399	// to avoid this situation.
4400	__attribute__((no_speculative_load_hardening))
4401	int bar(int i) {
4402	return foo(i);
4403	})reST";
4404
4405	static const char AttrDoc_NoSplitStack[] = R"reST(The ``no_split_stack`` attribute disables the emission of the split stack
4406	preamble for a particular function. It has no effect if ``-fsplit-stack``
4407	is not specified.)reST";
4408
4409	static const char AttrDoc_NoStackProtector[] = R"reST(Clang supports the GNU style ``__attribute__((no_stack_protector))`` and Microsoft
4410	style ``__declspec(safebuffers)`` attribute which disables
4411	the stack protector on the specified function. This attribute is useful for
4412	selectively disabling the stack protector on some functions when building with
4413	``-fstack-protector`` compiler option.
4414
4415	For example, it disables the stack protector for the function ``foo`` but function
4416	``bar`` will still be built with the stack protector with the ``-fstack-protector``
4417	option.
4418
4419	.. code-block:: c
4420
4421	int __attribute__((no_stack_protector))
4422	foo (int x); // stack protection will be disabled for foo.
4423
4424	int bar(int y); // bar can be built with the stack protector.)reST";
4425
4426	static const char AttrDoc_NoThreadSafetyAnalysis[] = R"reST(No documentation.)reST";
4427
4428	static const char AttrDoc_NoThrow[] = R"reST(Clang supports the GNU style ``__attribute__((nothrow))`` and Microsoft style
4429	``__declspec(nothrow)`` attribute as an equivalent of ``noexcept`` on function
4430	declarations. This attribute informs the compiler that the annotated function
4431	does not throw an exception. This prevents exception-unwinding. This attribute
4432	is particularly useful on functions in the C Standard Library that are
4433	guaranteed to not throw an exception.)reST";
4434
4435	static const char AttrDoc_NoUniqueAddress[] = R"reST(The ``no_unique_address`` attribute allows tail padding in a non-static data
4436	member to overlap other members of the enclosing class (and in the special
4437	case when the type is empty, permits it to fully overlap other members).
4438	The field is laid out as if a base class were encountered at the corresponding
4439	point within the class (except that it does not share a vptr with the enclosing
4440	object).
4441
4442	Example usage:
4443
4444	.. code-block:: c++
4445
4446	template<typename T, typename Alloc> struct my_vector {
4447	T *p;
4448	[[no_unique_address]] Alloc alloc;
4449	// ...
4450	};
4451	static_assert(sizeof(my_vector<int, std::allocator<int>>) == sizeof(int*));
4452
4453	``[[no_unique_address]]`` is a standard C++20 attribute. Clang supports its use
4454	in C++11 onwards.
4455
4456	On MSVC targets, ``[[no_unique_address]]`` is ignored; use
4457	``[[msvc::no_unique_address]]`` instead. Currently there is no guarantee of ABI
4458	compatibility or stability with MSVC.)reST";
4459
4460	static const char AttrDoc_NoUwtable[] = R"reST(Clang supports the ``nouwtable`` attribute which skips emitting
4461	the unwind table entry for the specified function. This attribute is useful for
4462	selectively emitting the unwind table entry on some functions when building with
4463	``-funwind-tables`` compiler option.)reST";
4464
4465	static const char AttrDoc_NonAllocating[] = R"reST(Declares that a function or function type either does or does not allocate heap memory, according
4466	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
4467	is false, the attribute is equivalent to ``allocating``.)reST";
4468
4469	static const char AttrDoc_NonBlocking[] = R"reST(Declares that a function or function type either does or does not block in any way, according
4470	to the optional, compile-time constant boolean argument, which defaults to true. When the argument
4471	is false, the attribute is equivalent to ``blocking``.
4472
4473	For the purposes of diagnostics, ``nonblocking`` is considered to include the
4474	``nonallocating`` guarantee and is therefore a "stronger" constraint or attribute.)reST";
4475
4476	static const char AttrDoc_NonNull[] = R"reST(The ``nonnull`` attribute indicates that some function parameters must not be
4477	null, and can be used in several different ways. It's original usage
4478	(`from GCC <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes>`_)
4479	is as a function (or Objective-C method) attribute that specifies which
4480	parameters of the function are nonnull in a comma-separated list. For example:
4481
4482	.. code-block:: c
4483
4484	extern void * my_memcpy (void dest, const void src, size_t len)
4485	__attribute__((nonnull (1, 2)));
4486
4487	Here, the ``nonnull`` attribute indicates that parameters 1 and 2
4488	cannot have a null value. Omitting the parenthesized list of parameter indices
4489	means that all parameters of pointer type cannot be null:
4490
4491	.. code-block:: c
4492
4493	extern void * my_memcpy (void dest, const void src, size_t len)
4494	__attribute__((nonnull));
4495
4496	Clang also allows the ``nonnull`` attribute to be placed directly on a function
4497	(or Objective-C method) parameter, eliminating the need to specify the
4498	parameter index ahead of type. For example:
4499
4500	.. code-block:: c
4501
4502	extern void * my_memcpy (void *dest __attribute__((nonnull)),
4503	const void *src __attribute__((nonnull)), size_t len);
4504
4505	Note that the ``nonnull`` attribute indicates that passing null to a non-null
4506	parameter is undefined behavior, which the optimizer may take advantage of to,
4507	e.g., remove null checks. The ``_Nonnull`` type qualifier indicates that a
4508	pointer cannot be null in a more general manner (because it is part of the type
4509	system) and does not imply undefined behavior, making it more widely applicable.)reST";
4510
4511	static const char AttrDoc_NotTailCalled[] = R"reST(The ``not_tail_called`` attribute prevents tail-call optimization on statically
4512	bound calls. Objective-c methods, and functions marked as ``always_inline``
4513	cannot be marked as ``not_tail_called``.
4514
4515	For example, it prevents tail-call optimization in the following case:
4516
4517	.. code-block:: c
4518
4519	int __attribute__((not_tail_called)) foo1(int);
4520
4521	int foo2(int a) {
4522	return foo1(a); // No tail-call optimization on direct calls.
4523	}
4524
4525	However, it doesn't prevent tail-call optimization in this case:
4526
4527	.. code-block:: c
4528
4529	int __attribute__((not_tail_called)) foo1(int);
4530
4531	int foo2(int a) {
4532	int (*fn)(int) = &foo1;
4533
4534	// not_tail_called has no effect on an indirect call even if the call can
4535	// be resolved at compile time.
4536	return (*fn)(a);
4537	}
4538
4539	Generally, marking an overriding virtual function as ``not_tail_called`` is
4540	not useful, because this attribute is a property of the static type. Calls
4541	made through a pointer or reference to the base class type will respect
4542	the ``not_tail_called`` attribute of the base class's member function,
4543	regardless of the runtime destination of the call:
4544
4545	.. code-block:: c++
4546
4547	struct Foo { virtual void f(); };
4548	struct Bar : Foo {
4549	[[clang::not_tail_called]] void f() override;
4550	};
4551	void callera(Bar& bar) {
4552	Foo& foo = bar;
4553	// not_tail_called has no effect on here, even though the
4554	// underlying method is f from Bar.
4555	foo.f();
4556	bar.f(); // No tail-call optimization on here.
4557	})reST";
4558
4559	static const char AttrDoc_OMPAllocateDecl[] = R"reST()reST";
4560
4561	static const char AttrDoc_OMPAssume[] = R"reST(Clang supports the ``[[omp::assume("assumption")]]`` attribute to
4562	provide additional information to the optimizer. The string-literal, here
4563	"assumption", will be attached to the function declaration such that later
4564	analysis and optimization passes can assume the "assumption" to hold.
4565	This is similar to :ref:`__builtin_assume <langext-__builtin_assume>` but
4566	instead of an expression that can be assumed to be non-zero, the assumption is
4567	expressed as a string and it holds for the entire function.
4568
4569	A function can have multiple assume attributes and they propagate from prior
4570	declarations to later definitions. Multiple assumptions are aggregated into a
4571	single comma separated string. Thus, one can provide multiple assumptions via
4572	a comma separated string, i.a.,
4573	``[[omp::assume("assumption1,assumption2")]]``.
4574
4575	While LLVM plugins might provide more assumption strings, the default LLVM
4576	optimization passes are aware of the following assumptions:
4577
4578	.. code-block:: none
4579
4580	"omp_no_openmp"
4581	"omp_no_openmp_routines"
4582	"omp_no_parallelism"
4583
4584	The OpenMP standard defines the meaning of OpenMP assumptions ("omp_XYZ" is
4585	spelled "XYZ" in the `OpenMP 5.1 Standard`_).
4586
4587	.. _`OpenMP 5.1 Standard`: https://www.openmp.org/spec-html/5.1/openmpsu37.html#x56-560002.5.2)reST";
4588
4589	static const char AttrDoc_OMPCaptureKind[] = R"reST()reST";
4590
4591	static const char AttrDoc_OMPCaptureNoInit[] = R"reST()reST";
4592
4593	static const char AttrDoc_OMPDeclareSimdDecl[] = R"reST(The ``declare simd`` construct can be applied to a function to enable the creation
4594	of one or more versions that can process multiple arguments using SIMD
4595	instructions from a single invocation in a SIMD loop. The ``declare simd``
4596	directive is a declarative directive. There may be multiple ``declare simd``
4597	directives for a function. The use of a ``declare simd`` construct on a function
4598	enables the creation of SIMD versions of the associated function that can be
4599	used to process multiple arguments from a single invocation from a SIMD loop
4600	concurrently.
4601	The syntax of the ``declare simd`` construct is as follows:
4602
4603	.. code-block:: none
4604
4605	#pragma omp declare simd [clause[[,] clause] ...] new-line
4606	[#pragma omp declare simd [clause[[,] clause] ...] new-line]
4607	[...]
4608	function definition or declaration
4609
4610	where clause is one of the following:
4611
4612	.. code-block:: none
4613
4614	simdlen(length)
4615	linear(argument-list[:constant-linear-step])
4616	aligned(argument-list[:alignment])
4617	uniform(argument-list)
4618	inbranch
4619	notinbranch)reST";
4620
4621	static const char AttrDoc_OMPDeclareTargetDecl[] = R"reST(The ``declare target`` directive specifies that variables and functions are mapped
4622	to a device for OpenMP offload mechanism.
4623
4624	The syntax of the declare target directive is as follows:
4625
4626	.. code-block:: c
4627
4628	#pragma omp declare target new-line
4629	declarations-definition-seq
4630	#pragma omp end declare target new-line
4631
4632	or
4633
4634	.. code-block:: c
4635
4636	#pragma omp declare target (extended-list) new-line
4637
4638	or
4639
4640	.. code-block:: c
4641
4642	#pragma omp declare target clause[ [,] clause ... ] new-line
4643
4644	where clause is one of the following:
4645
4646
4647	.. code-block:: c
4648
4649	to(extended-list)
4650	link(list)
4651	device_type(host \| nohost \| any))reST";
4652
4653	static const char AttrDoc_OMPDeclareVariant[] = R"reST(The ``declare variant`` directive declares a specialized variant of a base
4654	function and specifies the context in which that specialized variant is used.
4655	The declare variant directive is a declarative directive.
4656	The syntax of the ``declare variant`` construct is as follows:
4657
4658	.. code-block:: none
4659
4660	#pragma omp declare variant(variant-func-id) clause new-line
4661	[#pragma omp declare variant(variant-func-id) clause new-line]
4662	[...]
4663	function definition or declaration
4664
4665	where clause is one of the following:
4666
4667	.. code-block:: none
4668
4669	match(context-selector-specification)
4670
4671	and where ``variant-func-id`` is the name of a function variant that is either a
4672	base language identifier or, for C++, a template-id.
4673
4674	Clang provides the following context selector extensions, used via
4675	``implementation={extension(EXTENSION)}``:
4676
4677	.. code-block:: none
4678
4679	match_all
4680	match_any
4681	match_none
4682	disable_implicit_base
4683	allow_templates
4684	bind_to_declaration
4685
4686	The match extensions change when the entire context selector is considered a
4687	match for an OpenMP context. The default is ``all``, with ``none`` no trait in the
4688	selector is allowed to be in the OpenMP context, with ``any`` a single trait in
4689	both the selector and OpenMP context is sufficient. Only a single match
4690	extension trait is allowed per context selector.
4691	The disable extensions remove default effects of the ``begin declare variant``
4692	applied to a definition. If ``disable_implicit_base`` is given, we will not
4693	introduce an implicit base function for a variant if no base function was
4694	found. The variant is still generated but will never be called, due to the
4695	absence of a base function and consequently calls to a base function.
4696	The allow extensions change when the ``begin declare variant`` effect is
4697	applied to a definition. If ``allow_templates`` is given, template function
4698	definitions are considered as specializations of existing or assumed template
4699	declarations with the same name. The template parameters for the base functions
4700	are used to instantiate the specialization. If ``bind_to_declaration`` is given,
4701	apply the same variant rules to function declarations. This allows the user to
4702	override declarations with only a function declaration.)reST";
4703
4704	static const char AttrDoc_OMPReferencedVar[] = R"reST()reST";
4705
4706	static const char AttrDoc_OMPThreadPrivateDecl[] = R"reST()reST";
4707
4708	static const char AttrDoc_OSConsumed[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4709	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4710	convention (e.g. functions starting with "get" are assumed to return at
4711	``+0``).
4712
4713	It can be overridden using a family of the following attributes. In
4714	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4715	a function communicates that the object is returned at ``+1``, and the caller
4716	is responsible for freeing it.
4717	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4718	specifies that the object is returned at ``+0`` and the ownership remains with
4719	the callee.
4720	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4721	the Objective-C method call consumes the reference to ``self``, e.g. by
4722	attaching it to a supplied parameter.
4723	Additionally, parameters can have an annotation
4724	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4725	as that parameter effectively transfers the ownership, and the caller is no
4726	longer responsible for it.
4727	These attributes affect code generation when interacting with ARC code, and
4728	they are used by the Clang Static Analyzer.
4729
4730	In C programs using CoreFoundation, a similar set of attributes:
4731	``__attribute__((cf_returns_not_retained))``,
4732	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4733	have the same respective semantics when applied to CoreFoundation objects.
4734	These attributes affect code generation when interacting with ARC code, and
4735	they are used by the Clang Static Analyzer.
4736
4737	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4738	the same attribute family is present:
4739	``__attribute__((os_returns_not_retained))``,
4740	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4741	with the same respective semantics.
4742	Similar to ``__attribute__((ns_consumes_self))``,
4743	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4744	the reference to "this" (e.g., when attaching it to a different object supplied
4745	as a parameter).
4746	Out parameters (parameters the function is meant to write into,
4747	either via pointers-to-pointers or references-to-pointers)
4748	may be annotated with ``__attribute__((os_returns_retained))``
4749	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4750	written into the out parameter should (or respectively should not) be released
4751	after use.
4752	Since often out parameters may or may not be written depending on the exit
4753	code of the function,
4754	annotations ``__attribute__((os_returns_retained_on_zero))``
4755	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4756	an out parameter at ``+1`` is written if and only if the function returns a zero
4757	(respectively non-zero) error code.
4758	Observe that return-code-dependent out parameter annotations are only
4759	available for retained out parameters, as non-retained object do not have to be
4760	released by the callee.
4761	These attributes are only used by the Clang Static Analyzer.
4762
4763	The family of attributes ``X_returns_X_retained`` can be added to functions,
4764	C++ methods, and Objective-C methods and properties.
4765	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4766	and Objective-C methods.)reST";
4767
4768	static const char AttrDoc_OSConsumesThis[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4769	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4770	convention (e.g. functions starting with "get" are assumed to return at
4771	``+0``).
4772
4773	It can be overridden using a family of the following attributes. In
4774	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4775	a function communicates that the object is returned at ``+1``, and the caller
4776	is responsible for freeing it.
4777	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4778	specifies that the object is returned at ``+0`` and the ownership remains with
4779	the callee.
4780	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4781	the Objective-C method call consumes the reference to ``self``, e.g. by
4782	attaching it to a supplied parameter.
4783	Additionally, parameters can have an annotation
4784	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4785	as that parameter effectively transfers the ownership, and the caller is no
4786	longer responsible for it.
4787	These attributes affect code generation when interacting with ARC code, and
4788	they are used by the Clang Static Analyzer.
4789
4790	In C programs using CoreFoundation, a similar set of attributes:
4791	``__attribute__((cf_returns_not_retained))``,
4792	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4793	have the same respective semantics when applied to CoreFoundation objects.
4794	These attributes affect code generation when interacting with ARC code, and
4795	they are used by the Clang Static Analyzer.
4796
4797	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4798	the same attribute family is present:
4799	``__attribute__((os_returns_not_retained))``,
4800	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4801	with the same respective semantics.
4802	Similar to ``__attribute__((ns_consumes_self))``,
4803	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4804	the reference to "this" (e.g., when attaching it to a different object supplied
4805	as a parameter).
4806	Out parameters (parameters the function is meant to write into,
4807	either via pointers-to-pointers or references-to-pointers)
4808	may be annotated with ``__attribute__((os_returns_retained))``
4809	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4810	written into the out parameter should (or respectively should not) be released
4811	after use.
4812	Since often out parameters may or may not be written depending on the exit
4813	code of the function,
4814	annotations ``__attribute__((os_returns_retained_on_zero))``
4815	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4816	an out parameter at ``+1`` is written if and only if the function returns a zero
4817	(respectively non-zero) error code.
4818	Observe that return-code-dependent out parameter annotations are only
4819	available for retained out parameters, as non-retained object do not have to be
4820	released by the callee.
4821	These attributes are only used by the Clang Static Analyzer.
4822
4823	The family of attributes ``X_returns_X_retained`` can be added to functions,
4824	C++ methods, and Objective-C methods and properties.
4825	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4826	and Objective-C methods.)reST";
4827
4828	static const char AttrDoc_OSReturnsNotRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4829	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4830	convention (e.g. functions starting with "get" are assumed to return at
4831	``+0``).
4832
4833	It can be overridden using a family of the following attributes. In
4834	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4835	a function communicates that the object is returned at ``+1``, and the caller
4836	is responsible for freeing it.
4837	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4838	specifies that the object is returned at ``+0`` and the ownership remains with
4839	the callee.
4840	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4841	the Objective-C method call consumes the reference to ``self``, e.g. by
4842	attaching it to a supplied parameter.
4843	Additionally, parameters can have an annotation
4844	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4845	as that parameter effectively transfers the ownership, and the caller is no
4846	longer responsible for it.
4847	These attributes affect code generation when interacting with ARC code, and
4848	they are used by the Clang Static Analyzer.
4849
4850	In C programs using CoreFoundation, a similar set of attributes:
4851	``__attribute__((cf_returns_not_retained))``,
4852	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4853	have the same respective semantics when applied to CoreFoundation objects.
4854	These attributes affect code generation when interacting with ARC code, and
4855	they are used by the Clang Static Analyzer.
4856
4857	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4858	the same attribute family is present:
4859	``__attribute__((os_returns_not_retained))``,
4860	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4861	with the same respective semantics.
4862	Similar to ``__attribute__((ns_consumes_self))``,
4863	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4864	the reference to "this" (e.g., when attaching it to a different object supplied
4865	as a parameter).
4866	Out parameters (parameters the function is meant to write into,
4867	either via pointers-to-pointers or references-to-pointers)
4868	may be annotated with ``__attribute__((os_returns_retained))``
4869	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4870	written into the out parameter should (or respectively should not) be released
4871	after use.
4872	Since often out parameters may or may not be written depending on the exit
4873	code of the function,
4874	annotations ``__attribute__((os_returns_retained_on_zero))``
4875	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4876	an out parameter at ``+1`` is written if and only if the function returns a zero
4877	(respectively non-zero) error code.
4878	Observe that return-code-dependent out parameter annotations are only
4879	available for retained out parameters, as non-retained object do not have to be
4880	released by the callee.
4881	These attributes are only used by the Clang Static Analyzer.
4882
4883	The family of attributes ``X_returns_X_retained`` can be added to functions,
4884	C++ methods, and Objective-C methods and properties.
4885	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4886	and Objective-C methods.)reST";
4887
4888	static const char AttrDoc_OSReturnsRetained[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4889	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4890	convention (e.g. functions starting with "get" are assumed to return at
4891	``+0``).
4892
4893	It can be overridden using a family of the following attributes. In
4894	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4895	a function communicates that the object is returned at ``+1``, and the caller
4896	is responsible for freeing it.
4897	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4898	specifies that the object is returned at ``+0`` and the ownership remains with
4899	the callee.
4900	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4901	the Objective-C method call consumes the reference to ``self``, e.g. by
4902	attaching it to a supplied parameter.
4903	Additionally, parameters can have an annotation
4904	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4905	as that parameter effectively transfers the ownership, and the caller is no
4906	longer responsible for it.
4907	These attributes affect code generation when interacting with ARC code, and
4908	they are used by the Clang Static Analyzer.
4909
4910	In C programs using CoreFoundation, a similar set of attributes:
4911	``__attribute__((cf_returns_not_retained))``,
4912	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4913	have the same respective semantics when applied to CoreFoundation objects.
4914	These attributes affect code generation when interacting with ARC code, and
4915	they are used by the Clang Static Analyzer.
4916
4917	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4918	the same attribute family is present:
4919	``__attribute__((os_returns_not_retained))``,
4920	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4921	with the same respective semantics.
4922	Similar to ``__attribute__((ns_consumes_self))``,
4923	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4924	the reference to "this" (e.g., when attaching it to a different object supplied
4925	as a parameter).
4926	Out parameters (parameters the function is meant to write into,
4927	either via pointers-to-pointers or references-to-pointers)
4928	may be annotated with ``__attribute__((os_returns_retained))``
4929	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4930	written into the out parameter should (or respectively should not) be released
4931	after use.
4932	Since often out parameters may or may not be written depending on the exit
4933	code of the function,
4934	annotations ``__attribute__((os_returns_retained_on_zero))``
4935	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4936	an out parameter at ``+1`` is written if and only if the function returns a zero
4937	(respectively non-zero) error code.
4938	Observe that return-code-dependent out parameter annotations are only
4939	available for retained out parameters, as non-retained object do not have to be
4940	released by the callee.
4941	These attributes are only used by the Clang Static Analyzer.
4942
4943	The family of attributes ``X_returns_X_retained`` can be added to functions,
4944	C++ methods, and Objective-C methods and properties.
4945	Attributes ``X_consumed`` can be added to parameters of methods, functions,
4946	and Objective-C methods.)reST";
4947
4948	static const char AttrDoc_OSReturnsRetainedOnNonZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
4949	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
4950	convention (e.g. functions starting with "get" are assumed to return at
4951	``+0``).
4952
4953	It can be overridden using a family of the following attributes. In
4954	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
4955	a function communicates that the object is returned at ``+1``, and the caller
4956	is responsible for freeing it.
4957	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
4958	specifies that the object is returned at ``+0`` and the ownership remains with
4959	the callee.
4960	The annotation ``__attribute__((ns_consumes_self))`` specifies that
4961	the Objective-C method call consumes the reference to ``self``, e.g. by
4962	attaching it to a supplied parameter.
4963	Additionally, parameters can have an annotation
4964	``__attribute__((ns_consumed))``, which specifies that passing an owned object
4965	as that parameter effectively transfers the ownership, and the caller is no
4966	longer responsible for it.
4967	These attributes affect code generation when interacting with ARC code, and
4968	they are used by the Clang Static Analyzer.
4969
4970	In C programs using CoreFoundation, a similar set of attributes:
4971	``__attribute__((cf_returns_not_retained))``,
4972	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
4973	have the same respective semantics when applied to CoreFoundation objects.
4974	These attributes affect code generation when interacting with ARC code, and
4975	they are used by the Clang Static Analyzer.
4976
4977	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
4978	the same attribute family is present:
4979	``__attribute__((os_returns_not_retained))``,
4980	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
4981	with the same respective semantics.
4982	Similar to ``__attribute__((ns_consumes_self))``,
4983	``__attribute__((os_consumes_this))`` specifies that the method call consumes
4984	the reference to "this" (e.g., when attaching it to a different object supplied
4985	as a parameter).
4986	Out parameters (parameters the function is meant to write into,
4987	either via pointers-to-pointers or references-to-pointers)
4988	may be annotated with ``__attribute__((os_returns_retained))``
4989	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
4990	written into the out parameter should (or respectively should not) be released
4991	after use.
4992	Since often out parameters may or may not be written depending on the exit
4993	code of the function,
4994	annotations ``__attribute__((os_returns_retained_on_zero))``
4995	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
4996	an out parameter at ``+1`` is written if and only if the function returns a zero
4997	(respectively non-zero) error code.
4998	Observe that return-code-dependent out parameter annotations are only
4999	available for retained out parameters, as non-retained object do not have to be
5000	released by the callee.
5001	These attributes are only used by the Clang Static Analyzer.
5002
5003	The family of attributes ``X_returns_X_retained`` can be added to functions,
5004	C++ methods, and Objective-C methods and properties.
5005	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5006	and Objective-C methods.)reST";
5007
5008	static const char AttrDoc_OSReturnsRetainedOnZero[] = R"reST(The behavior of a function with respect to reference counting for Foundation
5009	(Objective-C), CoreFoundation (C) and OSObject (C++) is determined by a naming
5010	convention (e.g. functions starting with "get" are assumed to return at
5011	``+0``).
5012
5013	It can be overridden using a family of the following attributes. In
5014	Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
5015	a function communicates that the object is returned at ``+1``, and the caller
5016	is responsible for freeing it.
5017	Similarly, the annotation ``__attribute__((ns_returns_not_retained))``
5018	specifies that the object is returned at ``+0`` and the ownership remains with
5019	the callee.
5020	The annotation ``__attribute__((ns_consumes_self))`` specifies that
5021	the Objective-C method call consumes the reference to ``self``, e.g. by
5022	attaching it to a supplied parameter.
5023	Additionally, parameters can have an annotation
5024	``__attribute__((ns_consumed))``, which specifies that passing an owned object
5025	as that parameter effectively transfers the ownership, and the caller is no
5026	longer responsible for it.
5027	These attributes affect code generation when interacting with ARC code, and
5028	they are used by the Clang Static Analyzer.
5029
5030	In C programs using CoreFoundation, a similar set of attributes:
5031	``__attribute__((cf_returns_not_retained))``,
5032	``__attribute__((cf_returns_retained))`` and ``__attribute__((cf_consumed))``
5033	have the same respective semantics when applied to CoreFoundation objects.
5034	These attributes affect code generation when interacting with ARC code, and
5035	they are used by the Clang Static Analyzer.
5036
5037	Finally, in C++ interacting with XNU kernel (objects inheriting from OSObject),
5038	the same attribute family is present:
5039	``__attribute__((os_returns_not_retained))``,
5040	``__attribute__((os_returns_retained))`` and ``__attribute__((os_consumed))``,
5041	with the same respective semantics.
5042	Similar to ``__attribute__((ns_consumes_self))``,
5043	``__attribute__((os_consumes_this))`` specifies that the method call consumes
5044	the reference to "this" (e.g., when attaching it to a different object supplied
5045	as a parameter).
5046	Out parameters (parameters the function is meant to write into,
5047	either via pointers-to-pointers or references-to-pointers)
5048	may be annotated with ``__attribute__((os_returns_retained))``
5049	or ``__attribute__((os_returns_not_retained))`` which specifies that the object
5050	written into the out parameter should (or respectively should not) be released
5051	after use.
5052	Since often out parameters may or may not be written depending on the exit
5053	code of the function,
5054	annotations ``__attribute__((os_returns_retained_on_zero))``
5055	and ``__attribute__((os_returns_retained_on_non_zero))`` specify that
5056	an out parameter at ``+1`` is written if and only if the function returns a zero
5057	(respectively non-zero) error code.
5058	Observe that return-code-dependent out parameter annotations are only
5059	available for retained out parameters, as non-retained object do not have to be
5060	released by the callee.
5061	These attributes are only used by the Clang Static Analyzer.
5062
5063	The family of attributes ``X_returns_X_retained`` can be added to functions,
5064	C++ methods, and Objective-C methods and properties.
5065	Attributes ``X_consumed`` can be added to parameters of methods, functions,
5066	and Objective-C methods.)reST";
5067
5068	static const char AttrDoc_ObjCBoxable[] = R"reST(Structs and unions marked with the ``objc_boxable`` attribute can be used
5069	with the Objective-C boxed expression syntax, ``@(...)``.
5070
5071	Usage: ``__attribute__((objc_boxable))``. This attribute
5072	can only be placed on a declaration of a trivially-copyable struct or union:
5073
5074	.. code-block:: objc
5075
5076	struct __attribute__((objc_boxable)) some_struct {
5077	int i;
5078	};
5079	union __attribute__((objc_boxable)) some_union {
5080	int i;
5081	float f;
5082	};
5083	typedef struct __attribute__((objc_boxable)) _some_struct some_struct;
5084
5085	// ...
5086
5087	some_struct ss;
5088	NSValue *boxed = @(ss);)reST";
5089
5090	static const char AttrDoc_ObjCBridge[] = R"reST(No documentation.)reST";
5091
5092	static const char AttrDoc_ObjCBridgeMutable[] = R"reST(No documentation.)reST";
5093
5094	static const char AttrDoc_ObjCBridgeRelated[] = R"reST(No documentation.)reST";
5095
5096	static const char AttrDoc_ObjCClassStub[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
5097	instantiated at runtime.
5098
5099	Unlike ``__attribute__((objc_runtime_visible))``, a class having this attribute
5100	still has a "class stub" that is visible to the linker. This allows categories
5101	to be defined. Static message sends with the class as a receiver use a special
5102	access pattern to ensure the class is lazily instantiated from the class stub.
5103
5104	Classes annotated with this attribute cannot be subclassed and cannot have
5105	implementations defined for them. This attribute is intended for use in
5106	Swift-generated headers for classes defined in Swift.
5107
5108	Adding or removing this attribute to a class is an ABI-breaking change.)reST";
5109
5110	static const char AttrDoc_ObjCDesignatedInitializer[] = R"reST(No documentation.)reST";
5111
5112	static const char AttrDoc_ObjCDirect[] = R"reST(The ``objc_direct`` attribute can be used to mark an Objective-C method as
5113	being direct. A direct method is treated statically like an ordinary method,
5114	but dynamically it behaves more like a C function. This lowers some of the costs
5115	associated with the method but also sacrifices some of the ordinary capabilities
5116	of Objective-C methods.
5117
5118	A message send of a direct method calls the implementation directly, as if it
5119	were a C function, rather than using ordinary Objective-C method dispatch. This
5120	is substantially faster and potentially allows the implementation to be inlined,
5121	but it also means the method cannot be overridden in subclasses or replaced
5122	dynamically, as ordinary Objective-C methods can.
5123
5124	Furthermore, a direct method is not listed in the class's method lists. This
5125	substantially reduces the code-size overhead of the method but also means it
5126	cannot be called dynamically using ordinary Objective-C method dispatch at all;
5127	in particular, this means that it cannot override a superclass method or satisfy
5128	a protocol requirement.
5129
5130	Because a direct method cannot be overridden, it is an error to perform
5131	a ``super`` message send of one.
5132
5133	Although a message send of a direct method causes the method to be called
5134	directly as if it were a C function, it still obeys Objective-C semantics in other
5135	ways:
5136
5137	- If the receiver is ``nil``, the message send does nothing and returns the zero value
5138	for the return type.
5139
5140	- A message send of a direct class method will cause the class to be initialized,
5141	including calling the ``+initialize`` method if present.
5142
5143	- The implicit ``_cmd`` parameter containing the method's selector is still defined.
5144	In order to minimize code-size costs, the implementation will not emit a reference
5145	to the selector if the parameter is unused within the method.
5146
5147	Symbols for direct method implementations are implicitly given hidden
5148	visibility, meaning that they can only be called within the same linkage unit.
5149
5150	It is an error to do any of the following:
5151
5152	- declare a direct method in a protocol,
5153	- declare an override of a direct method with a method in a subclass,
5154	- declare an override of a non-direct method with a direct method in a subclass,
5155	- declare a method with different directness in different class interfaces, or
5156	- implement a non-direct method (as declared in any class interface) with a direct method.
5157
5158	If any of these rules would be violated if every method defined in an
5159	``@implementation`` within a single linkage unit were declared in an
5160	appropriate class interface, the program is ill-formed with no diagnostic
5161	required. If a violation of this rule is not diagnosed, behavior remains
5162	well-defined; this paragraph is simply reserving the right to diagnose such
5163	conflicts in the future, not to treat them as undefined behavior.
5164
5165	Additionally, Clang will warn about any ``@selector`` expression that
5166	names a selector that is only known to be used for direct methods.
5167
5168	For the purpose of these rules, a "class interface" includes a class's primary
5169	``@interface`` block, its class extensions, its categories, its declared protocols,
5170	and all the class interfaces of its superclasses.
5171
5172	An Objective-C property can be declared with the ``direct`` property
5173	attribute. If a direct property declaration causes an implicit declaration of
5174	a getter or setter method (that is, if the given method is not explicitly
5175	declared elsewhere), the method is declared to be direct.
5176
5177	Some programmers may wish to make many methods direct at once. In order
5178	to simplify this, the ``objc_direct_members`` attribute is provided; see its
5179	documentation for more information.)reST";
5180
5181	static const char AttrDoc_ObjCDirectMembers[] = R"reST(The ``objc_direct_members`` attribute can be placed on an Objective-C
5182	``@interface`` or ``@implementation`` to mark that methods declared
5183	therein should be considered direct by default. See the documentation
5184	for ``objc_direct`` for more information about direct methods.
5185
5186	When ``objc_direct_members`` is placed on an ``@interface`` block, every
5187	method in the block is considered to be declared as direct. This includes any
5188	implicit method declarations introduced by property declarations. If the method
5189	redeclares a non-direct method, the declaration is ill-formed, exactly as if the
5190	method was annotated with the ``objc_direct`` attribute.
5191
5192	When ``objc_direct_members`` is placed on an ``@implementation`` block,
5193	methods defined in the block are considered to be declared as direct unless
5194	they have been previously declared as non-direct in any interface of the class.
5195	This includes the implicit method definitions introduced by synthesized
5196	properties, including auto-synthesized properties.)reST";
5197
5198	static const char AttrDoc_ObjCException[] = R"reST(No documentation.)reST";
5199
5200	static const char AttrDoc_ObjCExplicitProtocolImpl[] = R"reST(No documentation.)reST";
5201
5202	static const char AttrDoc_ObjCExternallyRetained[] = R"reST(The ``objc_externally_retained`` attribute can be applied to strong local
5203	variables, functions, methods, or blocks to opt into
5204	`externally-retained semantics
5205	<https://clang.llvm.org/docs/AutomaticReferenceCounting.html#externally-retained-variables>`_.
5206
5207	When applied to the definition of a function, method, or block, every parameter
5208	of the function with implicit strong retainable object pointer type is
5209	considered externally-retained, and becomes ``const``. By explicitly annotating
5210	a parameter with ``__strong``, you can opt back into the default
5211	non-externally-retained behavior for that parameter. For instance,
5212	``first_param`` is externally-retained below, but not ``second_param``:
5213
5214	.. code-block:: objc
5215
5216	__attribute__((objc_externally_retained))
5217	void f(NSArray first_param, __strong NSArray second_param) {
5218	// ...
5219	}
5220
5221	Likewise, when applied to a strong local variable, that variable becomes
5222	``const`` and is considered externally-retained.
5223
5224	When compiled without ``-fobjc-arc``, this attribute is ignored.)reST";
5225
5226	static const char AttrDoc_ObjCGC[] = R"reST(No documentation.)reST";
5227
5228	static const char AttrDoc_ObjCIndependentClass[] = R"reST(No documentation.)reST";
5229
5230	static const char AttrDoc_ObjCInertUnsafeUnretained[] = R"reST()reST";
5231
5232	static const char AttrDoc_ObjCKindOf[] = R"reST(No documentation.)reST";
5233
5234	static const char AttrDoc_ObjCMethodFamily[] = R"reST(Many methods in Objective-C have conventional meanings determined by their
5235	selectors. It is sometimes useful to be able to mark a method as having a
5236	particular conventional meaning despite not having the right selector, or as
5237	not having the conventional meaning that its selector would suggest. For these
5238	use cases, we provide an attribute to specifically describe the "method family"
5239	that a method belongs to.
5240
5241	Usage: ``__attribute__((objc_method_family(X)))``, where ``X`` is one of
5242	``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This
5243	attribute can only be placed at the end of a method declaration:
5244
5245	.. code-block:: objc
5246
5247	- (NSString *)initMyStringValue __attribute__((objc_method_family(none)));
5248
5249	Users who do not wish to change the conventional meaning of a method, and who
5250	merely want to document its non-standard retain and release semantics, should
5251	use the retaining behavior attributes (``ns_returns_retained``,
5252	``ns_returns_not_retained``, etc).
5253
5254	Query for this feature with ``__has_attribute(objc_method_family)``.)reST";
5255
5256	static const char AttrDoc_ObjCNSObject[] = R"reST(No documentation.)reST";
5257
5258	static const char AttrDoc_ObjCNonLazyClass[] = R"reST(This attribute can be added to an Objective-C ``@interface`` or
5259	``@implementation`` declaration to add the class to the list of non-lazily
5260	initialized classes. A non-lazy class will be initialized eagerly when the
5261	Objective-C runtime is loaded. This is required for certain system classes which
5262	have instances allocated in non-standard ways, such as the classes for blocks
5263	and constant strings. Adding this attribute is essentially equivalent to
5264	providing a trivial ``+load`` method but avoids the (fairly small) load-time
5265	overheads associated with defining and calling such a method.)reST";
5266
5267	static const char AttrDoc_ObjCNonRuntimeProtocol[] = R"reST(The ``objc_non_runtime_protocol`` attribute can be used to mark that an
5268	Objective-C protocol is only used during static type-checking and doesn't need
5269	to be represented dynamically. This avoids several small code-size and run-time
5270	overheads associated with handling the protocol's metadata. A non-runtime
5271	protocol cannot be used as the operand of a ``@protocol`` expression, and
5272	dynamic attempts to find it with ``objc_getProtocol`` will fail.
5273
5274	If a non-runtime protocol inherits from any ordinary protocols, classes and
5275	derived protocols that declare conformance to the non-runtime protocol will
5276	dynamically list their conformance to those bare protocols.)reST";
5277
5278	static const char AttrDoc_ObjCOwnership[] = R"reST(No documentation.)reST";
5279
5280	static const char AttrDoc_ObjCPreciseLifetime[] = R"reST(No documentation.)reST";
5281
5282	static const char AttrDoc_ObjCRequiresPropertyDefs[] = R"reST(No documentation.)reST";
5283
5284	static const char AttrDoc_ObjCRequiresSuper[] = R"reST(Some Objective-C classes allow a subclass to override a particular method in a
5285	parent class but expect that the overriding method also calls the overridden
5286	method in the parent class. For these cases, we provide an attribute to
5287	designate that a method requires a "call to ``super``" in the overriding
5288	method in the subclass.
5289
5290	Usage: ``__attribute__((objc_requires_super))``. This attribute can only
5291	be placed at the end of a method declaration:
5292
5293	.. code-block:: objc
5294
5295	- (void)foo __attribute__((objc_requires_super));
5296
5297	This attribute can only be applied the method declarations within a class, and
5298	not a protocol. Currently this attribute does not enforce any placement of
5299	where the call occurs in the overriding method (such as in the case of
5300	``-dealloc`` where the call must appear at the end). It checks only that it
5301	exists.
5302
5303	Note that on both OS X and iOS that the Foundation framework provides a
5304	convenience macro ``NS_REQUIRES_SUPER`` that provides syntactic sugar for this
5305	attribute:
5306
5307	.. code-block:: objc
5308
5309	- (void)foo NS_REQUIRES_SUPER;
5310
5311	This macro is conditionally defined depending on the compiler's support for
5312	this attribute. If the compiler does not support the attribute the macro
5313	expands to nothing.
5314
5315	Operationally, when a method has this annotation the compiler will warn if the
5316	implementation of an override in a subclass does not call super. For example:
5317
5318	.. code-block:: objc
5319
5320	warning: method possibly missing a [super AnnotMeth] call
5321	- (void) AnnotMeth{};
5322	^)reST";
5323
5324	static const char AttrDoc_ObjCReturnsInnerPointer[] = R"reST(No documentation.)reST";
5325
5326	static const char AttrDoc_ObjCRootClass[] = R"reST(No documentation.)reST";
5327
5328	static const char AttrDoc_ObjCRuntimeName[] = R"reST(By default, the Objective-C interface or protocol identifier is used
5329	in the metadata name for that object. The ``objc_runtime_name``
5330	attribute allows annotated interfaces or protocols to use the
5331	specified string argument in the object's metadata name instead of the
5332	default name.
5333
5334	Usage: ``__attribute__((objc_runtime_name("MyLocalName")))``. This attribute
5335	can only be placed before an @protocol or @interface declaration:
5336
5337	.. code-block:: objc
5338
5339	__attribute__((objc_runtime_name("MyLocalName")))
5340	@interface Message
5341	@end)reST";
5342
5343	static const char AttrDoc_ObjCRuntimeVisible[] = R"reST(This attribute specifies that the Objective-C class to which it applies is
5344	visible to the Objective-C runtime but not to the linker. Classes annotated
5345	with this attribute cannot be subclassed and cannot have categories defined for
5346	them.)reST";
5347
5348	static const char AttrDoc_ObjCSubclassingRestricted[] = R"reST(This attribute can be added to an Objective-C ``@interface`` declaration to
5349	ensure that this class cannot be subclassed.)reST";
5350
5351	static const char AttrDoc_OpenCLAccess[] = R"reST(The access qualifiers must be used with image object arguments or pipe arguments
5352	to declare if they are being read or written by a kernel or function.
5353
5354	The read_only/__read_only, write_only/__write_only and read_write/__read_write
5355	names are reserved for use as access qualifiers and shall not be used otherwise.
5356
5357	.. code-block:: c
5358
5359	kernel void
5360	foo (read_only image2d_t imageA,
5361	write_only image2d_t imageB) {
5362	...
5363	}
5364
5365	In the above example imageA is a read-only 2D image object, and imageB is a
5366	write-only 2D image object.
5367
5368	The read_write (or __read_write) qualifier can not be used with pipe.
5369
5370	More details can be found in the OpenCL C language Spec v2.0, Section 6.6.)reST";
5371
5372	static const char AttrDoc_OpenCLConstantAddressSpace[] = R"reST(The constant address space attribute signals that an object is located in
5373	a constant (non-modifiable) memory region. It is available to all work items.
5374	Any type can be annotated with the constant address space attribute. Objects
5375	with the constant address space qualifier can be declared in any scope and must
5376	have an initializer.)reST";
5377
5378	static const char AttrDoc_OpenCLGenericAddressSpace[] = R"reST(The generic address space attribute is only available with OpenCL v2.0 and later.
5379	It can be used with pointer types. Variables in global and local scope and
5380	function parameters in non-kernel functions can have the generic address space
5381	type attribute. It is intended to be a placeholder for any other address space
5382	except for '__constant' in OpenCL code which can be used with multiple address
5383	spaces.)reST";
5384
5385	static const char AttrDoc_OpenCLGlobalAddressSpace[] = R"reST(The global address space attribute specifies that an object is allocated in
5386	global memory, which is accessible by all work items. The content stored in this
5387	memory area persists between kernel executions. Pointer types to the global
5388	address space are allowed as function parameters or local variables. Starting
5389	with OpenCL v2.0, the global address space can be used with global (program
5390	scope) variables and static local variable as well.)reST";
5391
5392	static const char AttrDoc_OpenCLGlobalDeviceAddressSpace[] = R"reST(The ``global_device`` and ``global_host`` address space attributes specify that
5393	an object is allocated in global memory on the device/host. It helps to
5394	distinguish USM (Unified Shared Memory) pointers that access global device
5395	memory from those that access global host memory. These new address spaces are
5396	a subset of the ``__global/opencl_global`` address space, the full address space
5397	set model for OpenCL 2.0 with the extension looks as follows:
5398
5399	\| generic->global->host
5400	\| ->device
5401	\| ->private
5402	\| ->local
5403	\| constant
5404
5405	As ``global_device`` and ``global_host`` are a subset of
5406	``__global/opencl_global`` address spaces it is allowed to convert
5407	``global_device`` and ``global_host`` address spaces to
5408	``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
5409	"Address space nesting and rules for pointers").)reST";
5410
5411	static const char AttrDoc_OpenCLGlobalHostAddressSpace[] = R"reST(The ``global_device`` and ``global_host`` address space attributes specify that
5412	an object is allocated in global memory on the device/host. It helps to
5413	distinguish USM (Unified Shared Memory) pointers that access global device
5414	memory from those that access global host memory. These new address spaces are
5415	a subset of the ``__global/opencl_global`` address space, the full address space
5416	set model for OpenCL 2.0 with the extension looks as follows:
5417
5418	\| generic->global->host
5419	\| ->device
5420	\| ->private
5421	\| ->local
5422	\| constant
5423
5424	As ``global_device`` and ``global_host`` are a subset of
5425	``__global/opencl_global`` address spaces it is allowed to convert
5426	``global_device`` and ``global_host`` address spaces to
5427	``__global/opencl_global`` address spaces (following ISO/IEC TR 18037 5.1.3
5428	"Address space nesting and rules for pointers").)reST";
5429
5430	static const char AttrDoc_OpenCLIntelReqdSubGroupSize[] = R"reST(The optional attribute intel_reqd_sub_group_size can be used to indicate that
5431	the kernel must be compiled and executed with the specified subgroup size. When
5432	this attribute is present, get_max_sub_group_size() is guaranteed to return the
5433	specified integer value. This is important for the correctness of many subgroup
5434	algorithms, and in some cases may be used by the compiler to generate more optimal
5435	code. See `cl_intel_required_subgroup_size
5436	<https://www.khronos.org/registry/OpenCL/extensions/intel/cl_intel_required_subgroup_size.txt>`
5437	for details.)reST";
5438
5439	static const char AttrDoc_OpenCLKernel[] = R"reST(No documentation.)reST";
5440
5441	static const char AttrDoc_OpenCLLocalAddressSpace[] = R"reST(The local address space specifies that an object is allocated in the local (work
5442	group) memory area, which is accessible to all work items in the same work
5443	group. The content stored in this memory region is not accessible after
5444	the kernel execution ends. In a kernel function scope, any variable can be in
5445	the local address space. In other scopes, only pointer types to the local address
5446	space are allowed. Local address space variables cannot have an initializer.)reST";
5447
5448	static const char AttrDoc_OpenCLPrivateAddressSpace[] = R"reST(The private address space specifies that an object is allocated in the private
5449	(work item) memory. Other work items cannot access the same memory area and its
5450	content is destroyed after work item execution ends. Local variables can be
5451	declared in the private address space. Function arguments are always in the
5452	private address space. Kernel function arguments of a pointer or an array type
5453	cannot point to the private address space.)reST";
5454
5455	static const char AttrDoc_OpenCLUnrollHint[] = R"reST(The opencl_unroll_hint attribute qualifier can be used to specify that a loop
5456	(for, while and do loops) can be unrolled. This attribute qualifier can be
5457	used to specify full unrolling or partial unrolling by a specified amount.
5458	This is a compiler hint and the compiler may ignore this directive. See
5459	`OpenCL v2.0 <https://www.khronos.org/registry/cl/specs/opencl-2.0.pdf>`_
5460	s6.11.5 for details.)reST";
5461
5462	static const char AttrDoc_OptimizeNone[] = R"reST(The ``optnone`` attribute suppresses essentially all optimizations
5463	on a function or method, regardless of the optimization level applied to
5464	the compilation unit as a whole. This is particularly useful when you
5465	need to debug a particular function, but it is infeasible to build the
5466	entire application without optimization. Avoiding optimization on the
5467	specified function can improve the quality of the debugging information
5468	for that function.
5469
5470	This attribute is incompatible with the ``always_inline`` and ``minsize``
5471	attributes.
5472
5473	Note that this attribute does not apply recursively to nested functions such as
5474	lambdas or blocks when using declaration-specific attribute syntaxes such as double
5475	square brackets (``[[]]``) or ``__attribute__``. The ``#pragma`` syntax can be
5476	used to apply the attribute to all functions, including nested functions, in a
5477	range of source code.)reST";
5478
5479	static const char AttrDoc_Overloadable[] = R"reST(Clang provides support for C++ function overloading in C. Function overloading
5480	in C is introduced using the ``overloadable`` attribute. For example, one
5481	might provide several overloaded versions of a ``tgsin`` function that invokes
5482	the appropriate standard function computing the sine of a value with ``float``,
5483	``double``, or ``long double`` precision:
5484
5485	.. code-block:: c
5486
5487	#include <math.h>
5488	float __attribute__((overloadable)) tgsin(float x) { return sinf(x); }
5489	double __attribute__((overloadable)) tgsin(double x) { return sin(x); }
5490	long double __attribute__((overloadable)) tgsin(long double x) { return sinl(x); }
5491
5492	Given these declarations, one can call ``tgsin`` with a ``float`` value to
5493	receive a ``float`` result, with a ``double`` to receive a ``double`` result,
5494	etc. Function overloading in C follows the rules of C++ function overloading
5495	to pick the best overload given the call arguments, with a few C-specific
5496	semantics:
5497
5498	* Conversion from ``float`` or ``double`` to ``long double`` is ranked as a
5499	floating-point promotion (per C99) rather than as a floating-point conversion
5500	(as in C++).
5501
5502	* A conversion from a pointer of type ``T`` to a pointer of type ``U`` is
5503	considered a pointer conversion (with conversion rank) if ``T`` and ``U`` are
5504	compatible types.
5505
5506	* A conversion from type ``T`` to a value of type ``U`` is permitted if ``T``
5507	and ``U`` are compatible types. This conversion is given "conversion" rank.
5508
5509	* If no viable candidates are otherwise available, we allow a conversion from a
5510	pointer of type ``T`` to a pointer of type ``U``, where ``T`` and ``U`` are
5511	incompatible. This conversion is ranked below all other types of conversions.
5512	Please note: ``U`` lacking qualifiers that are present on ``T`` is sufficient
5513	for ``T`` and ``U`` to be incompatible.
5514
5515	The declaration of ``overloadable`` functions is restricted to function
5516	declarations and definitions. If a function is marked with the ``overloadable``
5517	attribute, then all declarations and definitions of functions with that name,
5518	except for at most one (see the note below about unmarked overloads), must have
5519	the ``overloadable`` attribute. In addition, redeclarations of a function with
5520	the ``overloadable`` attribute must have the ``overloadable`` attribute, and
5521	redeclarations of a function without the ``overloadable`` attribute must not
5522	have the ``overloadable`` attribute. e.g.,
5523
5524	.. code-block:: c
5525
5526	int f(int) __attribute__((overloadable));
5527	float f(float); // error: declaration of "f" must have the "overloadable" attribute
5528	int f(int); // error: redeclaration of "f" must have the "overloadable" attribute
5529
5530	int g(int) __attribute__((overloadable));
5531	int g(int) { } // error: redeclaration of "g" must also have the "overloadable" attribute
5532
5533	int h(int);
5534	int h(int) __attribute__((overloadable)); // error: declaration of "h" must not
5535	// have the "overloadable" attribute
5536
5537	Functions marked ``overloadable`` must have prototypes. Therefore, the
5538	following code is ill-formed:
5539
5540	.. code-block:: c
5541
5542	int h() __attribute__((overloadable)); // error: h does not have a prototype
5543
5544	However, ``overloadable`` functions are allowed to use a ellipsis even if there
5545	are no named parameters (as is permitted in C++). This feature is particularly
5546	useful when combined with the ``unavailable`` attribute:
5547
5548	.. code-block:: c++
5549
5550	void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error
5551
5552	Functions declared with the ``overloadable`` attribute have their names mangled
5553	according to the same rules as C++ function names. For example, the three
5554	``tgsin`` functions in our motivating example get the mangled names
5555	``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two
5556	caveats to this use of name mangling:
5557
5558	* Future versions of Clang may change the name mangling of functions overloaded
5559	in C, so you should not depend on an specific mangling. To be completely
5560	safe, we strongly urge the use of ``static inline`` with ``overloadable``
5561	functions.
5562
5563	* The ``overloadable`` attribute has almost no meaning when used in C++,
5564	because names will already be mangled and functions are already overloadable.
5565	However, when an ``overloadable`` function occurs within an ``extern "C"``
5566	linkage specification, its name will be mangled in the same way as it
5567	would in C.
5568
5569	For the purpose of backwards compatibility, at most one function with the same
5570	name as other ``overloadable`` functions may omit the ``overloadable``
5571	attribute. In this case, the function without the ``overloadable`` attribute
5572	will not have its name mangled.
5573
5574	For example:
5575
5576	.. code-block:: c
5577
5578	// Notes with mangled names assume Itanium mangling.
5579	int f(int);
5580	int f(double) __attribute__((overloadable));
5581	void foo() {
5582	f(5); // Emits a call to f (not _Z1fi, as it would with an overload that
5583	// was marked with overloadable).
5584	f(1.0); // Emits a call to _Z1fd.
5585	}
5586
5587	Support for unmarked overloads is not present in some versions of clang. You may
5588	query for it using ``__has_extension(overloadable_unmarked)``.
5589
5590	Query for this attribute with ``__has_attribute(overloadable)``.)reST";
5591
5592	static const char AttrDoc_Override[] = R"reST()reST";
5593
5594	static const char AttrDoc_Owner[] = R"reST(.. Note:: This attribute is experimental and its effect on analysis is subject to change in
5595	a future version of clang.
5596
5597	The attribute ``[[gsl::Owner(T)]]`` applies to structs and classes that own an
5598	object of type ``T``:
5599
5600	.. code::
5601
5602	class [[gsl::Owner(int)]] IntOwner {
5603	private:
5604	int value;
5605	public:
5606	int *getInt() { return &value; }
5607	};
5608
5609	The argument ``T`` is optional and is ignored.
5610	This attribute may be used by analysis tools and has no effect on code
5611	generation. A ``void`` argument means that the class can own any type.
5612
5613	See Pointer_ for an example.)reST";
5614
5615	static const char AttrDoc_Ownership[] = R"reST(No documentation.)reST";
5616
5617	static const char AttrDoc_Packed[] = R"reST(No documentation.)reST";
5618
5619	static const char AttrDoc_ParamTypestate[] = R"reST(This attribute specifies expectations about function parameters. Calls to an
5620	function with annotated parameters will issue a warning if the corresponding
5621	argument isn't in the expected state. The attribute is also used to set the
5622	initial state of the parameter when analyzing the function's body.)reST";
5623
5624	static const char AttrDoc_Pascal[] = R"reST(No documentation.)reST";
5625
5626	static const char AttrDoc_PassObjectSize[] = R"reST(.. Note:: The mangling of functions with parameters that are annotated with
5627	``pass_object_size`` is subject to change. You can get around this by
5628	using ``__asm__("foo")`` to explicitly name your functions, thus preserving
5629	your ABI; also, non-overloadable C functions with ``pass_object_size`` are
5630	not mangled.
5631
5632	The ``pass_object_size(Type)`` attribute can be placed on function parameters to
5633	instruct clang to call ``__builtin_object_size(param, Type)`` at each callsite
5634	of said function, and implicitly pass the result of this call in as an invisible
5635	argument of type ``size_t`` directly after the parameter annotated with
5636	``pass_object_size``. Clang will also replace any calls to
5637	``__builtin_object_size(param, Type)`` in the function by said implicit
5638	parameter.
5639
5640	Example usage:
5641
5642	.. code-block:: c
5643
5644	int bzero1(char *const p __attribute__((pass_object_size(0))))
5645	__attribute__((noinline)) {
5646	int i = 0;
5647	for (/**/; i < (int)__builtin_object_size(p, 0); ++i) {
5648	p[i] = 0;
5649	}
5650	return i;
5651	}
5652
5653	int main() {
5654	char chars[100];
5655	int n = bzero1(&chars[0]);
5656	assert(n == sizeof(chars));
5657	return 0;
5658	}
5659
5660	If successfully evaluating ``__builtin_object_size(param, Type)`` at the
5661	callsite is not possible, then the "failed" value is passed in. So, using the
5662	definition of ``bzero1`` from above, the following code would exit cleanly:
5663
5664	.. code-block:: c
5665
5666	int main2(int argc, char *argv[]) {
5667	int n = bzero1(argv);
5668	assert(n == -1);
5669	return 0;
5670	}
5671
5672	``pass_object_size`` plays a part in overload resolution. If two overload
5673	candidates are otherwise equally good, then the overload with one or more
5674	parameters with ``pass_object_size`` is preferred. This implies that the choice
5675	between two identical overloads both with ``pass_object_size`` on one or more
5676	parameters will always be ambiguous; for this reason, having two such overloads
5677	is illegal. For example:
5678
5679	.. code-block:: c++
5680
5681	#define PS(N) __attribute__((pass_object_size(N)))
5682	// OK
5683	void Foo(char a, char b); // Overload A
5684	// OK -- overload A has no parameters with pass_object_size.
5685	void Foo(char a PS(0), char b PS(0)); // Overload B
5686	// Error -- Same signature (sans pass_object_size) as overload B, and both
5687	// overloads have one or more parameters with the pass_object_size attribute.
5688	void Foo(void a PS(0), void b);
5689
5690	// OK
5691	void Bar(void *a PS(0)); // Overload C
5692	// OK
5693	void Bar(char *c PS(1)); // Overload D
5694
5695	void main() {
5696	char known[10], *unknown;
5697	Foo(unknown, unknown); // Calls overload B
5698	Foo(known, unknown); // Calls overload B
5699	Foo(unknown, known); // Calls overload B
5700	Foo(known, known); // Calls overload B
5701
5702	Bar(known); // Calls overload D
5703	Bar(unknown); // Calls overload D
5704	}
5705
5706	Currently, ``pass_object_size`` is a bit restricted in terms of its usage:
5707
5708	* Only one use of ``pass_object_size`` is allowed per parameter.
5709
5710	* It is an error to take the address of a function with ``pass_object_size`` on
5711	any of its parameters. If you wish to do this, you can create an overload
5712	without ``pass_object_size`` on any parameters.
5713
5714	* It is an error to apply the ``pass_object_size`` attribute to parameters that
5715	are not pointers. Additionally, any parameter that ``pass_object_size`` is
5716	applied to must be marked ``const`` at its function's definition.
5717
5718	Clang also supports the ``pass_dynamic_object_size`` attribute, which behaves
5719	identically to ``pass_object_size``, but evaluates a call to
5720	``__builtin_dynamic_object_size`` at the callee instead of
5721	``__builtin_object_size``. ``__builtin_dynamic_object_size`` provides some extra
5722	runtime checks when the object size can't be determined at compile-time. You can
5723	read more about ``__builtin_dynamic_object_size`` `here
5724	<https://clang.llvm.org/docs/LanguageExtensions.html#evaluating-object-size-dynamically>`_.)reST";
5725
5726	static const char AttrDoc_PatchableFunctionEntry[] = R"reST(``__attribute__((patchable_function_entry(N,M)))`` is used to generate M NOPs
5727	before the function entry and N-M NOPs after the function entry. This attribute
5728	takes precedence over the command line option ``-fpatchable-function-entry=N,M``.
5729	``M`` defaults to 0 if omitted.
5730
5731	This attribute is only supported on
5732	aarch64/aarch64-be/loongarch32/loongarch64/riscv32/riscv64/i386/x86-64/ppc/ppc64 targets.
5733	For ppc/ppc64 targets, AIX is still not supported.)reST";
5734
5735	static const char AttrDoc_Pcs[] = R"reST(On ARM targets, this attribute can be used to select calling conventions
5736	similar to ``stdcall`` on x86. Valid parameter values are "aapcs" and
5737	"aapcs-vfp".)reST";
5738
5739	static const char AttrDoc_Pointer[] = R"reST(.. Note:: This attribute is experimental and its effect on analysis is subject to change in
5740	a future version of clang.
5741
5742	The attribute ``[[gsl::Pointer(T)]]`` applies to structs and classes that behave
5743	like pointers to an object of type ``T``:
5744
5745	.. code::
5746
5747	class [[gsl::Pointer(int)]] IntPointer {
5748	private:
5749	int *valuePointer;
5750	public:
5751	IntPointer(const IntOwner&);
5752	int *getInt() { return valuePointer; }
5753	};
5754
5755	The argument ``T`` is optional and is ignored.
5756	This attribute may be used by analysis tools and has no effect on code
5757	generation. A ``void`` argument means that the pointer can point to any type.
5758
5759	Example:
5760	When constructing an instance of a class annotated like this (a Pointer) from
5761	an instance of a class annotated with ``[[gsl::Owner]]`` (an Owner),
5762	then the analysis will consider the Pointer to point inside the Owner.
5763	When the Owner's lifetime ends, it will consider the Pointer to be dangling.
5764
5765	.. code-block:: c++
5766
5767	int f() {
5768	IntPointer P(IntOwner{}); // P "points into" a temporary IntOwner object
5769	P.getInt(); // P is dangling
5770	})reST";
5771
5772	static const char AttrDoc_PragmaClangBSSSection[] = R"reST()reST";
5773
5774	static const char AttrDoc_PragmaClangDataSection[] = R"reST()reST";
5775
5776	static const char AttrDoc_PragmaClangRelroSection[] = R"reST()reST";
5777
5778	static const char AttrDoc_PragmaClangRodataSection[] = R"reST()reST";
5779
5780	static const char AttrDoc_PragmaClangTextSection[] = R"reST()reST";
5781
5782	static const char AttrDoc_PreferredName[] = R"reST(The ``preferred_name`` attribute can be applied to a class template, and
5783	specifies a preferred way of naming a specialization of the template. The
5784	preferred name will be used whenever the corresponding template specialization
5785	would otherwise be printed in a diagnostic or similar context.
5786
5787	The preferred name must be a typedef or type alias declaration that refers to a
5788	specialization of the class template (not including any type qualifiers). In
5789	general this requires the template to be declared at least twice. For example:
5790
5791	.. code-block:: c++
5792
5793	template<typename T> struct basic_string;
5794	using string = basic_string<char>;
5795	using wstring = basic_string<wchar_t>;
5796	template<typename T> struct [[clang::preferred_name(string),
5797	clang::preferred_name(wstring)]] basic_string {
5798	// ...
5799	};
5800
5801
5802	Note that the ``preferred_name`` attribute will be ignored when the compiler
5803	writes a C++20 Module interface now. This is due to a compiler issue
5804	(https://github.com/llvm/llvm-project/issues/56490) that blocks users to modularize
5805	declarations with `preferred_name`. This is intended to be fixed in the future.)reST";
5806
5807	static const char AttrDoc_PreferredType[] = R"reST(This attribute allows adjusting the type of a bit-field in debug information.
5808	This can be helpful when a bit-field is intended to store an enumeration value,
5809	but has to be specified as having the enumeration's underlying type in order to
5810	facilitate compiler optimizations or bit-field packing behavior. Normally, the
5811	underlying type is what is emitted in debug information, which can make it hard
5812	for debuggers to know to map a bit-field's value back to a particular enumeration.
5813
5814	.. code-block:: c++
5815
5816	enum Colors { Red, Green, Blue };
5817
5818	struct S {
5819	[[clang::preferred_type(Colors)]] unsigned ColorVal : 2;
5820	[[clang::preferred_type(bool)]] unsigned UseAlternateColorSpace : 1;
5821	} s = { Green, false };
5822
5823	Without the attribute, a debugger is likely to display the value ``1`` for ``ColorVal``
5824	and ``0`` for ``UseAlternateColorSpace``. With the attribute, the debugger may now
5825	display ``Green`` and ``false`` instead.
5826
5827	This can be used to map a bit-field to an arbitrary type that isn't integral
5828	or an enumeration type. For example:
5829
5830	.. code-block:: c++
5831
5832	struct A {
5833	short a1;
5834	short a2;
5835	};
5836
5837	struct B {
5838	[[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
5839	};
5840
5841	will associate the type ``A`` with the ``b1`` bit-field and is intended to display
5842	something like this in the debugger:
5843
5844	.. code-block:: text
5845
5846	Process 2755547 stopped
5847	* thread #1, name = 'test-preferred-', stop reason = step in
5848	frame #0: 0x0000555555555148 test-preferred-type`main at test.cxx:13:14
5849	10 int main()
5850	11 {
5851	12 B b;
5852	-> 13 return b.b1;
5853	14 }
5854	(lldb) v -T
5855	(B) b = {
5856	(A:32) b1 = {
5857	(short) a1 = 12
5858	(short) a2 = 15
5859	}
5860	}
5861
5862	Note that debuggers may not be able to handle more complex mappings, and so
5863	this usage is debugger-dependent.)reST";
5864
5865	static const char AttrDoc_PreserveAll[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
5866	a function. The ``preserve_all`` calling convention attempts to make the code
5867	in the caller even less intrusive than the ``preserve_most`` calling convention.
5868	This calling convention also behaves identical to the ``C`` calling convention
5869	on how arguments and return values are passed, but it uses a different set of
5870	caller/callee-saved registers. This removes the burden of saving and
5871	recovering a large register set before and after the call in the caller. If
5872	the arguments are passed in callee-saved registers, then they will be
5873	preserved by the callee across the call. This doesn't apply for values
5874	returned in callee-saved registers.
5875
5876	- On X86-64 the callee preserves all general purpose registers, except for
5877	R11. R11 can be used as a scratch register. Furthermore it also preserves
5878	all floating-point registers (XMMs/YMMs).
5879
5880	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
5881	X16-X18. Furthermore it also preserves lower 128 bits of V8-V31 SIMD - floating
5882	point registers.
5883
5884	The idea behind this convention is to support calls to runtime functions
5885	that don't need to call out to any other functions.
5886
5887	This calling convention, like the ``preserve_most`` calling convention, will be
5888	used by a future version of the Objective-C runtime and should be considered
5889	experimental at this time.)reST";
5890
5891	static const char AttrDoc_PreserveMost[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of
5892	a function. The ``preserve_most`` calling convention attempts to make the code
5893	in the caller as unintrusive as possible. This convention behaves identically
5894	to the ``C`` calling convention on how arguments and return values are passed,
5895	but it uses a different set of caller/callee-saved registers. This alleviates
5896	the burden of saving and recovering a large register set before and after the
5897	call in the caller. If the arguments are passed in callee-saved registers,
5898	then they will be preserved by the callee across the call. This doesn't
5899	apply for values returned in callee-saved registers.
5900
5901	- On X86-64 the callee preserves all general purpose registers, except for
5902	R11. R11 can be used as a scratch register. Floating-point registers
5903	(XMMs/YMMs) are not preserved and need to be saved by the caller.
5904
5905	- On AArch64 the callee preserve all general purpose registers, except X0-X8 and
5906	X16-X18.
5907
5908	The idea behind this convention is to support calls to runtime functions
5909	that have a hot path and a cold path. The hot path is usually a small piece
5910	of code that doesn't use many registers. The cold path might need to call out to
5911	another function and therefore only needs to preserve the caller-saved
5912	registers, which haven't already been saved by the caller. The
5913	``preserve_most`` calling convention is very similar to the ``cold`` calling
5914	convention in terms of caller/callee-saved registers, but they are used for
5915	different types of function calls. ``coldcc`` is for function calls that are
5916	rarely executed, whereas ``preserve_most`` function calls are intended to be
5917	on the hot path and definitely executed a lot. Furthermore ``preserve_most``
5918	doesn't prevent the inliner from inlining the function call.
5919
5920	This calling convention will be used by a future version of the Objective-C
5921	runtime and should therefore still be considered experimental at this time.
5922	Although this convention was created to optimize certain runtime calls to
5923	the Objective-C runtime, it is not limited to this runtime and might be used
5924	by other runtimes in the future too. The current implementation only
5925	supports X86-64 and AArch64, but the intention is to support more architectures
5926	in the future.)reST";
5927
5928	static const char AttrDoc_PreserveNone[] = R"reST(On X86-64 and AArch64 targets, this attribute changes the calling convention of a function.
5929	The ``preserve_none`` calling convention tries to preserve as few general
5930	registers as possible. So all general registers are caller saved registers. It
5931	also uses more general registers to pass arguments. This attribute doesn't
5932	impact floating-point registers. ``preserve_none``'s ABI is still unstable, and
5933	may be changed in the future.
5934
5935	- On X86-64, only RSP and RBP are preserved by the callee.
5936	Registers R12, R13, R14, R15, RDI, RSI, RDX, RCX, R8, R9, R11, and RAX now can
5937	be used to pass function arguments. Floating-point registers (XMMs/YMMs) still
5938	follow the C calling convention.
5939	- On AArch64, only LR and FP are preserved by the callee.
5940	Registers X20-X28, X0-X7, and X9-X14 are used to pass function arguments.
5941	X8, X16-X19, SIMD and floating-point registers follow the AAPCS calling
5942	convention. X15 is not available for argument passing on Windows, but is
5943	used to pass arguments on other platforms.)reST";
5944
5945	static const char AttrDoc_PtGuardedBy[] = R"reST(No documentation.)reST";
5946
5947	static const char AttrDoc_PtGuardedVar[] = R"reST(No documentation.)reST";
5948
5949	static const char AttrDoc_Ptr32[] = R"reST(The ``__ptr32`` qualifier represents a native pointer on a 32-bit system. On a
5950	64-bit system, a pointer with ``__ptr32`` is extended to a 64-bit pointer. The
5951	``__sptr`` and ``__uptr`` qualifiers can be used to specify whether the pointer
5952	is sign extended or zero extended. This qualifier is enabled under
5953	``-fms-extensions``.)reST";
5954
5955	static const char AttrDoc_Ptr64[] = R"reST(The ``__ptr64`` qualifier represents a native pointer on a 64-bit system. On a
5956	32-bit system, a ``__ptr64`` pointer is truncated to a 32-bit pointer. This
5957	qualifier is enabled under ``-fms-extensions``.)reST";
5958
5959	static const char AttrDoc_Pure[] = R"reST(No documentation.)reST";
5960
5961	static const char AttrDoc_RISCVInterrupt[] = R"reST(Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV
5962	targets. This attribute may be attached to a function definition and instructs
5963	the backend to generate appropriate function entry/exit code so that it can be
5964	used directly as an interrupt service routine.
5965
5966	Permissible values for this parameter are ``user``, ``supervisor``,
5967	and ``machine``. If there is no parameter, then it defaults to machine.
5968
5969	Repeated interrupt attribute on the same declaration will cause a warning
5970	to be emitted. In case of repeated declarations, the last one prevails.
5971
5972	Refer to:
5973	https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html
5974	https://riscv.org/specifications/privileged-isa/
5975	The RISC-V Instruction Set Manual Volume II: Privileged Architecture
5976	Version 1.10.)reST";
5977
5978	static const char AttrDoc_RISCVVectorCC[] = R"reST(The ``riscv_vector_cc`` attribute can be applied to a function. It preserves 15
5979	registers namely, v1-v7 and v24-v31 as callee-saved. Callers thus don't need
5980	to save these registers before function calls, and callees only need to save
5981	them if they use them.)reST";
5982
5983	static const char AttrDoc_RandomizeLayout[] = R"reST(The attribute ``randomize_layout``, when attached to a C structure, selects it
5984	for structure layout field randomization; a compile-time hardening technique. A
5985	"seed" value, is specified via the ``-frandomize-layout-seed=`` command line flag.
5986	For example:
5987
5988	.. code-block:: bash
5989
5990	SEED=`od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n'`
5991	make ... CFLAGS="-frandomize-layout-seed=$SEED" ...
5992
5993	You can also supply the seed in a file with ``-frandomize-layout-seed-file=``.
5994	For example:
5995
5996	.. code-block:: bash
5997
5998	od -A n -t x8 -N 32 /dev/urandom \| tr -d ' \n' > /tmp/seed_file.txt
5999	make ... CFLAGS="-frandomize-layout-seed-file=/tmp/seed_file.txt" ...
6000
6001	The randomization is deterministic based for a given seed, so the entire
6002	program should be compiled with the same seed, but keep the seed safe
6003	otherwise.
6004
6005	The attribute ``no_randomize_layout``, when attached to a C structure,
6006	instructs the compiler that this structure should not have its field layout
6007	randomized.)reST";
6008
6009	static const char AttrDoc_ReadOnlyPlacement[] = R"reST(This attribute is attached to a structure, class or union declaration.
6010	When attached to a record declaration/definition, it checks if all instances
6011	of this type can be placed in the read-only data segment of the program. If it
6012	finds an instance that can not be placed in a read-only segment, the compiler
6013	emits a warning at the source location where the type was used.
6014
6015	Examples:
6016	* ``struct __attribute__((enforce_read_only_placement)) Foo;``
6017	* ``struct __attribute__((enforce_read_only_placement)) Bar { ... };``
6018
6019	Both ``Foo`` and ``Bar`` types have the ``enforce_read_only_placement`` attribute.
6020
6021	The goal of introducing this attribute is to assist developers with writing secure
6022	code. A ``const``-qualified global is generally placed in the read-only section
6023	of the memory that has additional run time protection from malicious writes. By
6024	attaching this attribute to a declaration, the developer can express the intent
6025	to place all instances of the annotated type in the read-only program memory.
6026
6027	Note 1: The attribute doesn't guarantee that the object will be placed in the
6028	read-only data segment as it does not instruct the compiler to ensure such
6029	a placement. It emits a warning if something in the code can be proven to prevent
6030	an instance from being placed in the read-only data segment.
6031
6032	Note 2: Currently, clang only checks if all global declarations of a given type 'T'
6033	are ``const``-qualified. The following conditions would also prevent the data to be
6034	put into read only segment, but the corresponding warnings are not yet implemented.
6035
6036	1. An instance of type ``T`` is allocated on the heap/stack.
6037	2. Type ``T`` defines/inherits a mutable field.
6038	3. Type ``T`` defines/inherits non-constexpr constructor(s) for initialization.
6039	4. A field of type ``T`` is defined by type ``Q``, which does not bear the
6040	``enforce_read_only_placement`` attribute.
6041	5. A type ``Q`` inherits from type ``T`` and it does not have the
6042	``enforce_read_only_placement`` attribute.)reST";
6043
6044	static const char AttrDoc_RegCall[] = R"reST(On x86 targets, this attribute changes the calling convention to
6045	`__regcall`_ convention. This convention aims to pass as many arguments
6046	as possible in registers. It also tries to utilize registers for the
6047	return value whenever it is possible.
6048
6049	.. _`__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";
6050
6051	static const char AttrDoc_Reinitializes[] = R"reST(The ``reinitializes`` attribute can be applied to a non-static, non-const C++
6052	member function to indicate that this member function reinitializes the entire
6053	object to a known state, independent of the previous state of the object.
6054
6055	This attribute can be interpreted by static analyzers that warn about uses of an
6056	object that has been left in an indeterminate state by a move operation. If a
6057	member function marked with the ``reinitializes`` attribute is called on a
6058	moved-from object, the analyzer can conclude that the object is no longer in an
6059	indeterminate state.
6060
6061	A typical example where this attribute would be used is on functions that clear
6062	a container class:
6063
6064	.. code-block:: c++
6065
6066	template <class T>
6067	class Container {
6068	public:
6069	...
6070	[[clang::reinitializes]] void Clear();
6071	...
6072	};)reST";
6073
6074	static const char AttrDoc_ReleaseCapability[] = R"reST(Marks a function as releasing a capability.)reST";
6075
6076	static const char AttrDoc_ReleaseHandle[] = R"reST(If a function parameter is annotated with ``release_handle(tag)`` it is assumed to
6077	close the handle. It is also assumed to require an open handle to work with. The
6078	attribute requires a string literal argument to identify the handle being released.
6079
6080	.. code-block:: c++
6081
6082	zx_status_t zx_handle_close(zx_handle_t handle [[clang::release_handle("tag")]]);)reST";
6083
6084	static const char AttrDoc_RenderScriptKernel[] = R"reST(``__attribute__((kernel))`` is used to mark a ``kernel`` function in
6085	RenderScript.
6086
6087	In RenderScript, ``kernel`` functions are used to express data-parallel
6088	computations. The RenderScript runtime efficiently parallelizes ``kernel``
6089	functions to run on computational resources such as multi-core CPUs and GPUs.
6090	See the RenderScript_ documentation for more information.
6091
6092	.. _RenderScript: https://developer.android.com/guide/topics/renderscript/compute.html)reST";
6093
6094	static const char AttrDoc_ReqdWorkGroupSize[] = R"reST(No documentation.)reST";
6095
6096	static const char AttrDoc_RequiresCapability[] = R"reST(No documentation.)reST";
6097
6098	static const char AttrDoc_Restrict[] = R"reST(The ``malloc`` attribute indicates that the function acts like a system memory
6099	allocation function, returning a pointer to allocated storage disjoint from the
6100	storage for any other object accessible to the caller.)reST";
6101
6102	static const char AttrDoc_Retain[] = R"reST(This attribute, when attached to a function or variable definition, prevents
6103	section garbage collection in the linker. It does not prevent other discard
6104	mechanisms, such as archive member selection, and COMDAT group resolution.
6105
6106	If the compiler does not emit the definition, e.g. because it was not used in
6107	the translation unit or the compiler was able to eliminate all of the uses,
6108	this attribute has no effect. This attribute is typically combined with the
6109	``used`` attribute to force the definition to be emitted and preserved into the
6110	final linked image.
6111
6112	This attribute is only necessary on ELF targets; other targets prevent section
6113	garbage collection by the linker when using the ``used`` attribute alone.
6114	Using the attributes together should result in consistent behavior across
6115	targets.
6116
6117	This attribute requires the linker to support the ``SHF_GNU_RETAIN`` extension.
6118	This support is available in GNU ``ld`` and ``gold`` as of binutils 2.36, as
6119	well as in ``ld.lld`` 13.)reST";
6120
6121	static const char AttrDoc_ReturnTypestate[] = R"reST(The ``return_typestate`` attribute can be applied to functions or parameters.
6122	When applied to a function the attribute specifies the state of the returned
6123	value. The function's body is checked to ensure that it always returns a value
6124	in the specified state. On the caller side, values returned by the annotated
6125	function are initialized to the given state.
6126
6127	When applied to a function parameter it modifies the state of an argument after
6128	a call to the function returns. The function's body is checked to ensure that
6129	the parameter is in the expected state before returning.)reST";
6130
6131	static const char AttrDoc_ReturnsNonNull[] = R"reST(The ``returns_nonnull`` attribute indicates that a particular function (or
6132	Objective-C method) always returns a non-null pointer. For example, a
6133	particular system ``malloc`` might be defined to terminate a process when
6134	memory is not available rather than returning a null pointer:
6135
6136	.. code-block:: c
6137
6138	extern void * malloc (size_t size) __attribute__((returns_nonnull));
6139
6140	The ``returns_nonnull`` attribute implies that returning a null pointer is
6141	undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
6142	type qualifier indicates that a pointer cannot be null in a more general manner
6143	(because it is part of the type system) and does not imply undefined behavior,
6144	making it more widely applicable)reST";
6145
6146	static const char AttrDoc_ReturnsTwice[] = R"reST(No documentation.)reST";
6147
6148	static const char AttrDoc_SPtr[] = R"reST(The ``__sptr`` qualifier specifies that a 32-bit pointer should be sign
6149	extended when converted to a 64-bit pointer.)reST";
6150
6151	static const char AttrDoc_SYCLKernel[] = R"reST(The ``sycl_kernel`` attribute specifies that a function template will be used
6152	to outline device code and to generate an OpenCL kernel.
6153	Here is a code example of the SYCL program, which demonstrates the compiler's
6154	outlining job:
6155
6156	.. code-block:: c++
6157
6158	int foo(int x) { return ++x; }
6159
6160	using namespace cl::sycl;
6161	queue Q;
6162	buffer<int, 1> a(range<1>{1024});
6163	Q.submit([&](handler& cgh) {
6164	auto A = a.get_access<access::mode::write>(cgh);
6165	cgh.parallel_for<init_a>(range<1>{1024}, [=](id<1> index) {
6166	A[index] = index[0] + foo(42);
6167	});
6168	}
6169
6170	A C++ function object passed to the ``parallel_for`` is called a "SYCL kernel".
6171	A SYCL kernel defines the entry point to the "device part" of the code. The
6172	compiler will emit all symbols accessible from a "kernel". In this code
6173	example, the compiler will emit "foo" function. More details about the
6174	compilation of functions for the device part can be found in the SYCL 1.2.1
6175	specification Section 6.4.
6176	To show to the compiler entry point to the "device part" of the code, the SYCL
6177	runtime can use the ``sycl_kernel`` attribute in the following way:
6178
6179	.. code-block:: c++
6180
6181	namespace cl {
6182	namespace sycl {
6183	class handler {
6184	template <typename KernelName, typename KernelType/, .../>
6185	__attribute__((sycl_kernel)) void sycl_kernel_function(KernelType KernelFuncObj) {
6186	// ...
6187	KernelFuncObj();
6188	}
6189
6190	template <typename KernelName, typename KernelType, int Dims>
6191	void parallel_for(range<Dims> NumWorkItems, KernelType KernelFunc) {
6192	#ifdef __SYCL_DEVICE_ONLY__
6193	sycl_kernel_function<KernelName, KernelType, Dims>(KernelFunc);
6194	#else
6195	// Host implementation
6196	#endif
6197	}
6198	};
6199	} // namespace sycl
6200	} // namespace cl
6201
6202	The compiler will also generate an OpenCL kernel using the function marked with
6203	the ``sycl_kernel`` attribute.
6204	Here is the list of SYCL device compiler expectations with regard to the
6205	function marked with the ``sycl_kernel`` attribute:
6206
6207	- The function must be a template with at least two type template parameters.
6208	The compiler generates an OpenCL kernel and uses the first template parameter
6209	as a unique name for the generated OpenCL kernel. The host application uses
6210	this unique name to invoke the OpenCL kernel generated for the SYCL kernel
6211	specialized by this name and second template parameter ``KernelType`` (which
6212	might be an unnamed function object type).
6213	- The function must have at least one parameter. The first parameter is
6214	required to be a function object type (named or unnamed i.e. lambda). The
6215	compiler uses function object type fields to generate OpenCL kernel
6216	parameters.
6217	- The function must return void. The compiler reuses the body of marked functions to
6218	generate the OpenCL kernel body, and the OpenCL kernel must return ``void``.
6219
6220	The SYCL kernel in the previous code sample meets these expectations.)reST";
6221
6222	static const char AttrDoc_SYCLSpecialClass[] = R"reST(SYCL defines some special classes (accessor, sampler, and stream) which require
6223	specific handling during the generation of the SPIR entry point.
6224	The ``__attribute__((sycl_special_class))`` attribute is used in SYCL
6225	headers to indicate that a class or a struct needs a specific handling when
6226	it is passed from host to device.
6227	Special classes will have a mandatory ``__init`` method and an optional
6228	``__finalize`` method (the ``__finalize`` method is used only with the
6229	``stream`` type). Kernel parameters types are extract from the ``__init`` method
6230	parameters. The kernel function arguments list is derived from the
6231	arguments of the ``__init`` method. The arguments of the ``__init`` method are
6232	copied into the kernel function argument list and the ``__init`` and
6233	``__finalize`` methods are called at the beginning and the end of the kernel,
6234	respectively.
6235	The ``__init`` and ``__finalize`` methods must be defined inside the
6236	special class.
6237	Please note that this is an attribute that is used as an internal
6238	implementation detail and not intended to be used by external users.
6239
6240	The syntax of the attribute is as follows:
6241
6242	.. code-block:: text
6243
6244	class __attribute__((sycl_special_class)) accessor {};
6245	class [[clang::sycl_special_class]] accessor {};
6246
6247	This is a code example that illustrates the use of the attribute:
6248
6249	.. code-block:: c++
6250
6251	class __attribute__((sycl_special_class)) SpecialType {
6252	int F1;
6253	int F2;
6254	void __init(int f1) {
6255	F1 = f1;
6256	F2 = f1;
6257	}
6258	void __finalize() {}
6259	public:
6260	SpecialType() = default;
6261	int getF2() const { return F2; }
6262	};
6263
6264	int main () {
6265	SpecialType T;
6266	cgh.single_task([=] {
6267	T.getF2();
6268	});
6269	}
6270
6271	This would trigger the following kernel entry point in the AST:
6272
6273	.. code-block:: c++
6274
6275	void __sycl_kernel(int f1) {
6276	SpecialType T;
6277	T.__init(f1);
6278	...
6279	T.__finalize()
6280	})reST";
6281
6282	static const char AttrDoc_ScopedLockable[] = R"reST(No documentation.)reST";
6283
6284	static const char AttrDoc_Section[] = R"reST(The ``section`` attribute allows you to specify a specific section a
6285	global variable or function should be in after translation.)reST";
6286
6287	static const char AttrDoc_SelectAny[] = R"reST(This attribute appertains to a global symbol, causing it to have a weak
6288	definition (
6289	`linkonce <https://llvm.org/docs/LangRef.html#linkage-types>`_
6290	), allowing the linker to select any definition.
6291
6292	For more information see
6293	`gcc documentation <https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Microsoft-Windows-Variable-Attributes.html>`_
6294	or `msvc documentation <https://docs.microsoft.com/pl-pl/cpp/cpp/selectany>`_.)reST";
6295
6296	static const char AttrDoc_Sentinel[] = R"reST(No documentation.)reST";
6297
6298	static const char AttrDoc_SetTypestate[] = R"reST(Annotate methods that transition an object into a new state with
6299	``__attribute__((set_typestate(new_state)))``. The new state must be
6300	unconsumed, consumed, or unknown.)reST";
6301
6302	static const char AttrDoc_SharedTrylockFunction[] = R"reST(No documentation.)reST";
6303
6304	static const char AttrDoc_SizedBy[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
6305	structure in C. The argument for the attribute is the name of a field member
6306	holding the count of elements in the flexible array. This information can be
6307	used to improve the results of the array bound sanitizer and the
6308	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
6309	within the same non-anonymous, enclosing struct as the flexible array member.
6310
6311	This example specifies that the flexible array member ``array`` has the number
6312	of elements allocated for it in ``count``:
6313
6314	.. code-block:: c
6315
6316	struct bar;
6317
6318	struct foo {
6319	size_t count;
6320	char other;
6321	struct bar *array[] __attribute__((counted_by(count)));
6322	};
6323
6324	This establishes a relationship between ``array`` and ``count``. Specifically,
6325	``array`` must have at least ``count`` number of elements available. It's the
6326	user's responsibility to ensure that this relationship is maintained through
6327	changes to the structure.
6328
6329	In the following example, the allocated array erroneously has fewer elements
6330	than what's specified by ``p->count``. This would result in an out-of-bounds
6331	access not being detected.
6332
6333	.. code-block:: c
6334
6335	#define SIZE_INCR 42
6336
6337	struct foo *p;
6338
6339	void foo_alloc(size_t count) {
6340	p = malloc(MAX(sizeof(struct foo),
6341	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
6342	p->count = count + SIZE_INCR;
6343	}
6344
6345	The next example updates ``p->count``, but breaks the relationship requirement
6346	that ``p->array`` must have at least ``p->count`` number of elements available:
6347
6348	.. code-block:: c
6349
6350	#define SIZE_INCR 42
6351
6352	struct foo *p;
6353
6354	void foo_alloc(size_t count) {
6355	p = malloc(MAX(sizeof(struct foo),
6356	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
6357	p->count = count;
6358	}
6359
6360	void use_foo(int index, int val) {
6361	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
6362	p->array[index] = val; /* The sanitizer can't properly check this access. */
6363	}
6364
6365	In this example, an update to ``p->count`` maintains the relationship
6366	requirement:
6367
6368	.. code-block:: c
6369
6370	void use_foo(int index, int val) {
6371	if (p->count == 0)
6372	return;
6373	--p->count;
6374	p->array[index] = val;
6375	})reST";
6376
6377	static const char AttrDoc_SizedByOrNull[] = R"reST(Clang supports the ``counted_by`` attribute on the flexible array member of a
6378	structure in C. The argument for the attribute is the name of a field member
6379	holding the count of elements in the flexible array. This information can be
6380	used to improve the results of the array bound sanitizer and the
6381	``__builtin_dynamic_object_size`` builtin. The ``count`` field member must be
6382	within the same non-anonymous, enclosing struct as the flexible array member.
6383
6384	This example specifies that the flexible array member ``array`` has the number
6385	of elements allocated for it in ``count``:
6386
6387	.. code-block:: c
6388
6389	struct bar;
6390
6391	struct foo {
6392	size_t count;
6393	char other;
6394	struct bar *array[] __attribute__((counted_by(count)));
6395	};
6396
6397	This establishes a relationship between ``array`` and ``count``. Specifically,
6398	``array`` must have at least ``count`` number of elements available. It's the
6399	user's responsibility to ensure that this relationship is maintained through
6400	changes to the structure.
6401
6402	In the following example, the allocated array erroneously has fewer elements
6403	than what's specified by ``p->count``. This would result in an out-of-bounds
6404	access not being detected.
6405
6406	.. code-block:: c
6407
6408	#define SIZE_INCR 42
6409
6410	struct foo *p;
6411
6412	void foo_alloc(size_t count) {
6413	p = malloc(MAX(sizeof(struct foo),
6414	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
6415	p->count = count + SIZE_INCR;
6416	}
6417
6418	The next example updates ``p->count``, but breaks the relationship requirement
6419	that ``p->array`` must have at least ``p->count`` number of elements available:
6420
6421	.. code-block:: c
6422
6423	#define SIZE_INCR 42
6424
6425	struct foo *p;
6426
6427	void foo_alloc(size_t count) {
6428	p = malloc(MAX(sizeof(struct foo),
6429	offsetof(struct foo, array[0]) + count * sizeof(struct bar *)));
6430	p->count = count;
6431	}
6432
6433	void use_foo(int index, int val) {
6434	p->count += SIZE_INCR + 1; /* 'count' is now larger than the number of elements of 'array'. */
6435	p->array[index] = val; /* The sanitizer can't properly check this access. */
6436	}
6437
6438	In this example, an update to ``p->count`` maintains the relationship
6439	requirement:
6440
6441	.. code-block:: c
6442
6443	void use_foo(int index, int val) {
6444	if (p->count == 0)
6445	return;
6446	--p->count;
6447	p->array[index] = val;
6448	})reST";
6449
6450	static const char AttrDoc_SpeculativeLoadHardening[] = R"reST(This attribute can be applied to a function declaration in order to indicate
6451	that `Speculative Load Hardening <https://llvm.org/docs/SpeculativeLoadHardening.html>`_
6452	should be enabled for the function body. This can also be applied to a method
6453	in Objective C. This attribute will take precedence over the command line flag in
6454	the case where `-mno-speculative-load-hardening <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mspeculative-load-hardening>`_ is specified.
6455
6456	Speculative Load Hardening is a best-effort mitigation against
6457	information leak attacks that make use of control flow
6458	miss-speculation - specifically miss-speculation of whether a branch
6459	is taken or not. Typically vulnerabilities enabling such attacks are
6460	classified as "Spectre variant #1". Notably, this does not attempt to
6461	mitigate against miss-speculation of branch target, classified as
6462	"Spectre variant #2" vulnerabilities.
6463
6464	When inlining, the attribute is sticky. Inlining a function that
6465	carries this attribute will cause the caller to gain the
6466	attribute. This is intended to provide a maximally conservative model
6467	where the code in a function annotated with this attribute will always
6468	(even after inlining) end up hardened.)reST";
6469
6470	static const char AttrDoc_StandaloneDebug[] = R"reST(The ``standalone_debug`` attribute causes debug info to be emitted for a record
6471	type regardless of the debug info optimizations that are enabled with
6472	-fno-standalone-debug. This attribute only has an effect when debug info
6473	optimizations are enabled (e.g. with -fno-standalone-debug), and is C++-only.)reST";
6474
6475	static const char AttrDoc_StdCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
6476	function to clear parameters off of the stack on return. This convention does
6477	not support variadic calls or unprototyped functions in C, and has no effect on
6478	x86_64 targets. This calling convention is used widely by the Windows API and
6479	COM applications. See the documentation for `__stdcall`_ on MSDN.
6480
6481	.. _`__stdcall`: http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx)reST";
6482
6483	static const char AttrDoc_StrictFP[] = R"reST()reST";
6484
6485	static const char AttrDoc_StrictGuardStackCheck[] = R"reST(Clang supports the Microsoft style ``__declspec((strict_gs_check))`` attribute
6486	which upgrades the stack protector check from ``-fstack-protector`` to
6487	``-fstack-protector-strong``.
6488
6489	For example, it upgrades the stack protector for the function ``foo`` to
6490	``-fstack-protector-strong`` but function ``bar`` will still be built with the
6491	stack protector with the ``-fstack-protector`` option.
6492
6493	.. code-block:: c
6494
6495	__declspec((strict_gs_check))
6496	int foo(int x); // stack protection will be upgraded for foo.
6497
6498	int bar(int y); // bar can be built with the standard stack protector checks.)reST";
6499
6500	static const char AttrDoc_Suppress[] = R"reST(The ``suppress`` attribute suppresses unwanted warnings coming from static
6501	analysis tools such as the Clang Static Analyzer. The tool will not report
6502	any issues in source code annotated with the attribute.
6503
6504	The attribute cannot be used to suppress traditional Clang warnings, because
6505	many such warnings are emitted before the attribute is fully parsed.
6506	Consider using ``#pragma clang diagnostic`` to control such diagnostics,
6507	as described in `Controlling Diagnostics via Pragmas
6508	<https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas>`_.
6509
6510	The ``suppress`` attribute can be placed on an individual statement in order to
6511	suppress warnings about undesirable behavior occurring at that statement:
6512
6513	.. code-block:: c++
6514
6515	int foo() {
6516	int *x = nullptr;
6517	...
6518	[[clang::suppress]]
6519	return *x; // null pointer dereference warning suppressed here
6520	}
6521
6522	Putting the attribute on a compound statement suppresses all warnings in scope:
6523
6524	.. code-block:: c++
6525
6526	int foo() {
6527	[[clang::suppress]] {
6528	int *x = nullptr;
6529	...
6530	return *x; // warnings suppressed in the entire scope
6531	}
6532	}
6533
6534	The attribute can also be placed on entire declarations of functions, classes,
6535	variables, member variables, and so on, to suppress warnings related
6536	to the declarations themselves. When used this way, the attribute additionally
6537	suppresses all warnings in the lexical scope of the declaration:
6538
6539	.. code-block:: c++
6540
6541	class [[clang::suppress]] C {
6542	int foo() {
6543	int *x = nullptr;
6544	...
6545	return *x; // warnings suppressed in the entire class scope
6546	}
6547
6548	int bar();
6549	};
6550
6551	int C::bar() {
6552	int *x = nullptr;
6553	...
6554	return *x; // warning NOT suppressed! - not lexically nested in 'class C{}'
6555	}
6556
6557	Some static analysis warnings are accompanied by one or more notes, and the
6558	line of code against which the warning is emitted isn't necessarily the best
6559	for suppression purposes. In such cases the tools are allowed to implement
6560	additional ways to suppress specific warnings based on the attribute attached
6561	to a note location.
6562
6563	For example, the Clang Static Analyzer suppresses memory leak warnings when
6564	the suppression attribute is placed at the allocation site (highlited by
6565	a "note: memory is allocated"), which may be different from the line of code
6566	at which the program "loses track" of the pointer (where the warning
6567	is ultimately emitted):
6568
6569	.. code-block:: c
6570
6571	int bar1(bool coin_flip) {
6572	__attribute__((suppress))
6573	int result = (int )malloc(sizeof(int));
6574	if (coin_flip)
6575	return 1; // warning about this leak path is suppressed
6576
6577	return *result; // warning about this leak path is also suppressed
6578	}
6579
6580	int bar2(bool coin_flip) {
6581	int result = (int )malloc(sizeof(int));
6582	if (coin_flip)
6583	return 1; // leak warning on this path NOT suppressed
6584
6585	__attribute__((suppress))
6586	return *result; // leak warning is suppressed only on this path
6587	}
6588
6589
6590	When written as ``[[gsl::suppress]]``, this attribute suppresses specific
6591	clang-tidy diagnostics for rules of the `C++ Core Guidelines`_ in a portable
6592	way. The attribute can be attached to declarations, statements, and at
6593	namespace scope.
6594
6595	.. code-block:: c++
6596
6597	[[gsl::suppress("Rh-public")]]
6598	void f_() {
6599	int *p;
6600	[[gsl::suppress("type")]] {
6601	p = reinterpret_cast<int*>(7);
6602	}
6603	}
6604	namespace N {
6605	[[clang::suppress("type", "bounds")]];
6606	...
6607	}
6608
6609	.. _`C++ Core Guidelines`: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#inforce-enforcement)reST";
6610
6611	static const char AttrDoc_SwiftAsync[] = R"reST(The ``swift_async`` attribute specifies if and how a particular function or
6612	Objective-C method is imported into a swift async method. For instance:
6613
6614	.. code-block:: objc
6615
6616	@interface MyClass : NSObject
6617	-(void)notActuallyAsync:(int)p1 withCompletionHandler:(void (^)())handler
6618	__attribute__((swift_async(none)));
6619
6620	-(void)actuallyAsync:(int)p1 callThisAsync:(void (^)())fun
6621	__attribute__((swift_async(swift_private, 1)));
6622	@end
6623
6624	Here, ``notActuallyAsync:withCompletionHandler`` would have been imported as
6625	``async`` (because it's last parameter's selector piece is
6626	``withCompletionHandler``) if not for the ``swift_async(none)`` attribute.
6627	Conversely, ``actuallyAsync:callThisAsync`` wouldn't have been imported as
6628	``async`` if not for the ``swift_async`` attribute because it doesn't match the
6629	naming convention.
6630
6631	When using ``swift_async`` to enable importing, the first argument to the
6632	attribute is either ``swift_private`` or ``not_swift_private`` to indicate
6633	whether the function/method is private to the current framework, and the second
6634	argument is the index of the completion handler parameter.)reST";
6635
6636	static const char AttrDoc_SwiftAsyncCall[] = R"reST(The ``swiftasynccall`` attribute indicates that a function is
6637	compatible with the low-level conventions of Swift async functions,
6638	provided it declares the right formal arguments.
6639
6640	In most respects, this is similar to the ``swiftcall`` attribute, except for
6641	the following:
6642
6643	- A parameter may be marked ``swift_async_context``, ``swift_context``
6644	or ``swift_indirect_result`` (with the same restrictions on parameter
6645	ordering as ``swiftcall``) but the parameter attribute
6646	``swift_error_result`` is not permitted.
6647
6648	- A ``swiftasynccall`` function must have return type ``void``.
6649
6650	- Within a ``swiftasynccall`` function, a call to a ``swiftasynccall``
6651	function that is the immediate operand of a ``return`` statement is
6652	guaranteed to be performed as a tail call. This syntax is allowed even
6653	in C as an extension (a call to a void-returning function cannot be a
6654	return operand in standard C). If something in the calling function would
6655	semantically be performed after a guaranteed tail call, such as the
6656	non-trivial destruction of a local variable or temporary,
6657	then the program is ill-formed.
6658
6659	Query for this attribute with ``__has_attribute(swiftasynccall)``. Query if
6660	the target supports the calling convention with
6661	``__has_extension(swiftasynccc)``.)reST";
6662
6663	static const char AttrDoc_SwiftAsyncContext[] = R"reST(The ``swift_async_context`` attribute marks a parameter of a ``swiftasynccall``
6664	function as having the special asynchronous context-parameter ABI treatment.
6665
6666	If the function is not ``swiftasynccall``, this attribute only generates
6667	extended frame information.
6668
6669	A context parameter must have pointer or reference type.)reST";
6670
6671	static const char AttrDoc_SwiftAsyncError[] = R"reST(The ``swift_async_error`` attribute specifies how an error state will be
6672	represented in a swift async method. It's a bit analogous to the ``swift_error``
6673	attribute for the generated async method. The ``swift_async_error`` attribute
6674	can indicate a variety of different ways of representing an error.
6675
6676	- ``__attribute__((swift_async_error(zero_argument, N)))``, specifies that the
6677	async method is considered to have failed if the Nth argument to the
6678	completion handler is zero.
6679
6680	- ``__attribute__((swift_async_error(nonzero_argument, N)))``, specifies that
6681	the async method is considered to have failed if the Nth argument to the
6682	completion handler is non-zero.
6683
6684	- ``__attribute__((swift_async_error(nonnull_error)))``, specifies that the
6685	async method is considered to have failed if the ``NSError *`` argument to the
6686	completion handler is non-null.
6687
6688	- ``__attribute__((swift_async_error(none)))``, specifies that the async method
6689	cannot fail.
6690
6691
6692	For instance:
6693
6694	.. code-block:: objc
6695
6696	@interface MyClass : NSObject
6697	-(void)asyncMethod:(void (^)(char, int, float))handler
6698	__attribute__((swift_async(swift_private, 1)))
6699	__attribute__((swift_async_error(zero_argument, 2)));
6700	@end
6701
6702	Here, the ``swift_async`` attribute specifies that ``handler`` is the completion
6703	handler for this method, and the ``swift_async_error`` attribute specifies that
6704	the ``int`` parameter is the one that represents the error.)reST";
6705
6706	static const char AttrDoc_SwiftAsyncName[] = R"reST(The ``swift_async_name`` attribute provides the name of the ``async`` overload for
6707	the given declaration in Swift. If this attribute is absent, the name is
6708	transformed according to the algorithm built into the Swift compiler.
6709
6710	The argument is a string literal that contains the Swift name of the function or
6711	method. The name may be a compound Swift name. The function or method with such
6712	an attribute must have more than zero parameters, as its last parameter is
6713	assumed to be a callback that's eliminated in the Swift ``async`` name.
6714
6715	.. code-block:: objc
6716
6717	@interface URL
6718	+ (void) loadContentsFrom:(URL )url callback:(void (^)(NSData ))data __attribute__((__swift_async_name__("URL.loadContentsFrom(_:)")))
6719	@end)reST";
6720
6721	static const char AttrDoc_SwiftAttr[] = R"reST(The ``swift_attr`` provides a Swift-specific annotation for the declaration
6722	to which the attribute appertains to. It can be used on any declaration
6723	in Clang. This kind of annotation is ignored by Clang as it doesn't have any
6724	semantic meaning in languages supported by Clang. The Swift compiler can
6725	interpret these annotations according to its own rules when importing C or
6726	Objective-C declarations.)reST";
6727
6728	static const char AttrDoc_SwiftBridge[] = R"reST(The ``swift_bridge`` attribute indicates that the declaration to which the
6729	attribute appertains is bridged to the named Swift type.
6730
6731	.. code-block:: objc
6732
6733	__attribute__((__objc_root__))
6734	@interface Base
6735	- (instancetype)init;
6736	@end
6737
6738	__attribute__((__swift_bridge__("BridgedI")))
6739	@interface I : Base
6740	@end
6741
6742	In this example, the Objective-C interface ``I`` will be made available to Swift
6743	with the name ``BridgedI``. It would be possible for the compiler to refer to
6744	``I`` still in order to bridge the type back to Objective-C.)reST";
6745
6746	static const char AttrDoc_SwiftBridgedTypedef[] = R"reST(The ``swift_bridged_typedef`` attribute indicates that when the typedef to which
6747	the attribute appertains is imported into Swift, it should refer to the bridged
6748	Swift type (e.g. Swift's ``String``) rather than the Objective-C type as written
6749	(e.g. ``NSString``).
6750
6751	.. code-block:: objc
6752
6753	@interface NSString;
6754	typedef NSString *AliasedString __attribute__((__swift_bridged_typedef__));
6755
6756	extern void acceptsAliasedString(AliasedString _Nonnull parameter);
6757
6758	In this case, the function ``acceptsAliasedString`` will be imported into Swift
6759	as a function which accepts a ``String`` type parameter.)reST";
6760
6761	static const char AttrDoc_SwiftCall[] = R"reST(The ``swiftcall`` attribute indicates that a function should be called
6762	using the Swift calling convention for a function or function pointer.
6763
6764	The lowering for the Swift calling convention, as described by the Swift
6765	ABI documentation, occurs in multiple phases. The first, "high-level"
6766	phase breaks down the formal parameters and results into innately direct
6767	and indirect components, adds implicit parameters for the generic
6768	signature, and assigns the context and error ABI treatments to parameters
6769	where applicable. The second phase breaks down the direct parameters
6770	and results from the first phase and assigns them to registers or the
6771	stack. The ``swiftcall`` convention only handles this second phase of
6772	lowering; the C function type must accurately reflect the results
6773	of the first phase, as follows:
6774
6775	- Results classified as indirect by high-level lowering should be
6776	represented as parameters with the ``swift_indirect_result`` attribute.
6777
6778	- Results classified as direct by high-level lowering should be represented
6779	as follows:
6780
6781	- First, remove any empty direct results.
6782
6783	- If there are no direct results, the C result type should be ``void``.
6784
6785	- If there is one direct result, the C result type should be a type with
6786	the exact layout of that result type.
6787
6788	- If there are a multiple direct results, the C result type should be
6789	a struct type with the exact layout of a tuple of those results.
6790
6791	- Parameters classified as indirect by high-level lowering should be
6792	represented as parameters of pointer type.
6793
6794	- Parameters classified as direct by high-level lowering should be
6795	omitted if they are empty types; otherwise, they should be represented
6796	as a parameter type with a layout exactly matching the layout of the
6797	Swift parameter type.
6798
6799	- The context parameter, if present, should be represented as a trailing
6800	parameter with the ``swift_context`` attribute.
6801
6802	- The error result parameter, if present, should be represented as a
6803	trailing parameter (always following a context parameter) with the
6804	``swift_error_result`` attribute.
6805
6806	``swiftcall`` does not support variadic arguments or unprototyped functions.
6807
6808	The parameter ABI treatment attributes are aspects of the function type.
6809	A function type which applies an ABI treatment attribute to a
6810	parameter is a different type from an otherwise-identical function type
6811	that does not. A single parameter may not have multiple ABI treatment
6812	attributes.
6813
6814	Support for this feature is target-dependent, although it should be
6815	supported on every target that Swift supports. Query for this attribute
6816	with ``__has_attribute(swiftcall)``. Query if the target supports the
6817	calling convention with ``__has_extension(swiftcc)``. This implies
6818	support for the ``swift_context``, ``swift_error_result``, and
6819	``swift_indirect_result`` attributes.)reST";
6820
6821	static const char AttrDoc_SwiftContext[] = R"reST(The ``swift_context`` attribute marks a parameter of a ``swiftcall``
6822	or ``swiftasynccall`` function as having the special context-parameter
6823	ABI treatment.
6824
6825	This treatment generally passes the context value in a special register
6826	which is normally callee-preserved.
6827
6828	A ``swift_context`` parameter must either be the last parameter or must be
6829	followed by a ``swift_error_result`` parameter (which itself must always be
6830	the last parameter).
6831
6832	A context parameter must have pointer or reference type.)reST";
6833
6834	static const char AttrDoc_SwiftError[] = R"reST(The ``swift_error`` attribute controls whether a particular function (or
6835	Objective-C method) is imported into Swift as a throwing function, and if so,
6836	which dynamic convention it uses.
6837
6838	All of these conventions except ``none`` require the function to have an error
6839	parameter. Currently, the error parameter is always the last parameter of type
6840	``NSError*`` or ``CFErrorRef``. Swift will remove the error parameter from
6841	the imported API. When calling the API, Swift will always pass a valid address
6842	initialized to a null pointer.
6843
6844	* ``swift_error(none)`` means that the function should not be imported as
6845	throwing. The error parameter and result type will be imported normally.
6846
6847	* ``swift_error(null_result)`` means that calls to the function should be
6848	considered to have thrown if they return a null value. The return type must be
6849	a pointer type, and it will be imported into Swift with a non-optional type.
6850	This is the default error convention for Objective-C methods that return
6851	pointers.
6852
6853	* ``swift_error(zero_result)`` means that calls to the function should be
6854	considered to have thrown if they return a zero result. The return type must be
6855	an integral type. If the return type would have been imported as ``Bool``, it
6856	is instead imported as ``Void``. This is the default error convention for
6857	Objective-C methods that return a type that would be imported as ``Bool``.
6858
6859	* ``swift_error(nonzero_result)`` means that calls to the function should be
6860	considered to have thrown if they return a non-zero result. The return type must
6861	be an integral type. If the return type would have been imported as ``Bool``,
6862	it is instead imported as ``Void``.
6863
6864	* ``swift_error(nonnull_error)`` means that calls to the function should be
6865	considered to have thrown if they leave a non-null error in the error parameter.
6866	The return type is left unmodified.)reST";
6867
6868	static const char AttrDoc_SwiftErrorResult[] = R"reST(The ``swift_error_result`` attribute marks a parameter of a ``swiftcall``
6869	function as having the special error-result ABI treatment.
6870
6871	This treatment generally passes the underlying error value in and out of
6872	the function through a special register which is normally callee-preserved.
6873	This is modeled in C by pretending that the register is addressable memory:
6874
6875	- The caller appears to pass the address of a variable of pointer type.
6876	The current value of this variable is copied into the register before
6877	the call; if the call returns normally, the value is copied back into the
6878	variable.
6879
6880	- The callee appears to receive the address of a variable. This address
6881	is actually a hidden location in its own stack, initialized with the
6882	value of the register upon entry. When the function returns normally,
6883	the value in that hidden location is written back to the register.
6884
6885	A ``swift_error_result`` parameter must be the last parameter, and it must be
6886	preceded by a ``swift_context`` parameter.
6887
6888	A ``swift_error_result`` parameter must have type ``T*`` or ``T&`` for some
6889	type T. Note that no qualifiers are permitted on the intermediate level.
6890
6891	It is undefined behavior if the caller does not pass a pointer or
6892	reference to a valid object.
6893
6894	The standard convention is that the error value itself (that is, the
6895	value stored in the apparent argument) will be null upon function entry,
6896	but this is not enforced by the ABI.)reST";
6897
6898	static const char AttrDoc_SwiftImportAsNonGeneric[] = R"reST()reST";
6899
6900	static const char AttrDoc_SwiftImportPropertyAsAccessors[] = R"reST()reST";
6901
6902	static const char AttrDoc_SwiftIndirectResult[] = R"reST(The ``swift_indirect_result`` attribute marks a parameter of a ``swiftcall``
6903	or ``swiftasynccall`` function as having the special indirect-result ABI
6904	treatment.
6905
6906	This treatment gives the parameter the target's normal indirect-result
6907	ABI treatment, which may involve passing it differently from an ordinary
6908	parameter. However, only the first indirect result will receive this
6909	treatment. Furthermore, low-level lowering may decide that a direct result
6910	must be returned indirectly; if so, this will take priority over the
6911	``swift_indirect_result`` parameters.
6912
6913	A ``swift_indirect_result`` parameter must either be the first parameter or
6914	follow another ``swift_indirect_result`` parameter.
6915
6916	A ``swift_indirect_result`` parameter must have type ``T*`` or ``T&`` for
6917	some object type ``T``. If ``T`` is a complete type at the point of
6918	definition of a function, it is undefined behavior if the argument
6919	value does not point to storage of adequate size and alignment for a
6920	value of type ``T``.
6921
6922	Making indirect results explicit in the signature allows C functions to
6923	directly construct objects into them without relying on language
6924	optimizations like C++'s named return value optimization (NRVO).)reST";
6925
6926	static const char AttrDoc_SwiftName[] = R"reST(The ``swift_name`` attribute provides the name of the declaration in Swift. If
6927	this attribute is absent, the name is transformed according to the algorithm
6928	built into the Swift compiler.
6929
6930	The argument is a string literal that contains the Swift name of the function,
6931	variable, or type. When renaming a function, the name may be a compound Swift
6932	name. For a type, enum constant, property, or variable declaration, the name
6933	must be a simple or qualified identifier.
6934
6935	.. code-block:: objc
6936
6937	@interface URL
6938	- (void) initWithString:(NSString *)s __attribute__((__swift_name__("URL.init(_:)")))
6939	@end
6940
6941	void __attribute__((__swift_name__("squareRoot()"))) sqrt(double v) {
6942	})reST";
6943
6944	static const char AttrDoc_SwiftNewType[] = R"reST(The ``swift_newtype`` attribute indicates that the typedef to which the
6945	attribute appertains is imported as a new Swift type of the typedef's name.
6946	Previously, the attribute was spelt ``swift_wrapper``. While the behaviour of
6947	the attribute is identical with either spelling, ``swift_wrapper`` is
6948	deprecated, only exists for compatibility purposes, and should not be used in
6949	new code.
6950
6951	* ``swift_newtype(struct)`` means that a Swift struct will be created for this
6952	typedef.
6953
6954	* ``swift_newtype(enum)`` means that a Swift enum will be created for this
6955	typedef.
6956
6957	.. code-block:: c
6958
6959	// Import UIFontTextStyle as an enum type, with enumerated values being
6960	// constants.
6961	typedef NSString * UIFontTextStyle __attribute__((__swift_newtype__(enum)));
6962
6963	// Import UIFontDescriptorFeatureKey as a structure type, with enumerated
6964	// values being members of the type structure.
6965	typedef NSString * UIFontDescriptorFeatureKey __attribute__((__swift_newtype__(struct)));)reST";
6966
6967	static const char AttrDoc_SwiftObjCMembers[] = R"reST(This attribute indicates that Swift subclasses and members of Swift extensions
6968	of this class will be implicitly marked with the ``@objcMembers`` Swift
6969	attribute, exposing them back to Objective-C.)reST";
6970
6971	static const char AttrDoc_SwiftPrivate[] = R"reST(Declarations marked with the ``swift_private`` attribute are hidden from the
6972	framework client but are still made available for use within the framework or
6973	Swift SDK overlay.
6974
6975	The purpose of this attribute is to permit a more idomatic implementation of
6976	declarations in Swift while hiding the non-idiomatic one.)reST";
6977
6978	static const char AttrDoc_SwiftVersionedAddition[] = R"reST()reST";
6979
6980	static const char AttrDoc_SwiftVersionedRemoval[] = R"reST()reST";
6981
6982	static const char AttrDoc_SysVABI[] = R"reST(On Windows x86_64 targets, this attribute changes the calling convention of a
6983	function to match the default convention used on Sys V targets such as Linux,
6984	Mac, and BSD. This attribute has no effect on other targets.)reST";
6985
6986	static const char AttrDoc_TLSModel[] = R"reST(The ``tls_model`` attribute allows you to specify which thread-local storage
6987	model to use. It accepts the following strings:
6988
6989	* global-dynamic
6990	* local-dynamic
6991	* initial-exec
6992	* local-exec
6993
6994	TLS models are mutually exclusive.)reST";
6995
6996	static const char AttrDoc_Target[] = R"reST(Clang supports the GNU style ``__attribute__((target("OPTIONS")))`` attribute.
6997	This attribute may be attached to a function definition and instructs
6998	the backend to use different code generation options than were passed on the
6999	command line.
7000
7001	The current set of options correspond to the existing "subtarget features" for
7002	the target with or without a "-mno-" in front corresponding to the absence
7003	of the feature, as well as ``arch="CPU"`` which will change the default "CPU"
7004	for the function.
7005
7006	For X86, the attribute also allows ``tune="CPU"`` to optimize the generated
7007	code for the given CPU without changing the available instructions.
7008
7009	For AArch64, ``arch="Arch"`` will set the architecture, similar to the -march
7010	command line options. ``cpu="CPU"`` can be used to select a specific cpu,
7011	as per the ``-mcpu`` option, similarly for ``tune=``. The attribute also allows the
7012	"branch-protection=<args>" option, where the permissible arguments and their
7013	effect on code generation are the same as for the command-line option
7014	``-mbranch-protection``.
7015
7016	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
7017	"avx", "xop" and largely correspond to the machine specific options handled by
7018	the front end.
7019
7020	Note that this attribute does not apply transitively to nested functions such
7021	as blocks or C++ lambdas.
7022
7023	Additionally, this attribute supports function multiversioning for ELF based
7024	x86/x86-64 targets, which can be used to create multiple implementations of the
7025	same function that will be resolved at runtime based on the priority of their
7026	``target`` attribute strings. A function is considered a multiversioned function
7027	if either two declarations of the function have different ``target`` attribute
7028	strings, or if it has a ``target`` attribute string of ``default``. For
7029	example:
7030
7031	.. code-block:: c++
7032
7033	__attribute__((target("arch=atom")))
7034	void foo() {} // will be called on 'atom' processors.
7035	__attribute__((target("default")))
7036	void foo() {} // will be called on any other processors.
7037
7038	All multiversioned functions must contain a ``default`` (fallback)
7039	implementation, otherwise usages of the function are considered invalid.
7040	Additionally, a function may not become multiversioned after its first use.)reST";
7041
7042	static const char AttrDoc_TargetClones[] = R"reST(Clang supports the ``target_clones("OPTIONS")`` attribute. This attribute may be
7043	attached to a function declaration and causes function multiversioning, where
7044	multiple versions of the function will be emitted with different code
7045	generation options. Additionally, these versions will be resolved at runtime
7046	based on the priority of their attribute options. All ``target_clone`` functions
7047	are considered multiversioned functions.
7048
7049	For AArch64 target:
7050	The attribute contains comma-separated strings of target features joined by "+"
7051	sign. For example:
7052
7053	.. code-block:: c++
7054
7055	__attribute__((target_clones("sha2+memtag2", "fcma+sve2-pmull128")))
7056	void foo() {}
7057
7058	For every multiversioned function a ``default`` (fallback) implementation
7059	always generated if not specified directly.
7060
7061	For x86/x86-64 targets:
7062	All multiversioned functions must contain a ``default`` (fallback)
7063	implementation, otherwise usages of the function are considered invalid.
7064	Additionally, a function may not become multiversioned after its first use.
7065
7066	The options to ``target_clones`` can either be a target-specific architecture
7067	(specified as ``arch=CPU``), or one of a list of subtarget features.
7068
7069	Example "subtarget features" from the x86 backend include: "mmx", "sse", "sse4.2",
7070	"avx", "xop" and largely correspond to the machine specific options handled by
7071	the front end.
7072
7073	The versions can either be listed as a comma-separated sequence of string
7074	literals or as a single string literal containing a comma-separated list of
7075	versions. For compatibility with GCC, the two formats can be mixed. For
7076	example, the following will emit 4 versions of the function:
7077
7078	.. code-block:: c++
7079
7080	__attribute__((target_clones("arch=atom,avx2","arch=ivybridge","default")))
7081	void foo() {}
7082
7083	For targets that support the GNU indirect function (IFUNC) feature, dispatch
7084	is performed by emitting an indirect function that is resolved to the appropriate
7085	target clone at load time. The indirect function is given the name the
7086	multiversioned function would have if it had been declared without the attribute.
7087	For backward compatibility with earlier Clang releases, a function alias with an
7088	``.ifunc`` suffix is also emitted. The ``.ifunc`` suffixed symbol is a deprecated
7089	feature and support for it may be removed in the future.)reST";
7090
7091	static const char AttrDoc_TargetVersion[] = R"reST(For AArch64 target clang supports function multiversioning by
7092	``__attribute__((target_version("OPTIONS")))`` attribute. When applied to a
7093	function it instructs compiler to emit multiple function versions based on
7094	``target_version`` attribute strings, which resolved at runtime depend on their
7095	priority and target features availability. One of the versions is always
7096	( implicitly or explicitly ) the ``default`` (fallback). Attribute strings can
7097	contain dependent features names joined by the "+" sign.
7098
7099	For targets that support the GNU indirect function (IFUNC) feature, dispatch
7100	is performed by emitting an indirect function that is resolved to the appropriate
7101	target clone at load time. The indirect function is given the name the
7102	multiversioned function would have if it had been declared without the attribute.
7103	For backward compatibility with earlier Clang releases, a function alias with an
7104	``.ifunc`` suffix is also emitted. The ``.ifunc`` suffixed symbol is a deprecated
7105	feature and support for it may be removed in the future.)reST";
7106
7107	static const char AttrDoc_TestTypestate[] = R"reST(Use ``__attribute__((test_typestate(tested_state)))`` to indicate that a method
7108	returns true if the object is in the specified state..)reST";
7109
7110	static const char AttrDoc_ThisCall[] = R"reST(On 32-bit x86 targets, this attribute changes the calling convention of a
7111	function to use ECX for the first parameter (typically the implicit ``this``
7112	parameter of C++ methods) and clear parameters off of the stack on return. This
7113	convention does not support variadic calls or unprototyped functions in C, and
7114	has no effect on x86_64 targets. See the documentation for `__thiscall`_ on
7115	MSDN.
7116
7117	.. _`__thiscall`: http://msdn.microsoft.com/en-us/library/ek8tkfbw.aspx)reST";
7118
7119	static const char AttrDoc_Thread[] = R"reST(The ``__declspec(thread)`` attribute declares a variable with thread local
7120	storage. It is available under the ``-fms-extensions`` flag for MSVC
7121	compatibility. See the documentation for `__declspec(thread)`_ on MSDN.
7122
7123	.. _`__declspec(thread)`: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx
7124
7125	In Clang, ``__declspec(thread)`` is generally equivalent in functionality to the
7126	GNU ``__thread`` keyword. The variable must not have a destructor and must have
7127	a constant initializer, if any. The attribute only applies to variables
7128	declared with static storage duration, such as globals, class static data
7129	members, and static locals.)reST";
7130
7131	static const char AttrDoc_TransparentUnion[] = R"reST(This attribute can be applied to a union to change the behavior of calls to
7132	functions that have an argument with a transparent union type. The compiler
7133	behavior is changed in the following manner:
7134
7135	- A value whose type is any member of the transparent union can be passed as an
7136	argument without the need to cast that value.
7137
7138	- The argument is passed to the function using the calling convention of the
7139	first member of the transparent union. Consequently, all the members of the
7140	transparent union should have the same calling convention as its first member.
7141
7142	Transparent unions are not supported in C++.)reST";
7143
7144	static const char AttrDoc_TrivialABI[] = R"reST(The ``trivial_abi`` attribute can be applied to a C++ class, struct, or union.
7145	It instructs the compiler to pass and return the type using the C ABI for the
7146	underlying type when the type would otherwise be considered non-trivial for the
7147	purpose of calls.
7148	A class annotated with ``trivial_abi`` can have non-trivial destructors or
7149	copy/move constructors without automatically becoming non-trivial for the
7150	purposes of calls. For example:
7151
7152	.. code-block:: c++
7153
7154	// A is trivial for the purposes of calls because ``trivial_abi`` makes the
7155	// user-provided special functions trivial.
7156	struct __attribute__((trivial_abi)) A {
7157	~A();
7158	A(const A &);
7159	A(A &&);
7160	int x;
7161	};
7162
7163	// B's destructor and copy/move constructor are considered trivial for the
7164	// purpose of calls because A is trivial.
7165	struct B {
7166	A a;
7167	};
7168
7169	If a type is trivial for the purposes of calls, has a non-trivial destructor,
7170	and is passed as an argument by value, the convention is that the callee will
7171	destroy the object before returning.
7172
7173	If a type is trivial for the purpose of calls, it is assumed to be trivially
7174	relocatable for the purpose of ``__is_trivially_relocatable``.
7175
7176	Attribute ``trivial_abi`` has no effect in the following cases:
7177
7178	- The class directly declares a virtual base or virtual methods.
7179	- Copy constructors and move constructors of the class are all deleted.
7180	- The class has a base class that is non-trivial for the purposes of calls.
7181	- The class has a non-static data member whose type is non-trivial for the
7182	purposes of calls, which includes:
7183
7184	- classes that are non-trivial for the purposes of calls
7185	- __weak-qualified types in Objective-C++
7186	- arrays of any of the above)reST";
7187
7188	static const char AttrDoc_TryAcquireCapability[] = R"reST(Marks a function that attempts to acquire a capability. This function may fail to
7189	actually acquire the capability; they accept a Boolean value determining
7190	whether acquiring the capability means success (true), or failing to acquire
7191	the capability means success (false).)reST";
7192
7193	static const char AttrDoc_TypeNonNull[] = R"reST(The ``_Nonnull`` nullability qualifier indicates that null is not a meaningful
7194	value for a value of the ``_Nonnull`` pointer type. For example, given a
7195	declaration such as:
7196
7197	.. code-block:: c
7198
7199	int fetch(int * _Nonnull ptr);
7200
7201	a caller of ``fetch`` should not provide a null value, and the compiler will
7202	produce a warning if it sees a literal null value passed to ``fetch``. Note
7203	that, unlike the declaration attribute ``nonnull``, the presence of
7204	``_Nonnull`` does not imply that passing null is undefined behavior: ``fetch``
7205	is free to consider null undefined behavior or (perhaps for
7206	backward-compatibility reasons) defensively handle null.)reST";
7207
7208	static const char AttrDoc_TypeNullUnspecified[] = R"reST(The ``_Null_unspecified`` nullability qualifier indicates that neither the
7209	``_Nonnull`` nor ``_Nullable`` qualifiers make sense for a particular pointer
7210	type. It is used primarily to indicate that the role of null with specific
7211	pointers in a nullability-annotated header is unclear, e.g., due to
7212	overly-complex implementations or historical factors with a long-lived API.)reST";
7213
7214	static const char AttrDoc_TypeNullable[] = R"reST(The ``_Nullable`` nullability qualifier indicates that a value of the
7215	``_Nullable`` pointer type can be null. For example, given:
7216
7217	.. code-block:: c
7218
7219	int fetch_or_zero(int * _Nullable ptr);
7220
7221	a caller of ``fetch_or_zero`` can provide null.
7222
7223	The ``_Nullable`` attribute on classes indicates that the given class can
7224	represent null values, and so the ``_Nullable``, ``_Nonnull`` etc qualifiers
7225	make sense for this type. For example:
7226
7227	.. code-block:: c
7228
7229	class _Nullable ArenaPointer { ... };
7230
7231	ArenaPointer _Nonnull x = ...;
7232	ArenaPointer _Nullable y = nullptr;)reST";
7233
7234	static const char AttrDoc_TypeNullableResult[] = R"reST(The ``_Nullable_result`` nullability qualifier means that a value of the
7235	``_Nullable_result`` pointer can be ``nil``, just like ``_Nullable``. Where this
7236	attribute differs from ``_Nullable`` is when it's used on a parameter to a
7237	completion handler in a Swift async method. For instance, here:
7238
7239	.. code-block:: objc
7240
7241	-(void)fetchSomeDataWithID:(int)identifier
7242	completionHandler:(void (^)(Data _Nullable_result result, NSError error))completionHandler;
7243
7244	This method asynchronously calls ``completionHandler`` when the data is
7245	available, or calls it with an error. ``_Nullable_result`` indicates to the
7246	Swift importer that this is the uncommon case where ``result`` can get ``nil``
7247	even if no error has occurred, and will therefore import it as a Swift optional
7248	type. Otherwise, if ``result`` was annotated with ``_Nullable``, the Swift
7249	importer will assume that ``result`` will always be non-nil unless an error
7250	occurred.)reST";
7251
7252	static const char AttrDoc_TypeTagForDatatype[] = R"reST(When declaring a variable, use
7253	``__attribute__((type_tag_for_datatype(kind, type)))`` to create a type tag that
7254	is tied to the ``type`` argument given to the attribute.
7255
7256	In the attribute prototype above:
7257	* ``kind`` is an identifier that should be used when annotating all applicable
7258	type tags.
7259	* ``type`` indicates the name of the type.
7260
7261	Clang supports annotating type tags of two forms.
7262
7263	* Type tag that is a reference to a declared identifier.
7264	Use ``__attribute__((type_tag_for_datatype(kind, type)))`` when declaring that
7265	identifier:
7266
7267	.. code-block:: c++
7268
7269	typedef int MPI_Datatype;
7270	extern struct mpi_datatype mpi_datatype_int
7271	__attribute__(( type_tag_for_datatype(mpi,int) ));
7272	#define MPI_INT ((MPI_Datatype) &mpi_datatype_int)
7273	// &mpi_datatype_int is a type tag. It is tied to type "int".
7274
7275	* Type tag that is an integral literal.
7276	Declare a ``static const`` variable with an initializer value and attach
7277	``__attribute__((type_tag_for_datatype(kind, type)))`` on that declaration:
7278
7279	.. code-block:: c++
7280
7281	typedef int MPI_Datatype;
7282	static const MPI_Datatype mpi_datatype_int
7283	__attribute__(( type_tag_for_datatype(mpi,int) )) = 42;
7284	#define MPI_INT ((MPI_Datatype) 42)
7285	// The number 42 is a type tag. It is tied to type "int".
7286
7287
7288	The ``type_tag_for_datatype`` attribute also accepts an optional third argument
7289	that determines how the type of the function argument specified by either
7290	``arg_idx`` or ``ptr_idx`` is compared against the type associated with the type
7291	tag. (Recall that for the ``argument_with_type_tag`` attribute, the type of the
7292	function argument specified by ``arg_idx`` is compared against the type
7293	associated with the type tag. Also recall that for the ``pointer_with_type_tag``
7294	attribute, the pointee type of the function argument specified by ``ptr_idx`` is
7295	compared against the type associated with the type tag.) There are two supported
7296	values for this optional third argument:
7297
7298	* ``layout_compatible`` will cause types to be compared according to
7299	layout-compatibility rules (In C++11 [class.mem] p 17, 18, see the
7300	layout-compatibility rules for two standard-layout struct types and for two
7301	standard-layout union types). This is useful when creating a type tag
7302	associated with a struct or union type. For example:
7303
7304	.. code-block:: c++
7305
7306	/* In mpi.h */
7307	typedef int MPI_Datatype;
7308	struct internal_mpi_double_int { double d; int i; };
7309	extern struct mpi_datatype mpi_datatype_double_int
7310	__attribute__(( type_tag_for_datatype(mpi,
7311	struct internal_mpi_double_int, layout_compatible) ));
7312
7313	#define MPI_DOUBLE_INT ((MPI_Datatype) &mpi_datatype_double_int)
7314
7315	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
7316	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
7317
7318	/* In user code */
7319	struct my_pair { double a; int b; };
7320	struct my_pair *buffer;
7321	MPI_Send(buffer, 1, MPI_DOUBLE_INT /, ... /); // no warning because the
7322	// layout of my_pair is
7323	// compatible with that of
7324	// internal_mpi_double_int
7325
7326	struct my_int_pair { int a; int b; }
7327	struct my_int_pair *buffer2;
7328	MPI_Send(buffer2, 1, MPI_DOUBLE_INT /, ... /); // warning because the
7329	// layout of my_int_pair
7330	// does not match that of
7331	// internal_mpi_double_int
7332
7333	* ``must_be_null`` specifies that the function argument specified by either
7334	``arg_idx`` (for the ``argument_with_type_tag`` attribute) or ``ptr_idx`` (for
7335	the ``pointer_with_type_tag`` attribute) should be a null pointer constant.
7336	The second argument to the ``type_tag_for_datatype`` attribute is ignored. For
7337	example:
7338
7339	.. code-block:: c++
7340
7341	/* In mpi.h */
7342	typedef int MPI_Datatype;
7343	extern struct mpi_datatype mpi_datatype_null
7344	__attribute__(( type_tag_for_datatype(mpi, void, must_be_null) ));
7345
7346	#define MPI_DATATYPE_NULL ((MPI_Datatype) &mpi_datatype_null)
7347	int MPI_Send(void *buf, int count, MPI_Datatype datatype, ...)
7348	__attribute__(( pointer_with_type_tag(mpi,1,3) ));
7349
7350	/* In user code */
7351	struct my_pair { double a; int b; };
7352	struct my_pair *buffer;
7353	MPI_Send(buffer, 1, MPI_DATATYPE_NULL /, ... /); // warning: MPI_DATATYPE_NULL
7354	// was specified but buffer
7355	// is not a null pointer)reST";
7356
7357	static const char AttrDoc_TypeVisibility[] = R"reST(The ``type_visibility`` attribute allows the visibility of a type and its vague
7358	linkage objects (vtable, typeinfo, typeinfo name) to be controlled separately from
7359	the visibility of functions and data members of the type.
7360
7361	For example, this can be used to give default visibility to the typeinfo and the vtable
7362	of a type while still keeping hidden visibility on its member functions and static data
7363	members.
7364
7365	This attribute can only be applied to types and namespaces.
7366
7367	If both ``visibility`` and ``type_visibility`` are applied to a type or a namespace, the
7368	visibility specified with the ``type_visibility`` attribute overrides the visibility
7369	provided with the regular ``visibility`` attribute.)reST";
7370
7371	static const char AttrDoc_UPtr[] = R"reST(The ``__uptr`` qualifier specifies that a 32-bit pointer should be zero
7372	extended when converted to a 64-bit pointer.)reST";
7373
7374	static const char AttrDoc_Unavailable[] = R"reST(No documentation.)reST";
7375
7376	static const char AttrDoc_Uninitialized[] = R"reST(The command-line parameter ``-ftrivial-auto-var-init=*`` can be used to
7377	initialize trivial automatic stack variables. By default, trivial automatic
7378	stack variables are uninitialized. This attribute is used to override the
7379	command-line parameter, forcing variables to remain uninitialized. It has no
7380	semantic meaning in that using uninitialized values is undefined behavior,
7381	it rather documents the programmer's intent.)reST";
7382
7383	static const char AttrDoc_Unlikely[] = R"reST(The ``likely`` and ``unlikely`` attributes are used as compiler hints.
7384	The attributes are used to aid the compiler to determine which branch is
7385	likely or unlikely to be taken. This is done by marking the branch substatement
7386	with one of the two attributes.
7387
7388	It isn't allowed to annotate a single statement with both ``likely`` and
7389	``unlikely``. Annotating the ``true`` and ``false`` branch of an ``if``
7390	statement with the same likelihood attribute will result in a diagnostic and
7391	the attributes are ignored on both branches.
7392
7393	In a ``switch`` statement it's allowed to annotate multiple ``case`` labels
7394	or the ``default`` label with the same likelihood attribute. This makes
7395	* all labels without an attribute have a neutral likelihood,
7396	* all labels marked ``[[likely]]`` have an equally positive likelihood, and
7397	* all labels marked ``[[unlikely]]`` have an equally negative likelihood.
7398	The neutral likelihood is the more likely of path execution than the negative
7399	likelihood. The positive likelihood is the more likely of path of execution
7400	than the neutral likelihood.
7401
7402	These attributes have no effect on the generated code when using
7403	PGO (Profile-Guided Optimization) or at optimization level 0.
7404
7405	In Clang, the attributes will be ignored if they're not placed on
7406	* the ``case`` or ``default`` label of a ``switch`` statement,
7407	* or on the substatement of an ``if`` or ``else`` statement,
7408	* or on the substatement of an ``for`` or ``while`` statement.
7409	The C++ Standard recommends to honor them on every statement in the
7410	path of execution, but that can be confusing:
7411
7412	.. code-block:: c++
7413
7414	if (b) {
7415	[[unlikely]] --b; // In the path of execution,
7416	// this branch is considered unlikely.
7417	}
7418
7419	if (b) {
7420	--b;
7421	if(b)
7422	return;
7423	[[unlikely]] --b; // Not in the path of execution,
7424	} // the branch has no likelihood information.
7425
7426	if (b) {
7427	--b;
7428	foo(b);
7429	// Whether or not the next statement is in the path of execution depends
7430	// on the declaration of foo():
7431	// In the path of execution: void foo(int);
7432	// Not in the path of execution: [[noreturn]] void foo(int);
7433	// This means the likelihood of the branch depends on the declaration
7434	// of foo().
7435	[[unlikely]] --b;
7436	}
7437
7438
7439	Below are some example usages of the likelihood attributes and their effects:
7440
7441	.. code-block:: c++
7442
7443	if (b) [[likely]] { // Placement on the first statement in the branch.
7444	// The compiler will optimize to execute the code here.
7445	} else {
7446	}
7447
7448	if (b)
7449	[[unlikely]] b++; // Placement on the first statement in the branch.
7450	else {
7451	// The compiler will optimize to execute the code here.
7452	}
7453
7454	if (b) {
7455	[[unlikely]] b++; // Placement on the second statement in the branch.
7456	} // The attribute will be ignored.
7457
7458	if (b) [[likely]] {
7459	[[unlikely]] b++; // No contradiction since the second attribute
7460	} // is ignored.
7461
7462	if (b)
7463	;
7464	else [[likely]] {
7465	// The compiler will optimize to execute the code here.
7466	}
7467
7468	if (b)
7469	;
7470	else
7471	// The compiler will optimize to execute the next statement.
7472	[[likely]] b = f();
7473
7474	if (b) [[likely]]; // Both branches are likely. A diagnostic is issued
7475	else [[likely]]; // and the attributes are ignored.
7476
7477	if (b)
7478	[[likely]] int i = 5; // Issues a diagnostic since the attribute
7479	// isn't allowed on a declaration.
7480
7481	switch (i) {
7482	[[likely]] case 1: // This value is likely
7483	...
7484	break;
7485
7486	[[unlikely]] case 2: // This value is unlikely
7487	...
7488	[[fallthrough]];
7489
7490	case 3: // No likelihood attribute
7491	...
7492	[[likely]] break; // No effect
7493
7494	case 4: [[likely]] { // attribute on substatement has no effect
7495	...
7496	break;
7497	}
7498
7499	[[unlikely]] default: // All other values are unlikely
7500	...
7501	break;
7502	}
7503
7504	switch (i) {
7505	[[likely]] case 0: // This value and code path is likely
7506	...
7507	[[fallthrough]];
7508
7509	case 1: // No likelihood attribute, code path is neutral
7510	break; // falling through has no effect on the likelihood
7511
7512	case 2: // No likelihood attribute, code path is neutral
7513	[[fallthrough]];
7514
7515	[[unlikely]] default: // This value and code path are both unlikely
7516	break;
7517	}
7518
7519	for(int i = 0; i != size; ++i) [[likely]] {
7520	... // The loop is the likely path of execution
7521	}
7522
7523	for(const auto &E : Elements) [[likely]] {
7524	... // The loop is the likely path of execution
7525	}
7526
7527	while(i != size) [[unlikely]] {
7528	... // The loop is the unlikely path of execution
7529	} // The generated code will optimize to skip the loop body
7530
7531	while(true) [[unlikely]] {
7532	... // The attribute has no effect
7533	} // Clang elides the comparison and generates an infinite
7534	// loop)reST";
7535
7536	static const char AttrDoc_UnsafeBufferUsage[] = R"reST(The attribute ``[[clang::unsafe_buffer_usage]]`` should be placed on functions
7537	that need to be avoided as they are prone to buffer overflows. It is designed to
7538	work together with the off-by-default compiler warning ``-Wunsafe-buffer-usage``
7539	to help codebases transition away from raw pointer based buffer management,
7540	in favor of safer abstractions such as C++20 ``std::span``. The attribute causes
7541	``-Wunsafe-buffer-usage`` to warn on every use of the function, and it may
7542	enable ``-Wunsafe-buffer-usage`` to emit automatic fix-it hints
7543	which would help the user replace such unsafe functions with safe
7544	alternatives, though the attribute can be used even when the fix can't be automated.
7545
7546	The attribute does not suppress ``-Wunsafe-buffer-usage`` inside the function
7547	to which it is attached. These warnings still need to be addressed.
7548
7549	The attribute is warranted even if the only way a function can overflow
7550	the buffer is by violating the function's preconditions. For example, it
7551	would make sense to put the attribute on function ``foo()`` below because
7552	passing an incorrect size parameter would cause a buffer overflow:
7553
7554	.. code-block:: c++
7555
7556	[[clang::unsafe_buffer_usage]]
7557	void foo(int *buf, size_t size) {
7558	for (size_t i = 0; i < size; ++i) {
7559	buf[i] = i;
7560	}
7561	}
7562
7563	The attribute is NOT warranted when the function uses safe abstractions,
7564	assuming that these abstractions weren't misused outside the function.
7565	For example, function ``bar()`` below doesn't need the attribute,
7566	because assuming that the container ``buf`` is well-formed (has size that
7567	fits the original buffer it refers to), overflow cannot occur:
7568
7569	.. code-block:: c++
7570
7571	void bar(std::span<int> buf) {
7572	for (size_t i = 0; i < buf.size(); ++i) {
7573	buf[i] = i;
7574	}
7575	}
7576
7577	In this case function ``bar()`` enables the user to keep the buffer
7578	"containerized" in a span for as long as possible. On the other hand,
7579	Function ``foo()`` in the previous example may have internal
7580	consistency, but by accepting a raw buffer it requires the user to unwrap
7581	their span, which is undesirable according to the programming model
7582	behind ``-Wunsafe-buffer-usage``.
7583
7584	The attribute is warranted when a function accepts a raw buffer only to
7585	immediately put it into a span:
7586
7587	.. code-block:: c++
7588
7589	[[clang::unsafe_buffer_usage]]
7590	void baz(int *buf, size_t size) {
7591	std::span<int> sp{ buf, size };
7592	for (size_t i = 0; i < sp.size(); ++i) {
7593	sp[i] = i;
7594	}
7595	}
7596
7597	In this case ``baz()`` does not contain any unsafe operations, but the awkward
7598	parameter type causes the caller to unwrap the span unnecessarily.
7599	Note that regardless of the attribute, code inside ``baz()`` isn't flagged
7600	by ``-Wunsafe-buffer-usage`` as unsafe. It is definitely undesirable,
7601	but if ``baz()`` is on an API surface, there is no way to improve it
7602	to make it as safe as ``bar()`` without breaking the source and binary
7603	compatibility with existing users of the function. In such cases
7604	the proper solution would be to create a different function (possibly
7605	an overload of ``baz()``) that accepts a safe container like ``bar()``,
7606	and then use the attribute on the original ``baz()`` to help the users
7607	update their code to use the new function.)reST";
7608
7609	static const char AttrDoc_Unused[] = R"reST(When passing the ``-Wunused`` flag to Clang, entities that are unused by the
7610	program may be diagnosed. The ``[[maybe_unused]]`` (or
7611	``__attribute__((unused))``) attribute can be used to silence such diagnostics
7612	when the entity cannot be removed. For instance, a local variable may exist
7613	solely for use in an ``assert()`` statement, which makes the local variable
7614	unused when ``NDEBUG`` is defined.
7615
7616	The attribute may be applied to the declaration of a class, a typedef, a
7617	variable, a function or method, a function parameter, an enumeration, an
7618	enumerator, a non-static data member, or a label.
7619
7620	.. code-block:: c++
7621
7622	#include <cassert>
7623
7624	[[maybe_unused]] void f([[maybe_unused]] bool thing1,
7625	[[maybe_unused]] bool thing2) {
7626	[[maybe_unused]] bool b = thing1 && thing2;
7627	assert(b);
7628	})reST";
7629
7630	static const char AttrDoc_UseHandle[] = R"reST(A function taking a handle by value might close the handle. If a function
7631	parameter is annotated with ``use_handle(tag)`` it is assumed to not to change
7632	the state of the handle. It is also assumed to require an open handle to work with.
7633	The attribute requires a string literal argument to identify the handle being used.
7634
7635	.. code-block:: c++
7636
7637	zx_status_t zx_port_wait(zx_handle_t handle [[clang::use_handle("zircon")]],
7638	zx_time_t deadline,
7639	zx_port_packet_t* packet);)reST";
7640
7641	static const char AttrDoc_Used[] = R"reST(This attribute, when attached to a function or variable definition, indicates
7642	that there may be references to the entity which are not apparent in the source
7643	code. For example, it may be referenced from inline ``asm``, or it may be
7644	found through a dynamic symbol or section lookup.
7645
7646	The compiler must emit the definition even if it appears to be unused, and it
7647	must not apply optimizations which depend on fully understanding how the entity
7648	is used.
7649
7650	Whether this attribute has any effect on the linker depends on the target and
7651	the linker. Most linkers support the feature of section garbage collection
7652	(``--gc-sections``), also known as "dead stripping" (``ld64 -dead_strip``) or
7653	discarding unreferenced sections (``link.exe /OPT:REF``). On COFF and Mach-O
7654	targets (Windows and Apple platforms), the `used` attribute prevents symbols
7655	from being removed by linker section GC. On ELF targets, it has no effect on its
7656	own, and the linker may remove the definition if it is not otherwise referenced.
7657	This linker GC can be avoided by also adding the ``retain`` attribute. Note
7658	that ``retain`` requires special support from the linker; see that attribute's
7659	documentation for further information.)reST";
7660
7661	static const char AttrDoc_UsingIfExists[] = R"reST(The ``using_if_exists`` attribute applies to a using-declaration. It allows
7662	programmers to import a declaration that potentially does not exist, instead
7663	deferring any errors to the point of use. For instance:
7664
7665	.. code-block:: c++
7666
7667	namespace empty_namespace {};
7668	__attribute__((using_if_exists))
7669	using empty_namespace::does_not_exist; // no error!
7670
7671	does_not_exist x; // error: use of unresolved 'using_if_exists'
7672
7673	The C++ spelling of the attribute (`[[clang::using_if_exists]]`) is also
7674	supported as a clang extension, since ISO C++ doesn't support attributes in this
7675	position. If the entity referred to by the using-declaration is found by name
7676	lookup, the attribute has no effect. This attribute is useful for libraries
7677	(primarily, libc++) that wish to redeclare a set of declarations in another
7678	namespace, when the availability of those declarations is difficult or
7679	impossible to detect at compile time with the preprocessor.)reST";
7680
7681	static const char AttrDoc_Uuid[] = R"reST(No documentation.)reST";
7682
7683	static const char AttrDoc_VTablePointerAuthentication[] = R"reST(No documentation.)reST";
7684
7685	static const char AttrDoc_VecReturn[] = R"reST(No documentation.)reST";
7686
7687	static const char AttrDoc_VecTypeHint[] = R"reST(No documentation.)reST";
7688
7689	static const char AttrDoc_VectorCall[] = R"reST(On 32-bit x86 and x86_64 targets, this attribute changes the calling
7690	convention of a function to pass vector parameters in SSE registers.
7691
7692	On 32-bit x86 targets, this calling convention is similar to ``__fastcall``.
7693	The first two integer parameters are passed in ECX and EDX. Subsequent integer
7694	parameters are passed in memory, and callee clears the stack. On x86_64
7695	targets, the callee does not clear the stack, and integer parameters are
7696	passed in RCX, RDX, R8, and R9 as is done for the default Windows x64 calling
7697	convention.
7698
7699	On both 32-bit x86 and x86_64 targets, vector and floating point arguments are
7700	passed in XMM0-XMM5. Homogeneous vector aggregates of up to four elements are
7701	passed in sequential SSE registers if enough are available. If AVX is enabled,
7702	256 bit vectors are passed in YMM0-YMM5. Any vector or aggregate type that
7703	cannot be passed in registers for any reason is passed by reference, which
7704	allows the caller to align the parameter memory.
7705
7706	See the documentation for `__vectorcall`_ on MSDN for more details.
7707
7708	.. _`__vectorcall`: http://msdn.microsoft.com/en-us/library/dn375768.aspx)reST";
7709
7710	static const char AttrDoc_Visibility[] = R"reST(No documentation.)reST";
7711
7712	static const char AttrDoc_WarnUnused[] = R"reST(No documentation.)reST";
7713
7714	static const char AttrDoc_WarnUnusedResult[] = R"reST(Clang supports the ability to diagnose when the results of a function call
7715	expression are discarded under suspicious circumstances. A diagnostic is
7716	generated when a function or its return type is marked with ``[[nodiscard]]``
7717	(or ``__attribute__((warn_unused_result))``) and the function call appears as a
7718	potentially-evaluated discarded-value expression that is not explicitly cast to
7719	``void``.
7720
7721	A string literal may optionally be provided to the attribute, which will be
7722	reproduced in any resulting diagnostics. Redeclarations using different forms
7723	of the attribute (with or without the string literal or with different string
7724	literal contents) are allowed. If there are redeclarations of the entity with
7725	differing string literals, it is unspecified which one will be used by Clang
7726	in any resulting diagnostics.
7727
7728	.. code-block:: c++
7729
7730	struct [[nodiscard]] error_info { /.../ };
7731	error_info enable_missile_safety_mode();
7732
7733	void launch_missiles();
7734	void test_missiles() {
7735	enable_missile_safety_mode(); // diagnoses
7736	launch_missiles();
7737	}
7738	error_info &foo();
7739	void f() { foo(); } // Does not diagnose, error_info is a reference.
7740
7741	Additionally, discarded temporaries resulting from a call to a constructor
7742	marked with ``[[nodiscard]]`` or a constructor of a type marked
7743	``[[nodiscard]]`` will also diagnose. This also applies to type conversions that
7744	use the annotated ``[[nodiscard]]`` constructor or result in an annotated type.
7745
7746	.. code-block:: c++
7747
7748	struct [[nodiscard]] marked_type {/../ };
7749	struct marked_ctor {
7750	[[nodiscard]] marked_ctor();
7751	marked_ctor(int);
7752	};
7753
7754	struct S {
7755	operator marked_type() const;
7756	[[nodiscard]] operator int() const;
7757	};
7758
7759	void usages() {
7760	marked_type(); // diagnoses.
7761	marked_ctor(); // diagnoses.
7762	marked_ctor(3); // Does not diagnose, int constructor isn't marked nodiscard.
7763
7764	S s;
7765	static_cast<marked_type>(s); // diagnoses
7766	(int)s; // diagnoses
7767	})reST";
7768
7769	static const char AttrDoc_Weak[] = R"reST(In supported output formats the ``weak`` attribute can be used to
7770	specify that a variable or function should be emitted as a symbol with
7771	``weak`` (if a definition) or ``extern_weak`` (if a declaration of an
7772	external symbol) `linkage
7773	<https://llvm.org/docs/LangRef.html#linkage-types>`_.
7774
7775	If there is a non-weak definition of the symbol the linker will select
7776	that over the weak. They must have same type and alignment (variables
7777	must also have the same size), but may have a different value.
7778
7779	If there are multiple weak definitions of same symbol, but no non-weak
7780	definition, they should have same type, size, alignment and value, the
7781	linker will select one of them (see also selectany_ attribute).
7782
7783	If the ``weak`` attribute is applied to a ``const`` qualified variable
7784	definition that variable is no longer consider a compiletime constant
7785	as its value can change during linking (or dynamic linking). This
7786	means that it can e.g no longer be part of an initializer expression.
7787
7788	.. code-block:: c
7789
7790	const int ANSWER __attribute__ ((weak)) = 42;
7791
7792	/* This function may be replaced link-time */
7793	__attribute__ ((weak)) void debug_log(const char *msg)
7794	{
7795	fprintf(stderr, "DEBUG: %s\n", msg);
7796	}
7797
7798	int main(int argc, const char **argv)
7799	{
7800	debug_log ("Starting up...");
7801
7802	/* This may print something else than "6 * 7 = 42",
7803	if there is a non-weak definition of "ANSWER" in
7804	an object linked in */
7805	printf("6 * 7 = %d\n", ANSWER);
7806
7807	return 0;
7808	}
7809
7810	If an external declaration is marked weak and that symbol does not
7811	exist during linking (possibly dynamic) the address of the symbol will
7812	evaluate to NULL.
7813
7814	.. code-block:: c
7815
7816	void may_not_exist(void) __attribute__ ((weak));
7817
7818	int main(int argc, const char **argv)
7819	{
7820	if (may_not_exist) {
7821	may_not_exist();
7822	} else {
7823	printf("Function did not exist\n");
7824	}
7825	return 0;
7826	})reST";
7827
7828	static const char AttrDoc_WeakImport[] = R"reST(No documentation.)reST";
7829
7830	static const char AttrDoc_WeakRef[] = R"reST(No documentation.)reST";
7831
7832	static const char AttrDoc_WebAssemblyExportName[] = R"reST(Clang supports the ``__attribute__((export_name(<name>)))``
7833	attribute for the WebAssembly target. This attribute may be attached to a
7834	function declaration, where it modifies how the symbol is to be exported
7835	from the linked WebAssembly.
7836
7837	WebAssembly functions are exported via string name. By default when a symbol
7838	is exported, the export name for C/C++ symbols are the same as their C/C++
7839	symbol names. This attribute can be used to override the default behavior, and
7840	request a specific string name be used instead.)reST";
7841
7842	static const char AttrDoc_WebAssemblyFuncref[] = R"reST(Clang supports the ``__attribute__((export_name(<name>)))``
7843	attribute for the WebAssembly target. This attribute may be attached to a
7844	function declaration, where it modifies how the symbol is to be exported
7845	from the linked WebAssembly.
7846
7847	WebAssembly functions are exported via string name. By default when a symbol
7848	is exported, the export name for C/C++ symbols are the same as their C/C++
7849	symbol names. This attribute can be used to override the default behavior, and
7850	request a specific string name be used instead.)reST";
7851
7852	static const char AttrDoc_WebAssemblyImportModule[] = R"reST(Clang supports the ``__attribute__((import_module(<module_name>)))``
7853	attribute for the WebAssembly target. This attribute may be attached to a
7854	function declaration, where it modifies how the symbol is to be imported
7855	within the WebAssembly linking environment.
7856
7857	WebAssembly imports use a two-level namespace scheme, consisting of a module
7858	name, which typically identifies a module from which to import, and a field
7859	name, which typically identifies a field from that module to import. By
7860	default, module names for C/C++ symbols are assigned automatically by the
7861	linker. This attribute can be used to override the default behavior, and
7862	request a specific module name be used instead.)reST";
7863
7864	static const char AttrDoc_WebAssemblyImportName[] = R"reST(Clang supports the ``__attribute__((import_name(<name>)))``
7865	attribute for the WebAssembly target. This attribute may be attached to a
7866	function declaration, where it modifies how the symbol is to be imported
7867	within the WebAssembly linking environment.
7868
7869	WebAssembly imports use a two-level namespace scheme, consisting of a module
7870	name, which typically identifies a module from which to import, and a field
7871	name, which typically identifies a field from that module to import. By
7872	default, field names for C/C++ symbols are the same as their C/C++ symbol
7873	names. This attribute can be used to override the default behavior, and
7874	request a specific field name be used instead.)reST";
7875
7876	static const char AttrDoc_WorkGroupSizeHint[] = R"reST(No documentation.)reST";
7877
7878	static const char AttrDoc_X86ForceAlignArgPointer[] = R"reST(Use this attribute to force stack alignment.
7879
7880	Legacy x86 code uses 4-byte stack alignment. Newer aligned SSE instructions
7881	(like 'movaps') that work with the stack require operands to be 16-byte aligned.
7882	This attribute realigns the stack in the function prologue to make sure the
7883	stack can be used with SSE instructions.
7884
7885	Note that the x86_64 ABI forces 16-byte stack alignment at the call site.
7886	Because of this, 'force_align_arg_pointer' is not needed on x86_64, except in
7887	rare cases where the caller does not align the stack properly (e.g. flow
7888	jumps from i386 arch code).
7889
7890	.. code-block:: c
7891
7892	__attribute__ ((force_align_arg_pointer))
7893	void f () {
7894	...
7895	})reST";
7896
7897	static const char AttrDoc_XRayInstrument[] = R"reST(``__attribute__((xray_always_instrument))`` or
7898	``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++),
7899	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
7900	instrumented with XRay. This will cause the function to always have space at
7901	the beginning and exit points to allow for runtime patching.
7902
7903	Conversely, ``__attribute__((xray_never_instrument))`` or
7904	``[[clang::xray_never_instrument]]`` will inhibit the insertion of these
7905	instrumentation points.
7906
7907	If a function has neither of these attributes, they become subject to the XRay
7908	heuristics used to determine whether a function should be instrumented or
7909	otherwise.
7910
7911	``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is
7912	used to preserve N function arguments for the logging function. Currently,
7913	only N==1 is supported.)reST";
7914
7915	static const char AttrDoc_XRayLogArgs[] = R"reST(``__attribute__((xray_always_instrument))`` or
7916	``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++),
7917	methods (in Objective C), and free functions (in C, C++, and Objective C) to be
7918	instrumented with XRay. This will cause the function to always have space at
7919	the beginning and exit points to allow for runtime patching.
7920
7921	Conversely, ``__attribute__((xray_never_instrument))`` or
7922	``[[clang::xray_never_instrument]]`` will inhibit the insertion of these
7923	instrumentation points.
7924
7925	If a function has neither of these attributes, they become subject to the XRay
7926	heuristics used to determine whether a function should be instrumented or
7927	otherwise.
7928
7929	``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is
7930	used to preserve N function arguments for the logging function. Currently,
7931	only N==1 is supported.)reST";
7932
7933	static const char AttrDoc_ZeroCallUsedRegs[] = R"reST(This attribute, when attached to a function, causes the compiler to zero a
7934	subset of all call-used registers before the function returns. It's used to
7935	increase program security by either mitigating `Return-Oriented Programming`_
7936	(ROP) attacks or preventing information leakage through registers.
7937
7938	The term "call-used" means registers which are not guaranteed to be preserved
7939	unchanged for the caller by the current calling convention. This could also be
7940	described as "caller-saved" or "not callee-saved".
7941
7942	The `choice` parameters gives the programmer flexibility to choose the subset
7943	of the call-used registers to be zeroed:
7944
7945	- ``skip`` doesn't zero any call-used registers. This choice overrides any
7946	command-line arguments.
7947	- ``used`` only zeros call-used registers used in the function. By ``used``, we
7948	mean a register whose contents have been set or referenced in the function.
7949	- ``used-gpr`` only zeros call-used GPR registers used in the function.
7950	- ``used-arg`` only zeros call-used registers used to pass arguments to the
7951	function.
7952	- ``used-gpr-arg`` only zeros call-used GPR registers used to pass arguments to
7953	the function.
7954	- ``all`` zeros all call-used registers.
7955	- ``all-gpr`` zeros all call-used GPR registers.
7956	- ``all-arg`` zeros all call-used registers used to pass arguments to the
7957	function.
7958	- ``all-gpr-arg`` zeros all call-used GPR registers used to pass arguments to
7959	the function.
7960
7961	The default for the attribute is controlled by the ``-fzero-call-used-regs``
7962	flag.
7963
7964	.. _Return-Oriented Programming: https://en.wikipedia.org/wiki/Return-oriented_programming)reST";
7965

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