..\r
-------------------------------------------------------------------\r
- NOTE: This file is a placeholder that gets replaced by running\r
- clang-tblgen -gen-attr-docs. You should not edit this file by\r
- hand, nor should you commit changes to this file.\r
- -------------------------------------------------------------------
\ No newline at end of file
+ NOTE: This file is automatically generated by running clang-tblgen\r
+ -gen-attr-docs. Do not edit this file by hand!!\r
+ -------------------------------------------------------------------\r
+\r
+===================\r
+Attributes in Clang\r
+===================\r
+.. contents::\r
+ :local:\r
+\r
+Introduction\r
+============\r
+\r
+This page lists the attributes currently supported by Clang.\r
+\r
+Function Attributes\r
+===================\r
+\r
+\r
+interrupt\r
+---------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Clang supports the GNU style ``__attribute__((interrupt("TYPE")))`` attribute on\r
+ARM targets. This attribute may be attached to a function definition and\r
+instructs the backend to generate appropriate function entry/exit code so that\r
+it can be used directly as an interrupt service routine.\r
+\r
+The parameter passed to the interrupt attribute is optional, but if\r
+provided it must be a string literal with one of the following values: "IRQ",\r
+"FIQ", "SWI", "ABORT", "UNDEF".\r
+\r
+The semantics are as follows:\r
+\r
+- If the function is AAPCS, Clang instructs the backend to realign the stack to\r
+ 8 bytes on entry. This is a general requirement of the AAPCS at public\r
+ interfaces, but may not hold when an exception is taken. Doing this allows\r
+ other AAPCS functions to be called.\r
+- If the CPU is M-class this is all that needs to be done since the architecture\r
+ itself is designed in such a way that functions obeying the normal AAPCS ABI\r
+ constraints are valid exception handlers.\r
+- If the CPU is not M-class, the prologue and epilogue are modified to save all\r
+ non-banked registers that are used, so that upon return the user-mode state\r
+ will not be corrupted. Note that to avoid unnecessary overhead, only\r
+ general-purpose (integer) registers are saved in this way. If VFP operations\r
+ are needed, that state must be saved manually.\r
+\r
+ Specifically, interrupt kinds other than "FIQ" will save all core registers\r
+ except "lr" and "sp". "FIQ" interrupts will save r0-r7.\r
+- If the CPU is not M-class, the return instruction is changed to one of the\r
+ canonical sequences permitted by the architecture for exception return. Where\r
+ possible the function itself will make the necessary "lr" adjustments so that\r
+ the "preferred return address" is selected.\r
+\r
+ Unfortunately the compiler is unable to make this guarantee for an "UNDEF"\r
+ handler, where the offset from "lr" to the preferred return address depends on\r
+ the execution state of the code which generated the exception. In this case\r
+ a sequence equivalent to "movs pc, lr" will be used.\r
+\r
+\r
+availability\r
+------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+The ``availability`` attribute can be placed on declarations to describe the\r
+lifecycle of that declaration relative to operating system versions. Consider\r
+the function declaration for a hypothetical function ``f``:\r
+\r
+.. code-block:: c++\r
+\r
+ void f(void) __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7)));\r
+\r
+The availability attribute states that ``f`` was introduced in Mac OS X 10.4,\r
+deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7. This information\r
+is used by Clang to determine when it is safe to use ``f``: for example, if\r
+Clang is instructed to compile code for Mac OS X 10.5, a call to ``f()``\r
+succeeds. If Clang is instructed to compile code for Mac OS X 10.6, the call\r
+succeeds but Clang emits a warning specifying that the function is deprecated.\r
+Finally, if Clang is instructed to compile code for Mac OS X 10.7, the call\r
+fails because ``f()`` is no longer available.\r
+\r
+The availability attribute is a comma-separated list starting with the\r
+platform name and then including clauses specifying important milestones in the\r
+declaration's lifetime (in any order) along with additional information. Those\r
+clauses can be:\r
+\r
+introduced=\ *version*\r
+ The first version in which this declaration was introduced.\r
+\r
+deprecated=\ *version*\r
+ The first version in which this declaration was deprecated, meaning that\r
+ users should migrate away from this API.\r
+\r
+obsoleted=\ *version*\r
+ The first version in which this declaration was obsoleted, meaning that it\r
+ was removed completely and can no longer be used.\r
+\r
+unavailable\r
+ This declaration is never available on this platform.\r
+\r
+message=\ *string-literal*\r
+ Additional message text that Clang will provide when emitting a warning or\r
+ error about use of a deprecated or obsoleted declaration. Useful to direct\r
+ users to replacement APIs.\r
+\r
+Multiple availability attributes can be placed on a declaration, which may\r
+correspond to different platforms. Only the availability attribute with the\r
+platform corresponding to the target platform will be used; any others will be\r
+ignored. If no availability attribute specifies availability for the current\r
+target platform, the availability attributes are ignored. Supported platforms\r
+are:\r
+\r
+``ios``\r
+ Apple's iOS operating system. The minimum deployment target is specified by\r
+ the ``-mios-version-min=*version*`` or ``-miphoneos-version-min=*version*``\r
+ command-line arguments.\r
+\r
+``macosx``\r
+ Apple's Mac OS X operating system. The minimum deployment target is\r
+ specified by the ``-mmacosx-version-min=*version*`` command-line argument.\r
+\r
+A declaration can be used even when deploying back to a platform version prior\r
+to when the declaration was introduced. When this happens, the declaration is\r
+`weakly linked\r
+<https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,\r
+as if the ``weak_import`` attribute were added to the declaration. A\r
+weakly-linked declaration may or may not be present a run-time, and a program\r
+can determine whether the declaration is present by checking whether the\r
+address of that declaration is non-NULL.\r
+\r
+If there are multiple declarations of the same entity, the availability\r
+attributes must either match on a per-platform basis or later\r
+declarations must not have availability attributes for that\r
+platform. For example:\r
+\r
+.. code-block:: c\r
+\r
+ void g(void) __attribute__((availability(macosx,introduced=10.4)));\r
+ void g(void) __attribute__((availability(macosx,introduced=10.4))); // okay, matches\r
+ void g(void) __attribute__((availability(ios,introduced=4.0))); // okay, adds a new platform\r
+ void g(void); // okay, inherits both macosx and ios availability from above.\r
+ void g(void) __attribute__((availability(macosx,introduced=10.5))); // error: mismatch\r
+\r
+When one method overrides another, the overriding method can be more widely available than the overridden method, e.g.,:\r
+\r
+.. code-block:: objc\r
+\r
+ @interface A\r
+ - (id)method __attribute__((availability(macosx,introduced=10.4)));\r
+ - (id)method2 __attribute__((availability(macosx,introduced=10.4)));\r
+ @end\r
+\r
+ @interface B : A\r
+ - (id)method __attribute__((availability(macosx,introduced=10.3))); // okay: method moved into base class later\r
+ - (id)method __attribute__((availability(macosx,introduced=10.5))); // error: this method was available via the base class in 10.4\r
+ @end\r
+\r
+\r
+_Noreturn\r
+---------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "","","","X"\r
+\r
+A function declared as ``_Noreturn`` shall not return to its caller. The\r
+compiler will generate a diagnostic for a function declared as ``_Noreturn``\r
+that appears to be capable of returning to its caller.\r
+\r
+\r
+noreturn\r
+--------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "","X","",""\r
+\r
+A function declared as ``[[noreturn]]`` shall not return to its caller. The\r
+compiler will generate a diagnostic for a function declared as ``[[noreturn]]``\r
+that appears to be capable of returning to its caller.\r
+\r
+\r
+carries_dependency\r
+------------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","X","",""\r
+\r
+The ``carries_dependency`` attribute specifies dependency propagation into and\r
+out of functions.\r
+\r
+When specified on a function or Objective-C method, the ``carries_depedency``\r
+attribute means that the return value carries a dependency out of the function, \r
+so that the implementation need not constrain ordering upon return from that\r
+function. Implementations of the function and its caller may choose to preserve\r
+dependencies instead of emitting memory ordering instructions such as fences.\r
+\r
+Note, this attribute does not change the meaning of the program, but may result\r
+in generatation of more efficient code.\r
+\r
+\r
+enable_if\r
+---------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+The ``enable_if`` attribute can be placed on function declarations to control\r
+which overload is selected based on the values of the function's arguments.\r
+When combined with the ``overloadable`` attribute, this feature is also\r
+available in C.\r
+\r
+.. code-block:: c++\r
+\r
+ int isdigit(int c);\r
+ 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")));\r
+ \r
+ void foo(char c) {\r
+ isdigit(c);\r
+ isdigit(10);\r
+ isdigit(-10); // results in a compile-time error.\r
+ }\r
+\r
+The enable_if attribute takes two arguments, the first is an expression written\r
+in terms of the function parameters, the second is a string explaining why this\r
+overload candidate could not be selected to be displayed in diagnostics. The\r
+expression is part of the function signature for the purposes of determining\r
+whether it is a redeclaration (following the rules used when determining\r
+whether a C++ template specialization is ODR-equivalent), but is not part of\r
+the type.\r
+\r
+The enable_if expression is evaluated as if it were the body of a\r
+bool-returning constexpr function declared with the arguments of the function\r
+it is being applied to, then called with the parameters at the callsite. If the\r
+result is false or could not be determined through constant expression\r
+evaluation, then this overload will not be chosen and the provided string may\r
+be used in a diagnostic if the compile fails as a result.\r
+\r
+Because the enable_if expression is an unevaluated context, there are no global\r
+state changes, nor the ability to pass information from the enable_if\r
+expression to the function body. For example, suppose we want calls to\r
+strnlen(strbuf, maxlen) to resolve to strnlen_chk(strbuf, maxlen, size of\r
+strbuf) only if the size of strbuf can be determined:\r
+\r
+.. code-block:: c++\r
+\r
+ __attribute__((always_inline))\r
+ static inline size_t strnlen(const char *s, size_t maxlen)\r
+ __attribute__((overloadable))\r
+ __attribute__((enable_if(__builtin_object_size(s, 0) != -1))),\r
+ "chosen when the buffer size is known but 'maxlen' is not")))\r
+ {\r
+ return strnlen_chk(s, maxlen, __builtin_object_size(s, 0));\r
+ }\r
+\r
+Multiple enable_if attributes may be applied to a single declaration. In this\r
+case, the enable_if expressions are evaluated from left to right in the\r
+following manner. First, the candidates whose enable_if expressions evaluate to\r
+false or cannot be evaluated are discarded. If the remaining candidates do not\r
+share ODR-equivalent enable_if expressions, the overload resolution is\r
+ambiguous. Otherwise, enable_if overload resolution continues with the next\r
+enable_if attribute on the candidates that have not been discarded and have\r
+remaining enable_if attributes. In this way, we pick the most specific\r
+overload out of a number of viable overloads using enable_if.\r
+\r
+.. code-block:: c++\r
+\r
+ void f() __attribute__((enable_if(true, ""))); // #1\r
+ void f() __attribute__((enable_if(true, ""))) __attribute__((enable_if(true, ""))); // #2\r
+ \r
+ void g(int i, int j) __attribute__((enable_if(i, ""))); // #1\r
+ void g(int i, int j) __attribute__((enable_if(j, ""))) __attribute__((enable_if(true))); // #2\r
+\r
+In this example, a call to f() is always resolved to #2, as the first enable_if\r
+expression is ODR-equivalent for both declarations, but #1 does not have another\r
+enable_if expression to continue evaluating, so the next round of evaluation has\r
+only a single candidate. In a call to g(1, 1), the call is ambiguous even though\r
+#2 has more enable_if attributes, because the first enable_if expressions are\r
+not ODR-equivalent.\r
+\r
+Query for this feature with ``__has_attribute(enable_if)``.\r
+\r
+\r
+objc_method_family\r
+------------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Many methods in Objective-C have conventional meanings determined by their\r
+selectors. It is sometimes useful to be able to mark a method as having a\r
+particular conventional meaning despite not having the right selector, or as\r
+not having the conventional meaning that its selector would suggest. For these\r
+use cases, we provide an attribute to specifically describe the "method family"\r
+that a method belongs to.\r
+\r
+**Usage**: ``__attribute__((objc_method_family(X)))``, where ``X`` is one of\r
+``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This\r
+attribute can only be placed at the end of a method declaration:\r
+\r
+.. code-block:: objc\r
+\r
+ - (NSString *)initMyStringValue __attribute__((objc_method_family(none)));\r
+\r
+Users who do not wish to change the conventional meaning of a method, and who\r
+merely want to document its non-standard retain and release semantics, should\r
+use the retaining behavior attributes (``ns_returns_retained``,\r
+``ns_returns_not_retained``, etc).\r
+\r
+Query for this feature with ``__has_attribute(objc_method_family)``.\r
+\r
+\r
+objc_requires_super\r
+-------------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Some Objective-C classes allow a subclass to override a particular method in a\r
+parent class but expect that the overriding method also calls the overridden\r
+method in the parent class. For these cases, we provide an attribute to\r
+designate that a method requires a "call to ``super``" in the overriding\r
+method in the subclass.\r
+\r
+**Usage**: ``__attribute__((objc_requires_super))``. This attribute can only\r
+be placed at the end of a method declaration:\r
+\r
+.. code-block:: objc\r
+\r
+ - (void)foo __attribute__((objc_requires_super));\r
+\r
+This attribute can only be applied the method declarations within a class, and\r
+not a protocol. Currently this attribute does not enforce any placement of\r
+where the call occurs in the overriding method (such as in the case of\r
+``-dealloc`` where the call must appear at the end). It checks only that it\r
+exists.\r
+\r
+Note that on both OS X and iOS that the Foundation framework provides a\r
+convenience macro ``NS_REQUIRES_SUPER`` that provides syntactic sugar for this\r
+attribute:\r
+\r
+.. code-block:: objc\r
+\r
+ - (void)foo NS_REQUIRES_SUPER;\r
+\r
+This macro is conditionally defined depending on the compiler's support for\r
+this attribute. If the compiler does not support the attribute the macro\r
+expands to nothing.\r
+\r
+Operationally, when a method has this annotation the compiler will warn if the\r
+implementation of an override in a subclass does not call super. For example:\r
+\r
+.. code-block:: objc\r
+\r
+ warning: method possibly missing a [super AnnotMeth] call\r
+ - (void) AnnotMeth{};\r
+ ^\r
+\r
+\r
+overloadable\r
+------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Clang provides support for C++ function overloading in C. Function overloading\r
+in C is introduced using the ``overloadable`` attribute. For example, one\r
+might provide several overloaded versions of a ``tgsin`` function that invokes\r
+the appropriate standard function computing the sine of a value with ``float``,\r
+``double``, or ``long double`` precision:\r
+\r
+.. code-block:: c\r
+\r
+ #include <math.h>\r
+ float __attribute__((overloadable)) tgsin(float x) { return sinf(x); }\r
+ double __attribute__((overloadable)) tgsin(double x) { return sin(x); }\r
+ long double __attribute__((overloadable)) tgsin(long double x) { return sinl(x); }\r
+\r
+Given these declarations, one can call ``tgsin`` with a ``float`` value to\r
+receive a ``float`` result, with a ``double`` to receive a ``double`` result,\r
+etc. Function overloading in C follows the rules of C++ function overloading\r
+to pick the best overload given the call arguments, with a few C-specific\r
+semantics:\r
+\r
+* Conversion from ``float`` or ``double`` to ``long double`` is ranked as a\r
+ floating-point promotion (per C99) rather than as a floating-point conversion\r
+ (as in C++).\r
+\r
+* A conversion from a pointer of type ``T*`` to a pointer of type ``U*`` is\r
+ considered a pointer conversion (with conversion rank) if ``T`` and ``U`` are\r
+ compatible types.\r
+\r
+* A conversion from type ``T`` to a value of type ``U`` is permitted if ``T``\r
+ and ``U`` are compatible types. This conversion is given "conversion" rank.\r
+\r
+The declaration of ``overloadable`` functions is restricted to function\r
+declarations and definitions. Most importantly, if any function with a given\r
+name is given the ``overloadable`` attribute, then all function declarations\r
+and definitions with that name (and in that scope) must have the\r
+``overloadable`` attribute. This rule even applies to redeclarations of\r
+functions whose original declaration had the ``overloadable`` attribute, e.g.,\r
+\r
+.. code-block:: c\r
+\r
+ int f(int) __attribute__((overloadable));\r
+ float f(float); // error: declaration of "f" must have the "overloadable" attribute\r
+\r
+ int g(int) __attribute__((overloadable));\r
+ int g(int) { } // error: redeclaration of "g" must also have the "overloadable" attribute\r
+\r
+Functions marked ``overloadable`` must have prototypes. Therefore, the\r
+following code is ill-formed:\r
+\r
+.. code-block:: c\r
+\r
+ int h() __attribute__((overloadable)); // error: h does not have a prototype\r
+\r
+However, ``overloadable`` functions are allowed to use a ellipsis even if there\r
+are no named parameters (as is permitted in C++). This feature is particularly\r
+useful when combined with the ``unavailable`` attribute:\r
+\r
+.. code-block:: c++\r
+\r
+ void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error\r
+\r
+Functions declared with the ``overloadable`` attribute have their names mangled\r
+according to the same rules as C++ function names. For example, the three\r
+``tgsin`` functions in our motivating example get the mangled names\r
+``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two\r
+caveats to this use of name mangling:\r
+\r
+* Future versions of Clang may change the name mangling of functions overloaded\r
+ in C, so you should not depend on an specific mangling. To be completely\r
+ safe, we strongly urge the use of ``static inline`` with ``overloadable``\r
+ functions.\r
+\r
+* The ``overloadable`` attribute has almost no meaning when used in C++,\r
+ because names will already be mangled and functions are already overloadable.\r
+ However, when an ``overloadable`` function occurs within an ``extern "C"``\r
+ linkage specification, it's name *will* be mangled in the same way as it\r
+ would in C.\r
+\r
+Query for this feature with ``__has_extension(attribute_overloadable)``.\r
+\r
+\r
+Variable Attributes\r
+===================\r
+\r
+\r
+tls_model (gnu::tls_model)\r
+--------------------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","X","",""\r
+\r
+The ``tls_model`` attribute allows you to specify which thread-local storage\r
+model to use. It accepts the following strings:\r
+\r
+* global-dynamic\r
+* local-dynamic\r
+* initial-exec\r
+* local-exec\r
+\r
+TLS models are mutually exclusive.\r
+\r
+\r
+Statement Attributes\r
+====================\r
+\r
+\r
+fallthrough (clang::fallthrough)\r
+--------------------------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "","X","",""\r
+\r
+The ``clang::fallthrough`` attribute is used along with the\r
+``-Wimplicit-fallthrough`` argument to annotate intentional fall-through\r
+between switch labels. It can only be applied to a null statement placed at a\r
+point of execution between any statement and the next switch label. It is\r
+common to mark these places with a specific comment, but this attribute is\r
+meant to replace comments with a more strict annotation, which can be checked\r
+by the compiler. This attribute doesn't change semantics of the code and can\r
+be used wherever an intended fall-through occurs. It is designed to mimic\r
+control-flow statements like ``break;``, so it can be placed in most places\r
+where ``break;`` can, but only if there are no statements on the execution path\r
+between it and the next switch label.\r
+\r
+Here is an example:\r
+\r
+.. code-block:: c++\r
+\r
+ // compile with -Wimplicit-fallthrough\r
+ switch (n) {\r
+ case 22:\r
+ case 33: // no warning: no statements between case labels\r
+ f();\r
+ case 44: // warning: unannotated fall-through\r
+ g();\r
+ [[clang::fallthrough]];\r
+ case 55: // no warning\r
+ if (x) {\r
+ h();\r
+ break;\r
+ }\r
+ else {\r
+ i();\r
+ [[clang::fallthrough]];\r
+ }\r
+ case 66: // no warning\r
+ p();\r
+ [[clang::fallthrough]]; // warning: fallthrough annotation does not\r
+ // directly precede case label\r
+ q();\r
+ case 77: // warning: unannotated fall-through\r
+ r();\r
+ }\r
+\r
+\r
+Consumed Annotation Checking\r
+============================\r
+Clang supports additional attributes for checking basic resource management\r
+properties, specifically for unique objects that have a single owning reference.\r
+The following attributes are currently supported, although **the implementation\r
+for these annotations is currently in development and are subject to change.**\r
+\r
+callable_when\r
+-------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Use ``__attribute__((callable_when(...)))`` to indicate what states a method\r
+may be called in. Valid states are unconsumed, consumed, or unknown. Each\r
+argument to this attribute must be a quoted string. E.g.:\r
+\r
+``__attribute__((callable_when("unconsumed", "unknown")))``\r
+\r
+\r
+consumable\r
+----------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Each ``class`` that uses any of the typestate annotations must first be marked\r
+using the ``consumable`` attribute. Failure to do so will result in a warning.\r
+\r
+This attribute accepts a single parameter that must be one of the following:\r
+``unknown``, ``consumed``, or ``unconsumed``.\r
+\r
+\r
+param_typestate\r
+---------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+This attribute specifies expectations about function parameters. Calls to an\r
+function with annotated parameters will issue a warning if the corresponding\r
+argument isn't in the expected state. The attribute is also used to set the\r
+initial state of the parameter when analyzing the function's body.\r
+\r
+\r
+return_typestate\r
+----------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+The ``return_typestate`` attribute can be applied to functions or parameters.\r
+When applied to a function the attribute specifies the state of the returned\r
+value. The function's body is checked to ensure that it always returns a value\r
+in the specified state. On the caller side, values returned by the annotated\r
+function are initialized to the given state.\r
+\r
+When applied to a function parameter it modifies the state of an argument after\r
+a call to the function returns. The function's body is checked to ensure that\r
+the parameter is in the expected state before returning.\r
+\r
+\r
+set_typestate\r
+-------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Annotate methods that transition an object into a new state with\r
+``__attribute__((set_typestate(new_state)))``. The new new state must be\r
+unconsumed, consumed, or unknown.\r
+\r
+\r
+test_typestate\r
+--------------\r
+.. csv-table:: Supported Syntaxes\r
+ :header: "GNU", "C++11", "__declspec", "Keyword"\r
+\r
+ "X","","",""\r
+\r
+Use ``__attribute__((test_typestate(tested_state)))`` to indicate that a method\r
+returns true if the object is in the specified state..\r
+\r
+\r
projects / clang / commitdiff