[clang] a51d51a - Fix some of the more egregious 80-col and whitespace issues; NFC
Aaron Ballman via cfe-commits
cfe-commits at lists.llvm.org
Fri Sep 25 07:37:58 PDT 2020
Author: Aaron Ballman
Date: 2020-09-25T10:37:38-04:00
New Revision: a51d51a0d4d72ab423b11da4c5c877bc6e89a580
URL: https://github.com/llvm/llvm-project/commit/a51d51a0d4d72ab423b11da4c5c877bc6e89a580
DIFF: https://github.com/llvm/llvm-project/commit/a51d51a0d4d72ab423b11da4c5c877bc6e89a580.diff
LOG: Fix some of the more egregious 80-col and whitespace issues; NFC
Added:
Modified:
clang/include/clang/Basic/AttrDocs.td
Removed:
################################################################################
diff --git a/clang/include/clang/Basic/AttrDocs.td b/clang/include/clang/Basic/AttrDocs.td
index d6c3ce50f1b1..9c16fecfeaa8 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -87,12 +87,12 @@ def InitSegDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
The attribute applied by ``pragma init_seg()`` controls the section into
-which global initialization function pointers are emitted. It is only
-available with ``-fms-extensions``. Typically, this function pointer is
-emitted into ``.CRT$XCU`` on Windows. The user can change the order of
+which global initialization function pointers are emitted. It is only
+available with ``-fms-extensions``. Typically, this function pointer is
+emitted into ``.CRT$XCU`` on Windows. The user can change the order of
initialization by using a
diff erent section name with the same
``.CRT$XC`` prefix and a suffix that sorts lexicographically before or
-after the standard ``.CRT$XCU`` sections. See the init_seg_
+after the standard ``.CRT$XCU`` sections. See the init_seg_
documentation on MSDN for more information.
.. _init_seg: http://msdn.microsoft.com/en-us/library/7977wcck(v=vs.110).aspx
@@ -118,10 +118,10 @@ def DLLExportDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
The ``__declspec(dllexport)`` attribute declares a variable, function, or
-Objective-C interface to be exported from the module. It is available under the
-``-fdeclspec`` flag for compatibility with various compilers. The primary use
+Objective-C interface to be exported from the module. It is available under the
+``-fdeclspec`` flag for compatibility with various compilers. The primary use
is for COFF object files which explicitly specify what interfaces are available
-for external use. See the dllexport_ documentation on MSDN for more
+for external use. See the dllexport_ documentation on MSDN for more
information.
.. _dllexport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx
@@ -132,10 +132,10 @@ def DLLImportDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
The ``__declspec(dllimport)`` attribute declares a variable, function, or
-Objective-C interface to be imported from an external module. It is available
-under the ``-fdeclspec`` flag for compatibility with various compilers. The
+Objective-C interface to be imported from an external module. It is available
+under the ``-fdeclspec`` flag for compatibility with various compilers. The
primary use is for COFF object files which explicitly specify what interfaces
-are imported from external modules. See the dllimport_ documentation on MSDN
+are imported from external modules. See the dllimport_ documentation on MSDN
for more information.
.. _dllimport: https://msdn.microsoft.com/en-us/library/3y1sfaz2.aspx
@@ -146,14 +146,14 @@ def ThreadDocs : Documentation {
let Category = DocCatVariable;
let Content = [{
The ``__declspec(thread)`` attribute declares a variable with thread local
-storage. It is available under the ``-fms-extensions`` flag for MSVC
-compatibility. See the documentation for `__declspec(thread)`_ on MSDN.
+storage. It is available under the ``-fms-extensions`` flag for MSVC
+compatibility. See the documentation for `__declspec(thread)`_ on MSDN.
.. _`__declspec(thread)`: http://msdn.microsoft.com/en-us/library/9w1sdazb.aspx
In Clang, ``__declspec(thread)`` is generally equivalent in functionality to the
-GNU ``__thread`` keyword. The variable must not have a destructor and must have
-a constant initializer, if any. The attribute only applies to variables
+GNU ``__thread`` keyword. The variable must not have a destructor and must have
+a constant initializer, if any. The attribute only applies to variables
declared with static storage duration, such as globals, class static data
members, and static locals.
}];
@@ -305,7 +305,7 @@ outlining job:
A C++ function object passed to the ``parallel_for`` is called a "SYCL kernel".
A SYCL kernel defines the entry point to the "device part" of the code. The
compiler will emit all symbols accessible from a "kernel". In this code
-example, the compiler will emit "foo" function. More details about the
+example, the compiler will emit "foo" function. More details about the
compilation of functions for the device part can be found in the SYCL 1.2.1
specification Section 6.4.
To show to the compiler entry point to the "device part" of the code, the SYCL
@@ -524,7 +524,7 @@ parameter.
Note that this attribute merely informs the compiler that a function always
returns a sufficiently aligned pointer. It does not cause the compiler to
-emit code to enforce that alignment. The behavior is undefined if the returned
+emit code to enforce that alignment. The behavior is undefined if the returned
pointer is not sufficiently aligned.
}];
}
@@ -833,8 +833,8 @@ read more about ``__builtin_dynamic_object_size`` `here
def OverloadableDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
-Clang provides support for C++ function overloading in C. Function overloading
-in C is introduced using the ``overloadable`` attribute. For example, one
+Clang provides support for C++ function overloading in C. Function overloading
+in C is introduced using the ``overloadable`` attribute. For example, one
might provide several overloaded versions of a ``tgsin`` function that invokes
the appropriate standard function computing the sine of a value with ``float``,
``double``, or ``long double`` precision:
@@ -848,7 +848,7 @@ the appropriate standard function computing the sine of a value with ``float``,
Given these declarations, one can call ``tgsin`` with a ``float`` value to
receive a ``float`` result, with a ``double`` to receive a ``double`` result,
-etc. Function overloading in C follows the rules of C++ function overloading
+etc. Function overloading in C follows the rules of C++ function overloading
to pick the best overload given the call arguments, with a few C-specific
semantics:
@@ -861,7 +861,7 @@ semantics:
compatible types.
* A conversion from type ``T`` to a value of type ``U`` is permitted if ``T``
- and ``U`` are compatible types. This conversion is given "conversion" rank.
+ and ``U`` are compatible types. This conversion is given "conversion" rank.
* If no viable candidates are otherwise available, we allow a conversion from a
pointer of type ``T*`` to a pointer of type ``U*``, where ``T`` and ``U`` are
@@ -870,10 +870,10 @@ semantics:
for ``T`` and ``U`` to be incompatible.
The declaration of ``overloadable`` functions is restricted to function
-declarations and definitions. If a function is marked with the ``overloadable``
+declarations and definitions. If a function is marked with the ``overloadable``
attribute, then all declarations and definitions of functions with that name,
except for at most one (see the note below about unmarked overloads), must have
-the ``overloadable`` attribute. In addition, redeclarations of a function with
+the ``overloadable`` attribute. In addition, redeclarations of a function with
the ``overloadable`` attribute must have the ``overloadable`` attribute, and
redeclarations of a function without the ``overloadable`` attribute must *not*
have the ``overloadable`` attribute. e.g.,
@@ -891,7 +891,7 @@ have the ``overloadable`` attribute. e.g.,
int h(int) __attribute__((overloadable)); // error: declaration of "h" must not
// have the "overloadable" attribute
-Functions marked ``overloadable`` must have prototypes. Therefore, the
+Functions marked ``overloadable`` must have prototypes. Therefore, the
following code is ill-formed:
.. code-block:: c
@@ -899,7 +899,7 @@ following code is ill-formed:
int h() __attribute__((overloadable)); // error: h does not have a prototype
However, ``overloadable`` functions are allowed to use a ellipsis even if there
-are no named parameters (as is permitted in C++). This feature is particularly
+are no named parameters (as is permitted in C++). This feature is particularly
useful when combined with the ``unavailable`` attribute:
.. code-block:: c++
@@ -907,13 +907,13 @@ useful when combined with the ``unavailable`` attribute:
void honeypot(...) __attribute__((overloadable, unavailable)); // calling me is an error
Functions declared with the ``overloadable`` attribute have their names mangled
-according to the same rules as C++ function names. For example, the three
+according to the same rules as C++ function names. For example, the three
``tgsin`` functions in our motivating example get the mangled names
-``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two
+``_Z5tgsinf``, ``_Z5tgsind``, and ``_Z5tgsine``, respectively. There are two
caveats to this use of name mangling:
* Future versions of Clang may change the name mangling of functions overloaded
- in C, so you should not depend on an specific mangling. To be completely
+ in C, so you should not depend on an specific mangling. To be completely
safe, we strongly urge the use of ``static inline`` with ``overloadable``
functions.
@@ -959,7 +959,7 @@ use cases, we provide an attribute to specifically describe the "method family"
that a method belongs to.
**Usage**: ``__attribute__((objc_method_family(X)))``, where ``X`` is one of
-``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This
+``none``, ``alloc``, ``copy``, ``init``, ``mutableCopy``, or ``new``. This
attribute can only be placed at the end of a method declaration:
.. code-block:: objc
@@ -983,7 +983,7 @@ The behavior of a function with respect to reference counting for Foundation
convention (e.g. functions starting with "get" are assumed to return at
``+0``).
-It can be overridden using a family of the following attributes. In
+It can be overridden using a family of the following attributes. In
Objective-C, the annotation ``__attribute__((ns_returns_retained))`` applied to
a function communicates that the object is returned at ``+1``, and the caller
is responsible for freeing it.
@@ -1164,7 +1164,7 @@ method in the parent class. For these cases, we provide an attribute to
designate that a method requires a "call to ``super``" in the overriding
method in the subclass.
-**Usage**: ``__attribute__((objc_requires_super))``. This attribute can only
+**Usage**: ``__attribute__((objc_requires_super))``. This attribute can only
be placed at the end of a method declaration:
.. code-block:: objc
@@ -1172,9 +1172,9 @@ be placed at the end of a method declaration:
- (void)foo __attribute__((objc_requires_super));
This attribute can only be applied the method declarations within a class, and
-not a protocol. Currently this attribute does not enforce any placement of
+not a protocol. Currently this attribute does not enforce any placement of
where the call occurs in the overriding method (such as in the case of
-``-dealloc`` where the call must appear at the end). It checks only that it
+``-dealloc`` where the call must appear at the end). It checks only that it
exists.
Note that on both OS X and iOS that the Foundation framework provides a
@@ -1186,11 +1186,11 @@ attribute:
- (void)foo NS_REQUIRES_SUPER;
This macro is conditionally defined depending on the compiler's support for
-this attribute. If the compiler does not support the attribute the macro
+this attribute. If the compiler does not support the attribute the macro
expands to nothing.
Operationally, when a method has this annotation the compiler will warn if the
-implementation of an override in a subclass does not call super. For example:
+implementation of an override in a subclass does not call super. For example:
.. code-block:: objc
@@ -1209,7 +1209,7 @@ attribute allows annotated interfaces or protocols to use the
specified string argument in the object's metadata name instead of the
default name.
-**Usage**: ``__attribute__((objc_runtime_name("MyLocalName")))``. This attribute
+**Usage**: ``__attribute__((objc_runtime_name("MyLocalName")))``. This attribute
can only be placed before an @protocol or @interface declaration:
.. code-block:: objc
@@ -1282,7 +1282,7 @@ def AvailabilityDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
The ``availability`` attribute can be placed on declarations to describe the
-lifecycle of that declaration relative to operating system versions. Consider
+lifecycle of that declaration relative to operating system versions. Consider
the function declaration for a hypothetical function ``f``:
.. code-block:: c++
@@ -1290,17 +1290,17 @@ the function declaration for a hypothetical function ``f``:
void f(void) __attribute__((availability(macos,introduced=10.4,deprecated=10.6,obsoleted=10.7)));
The availability attribute states that ``f`` was introduced in macOS 10.4,
-deprecated in macOS 10.6, and obsoleted in macOS 10.7. This information
+deprecated in macOS 10.6, and obsoleted in macOS 10.7. This information
is used by Clang to determine when it is safe to use ``f``: for example, if
Clang is instructed to compile code for macOS 10.5, a call to ``f()``
-succeeds. If Clang is instructed to compile code for macOS 10.6, the call
+succeeds. If Clang is instructed to compile code for macOS 10.6, the call
succeeds but Clang emits a warning specifying that the function is deprecated.
Finally, if Clang is instructed to compile code for macOS 10.7, the call
fails because ``f()`` is no longer available.
The availability attribute is a comma-separated list starting with the
platform name and then including clauses specifying important milestones in the
-declaration's lifetime (in any order) along with additional information. Those
+declaration's lifetime (in any order) along with additional information. Those
clauses can be:
introduced=\ *version*
@@ -1319,7 +1319,7 @@ unavailable
message=\ *string-literal*
Additional message text that Clang will provide when emitting a warning or
- error about use of a deprecated or obsoleted declaration. Useful to direct
+ error about use of a deprecated or obsoleted declaration. Useful to direct
users to replacement APIs.
replacement=\ *string-literal*
@@ -1338,35 +1338,35 @@ specifies availability for the current target platform, the availability
attributes are ignored. Supported platforms are:
``ios``
- Apple's iOS operating system. The minimum deployment target is specified by
+ Apple's iOS operating system. The minimum deployment target is specified by
the ``-mios-version-min=*version*`` or ``-miphoneos-version-min=*version*``
command-line arguments.
``macos``
- Apple's macOS operating system. The minimum deployment target is
+ Apple's macOS operating system. The minimum deployment target is
specified by the ``-mmacosx-version-min=*version*`` command-line argument.
``macosx`` is supported for backward-compatibility reasons, but it is
deprecated.
``tvos``
- Apple's tvOS operating system. The minimum deployment target is specified by
+ Apple's tvOS operating system. The minimum deployment target is specified by
the ``-mtvos-version-min=*version*`` command-line argument.
``watchos``
- Apple's watchOS operating system. The minimum deployment target is specified by
+ Apple's watchOS operating system. The minimum deployment target is specified by
the ``-mwatchos-version-min=*version*`` command-line argument.
A declaration can typically be used even when deploying back to a platform
-version prior to when the declaration was introduced. When this happens, the
+version prior to when the declaration was introduced. When this happens, the
declaration is `weakly linked
<https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html>`_,
-as if the ``weak_import`` attribute were added to the declaration. A
+as if the ``weak_import`` attribute were added to the declaration. A
weakly-linked declaration may or may not be present a run-time, and a program
can determine whether the declaration is present by checking whether the
address of that declaration is non-NULL.
The flag ``strict`` disallows using API when deploying back to a
-platform version prior to when the declaration was introduced. An
+platform version prior to when the declaration was introduced. An
attempt to use such API before its introduction causes a hard error.
Weakly-linking is almost always a better API choice, since it allows
users to query availability at runtime.
@@ -1664,12 +1664,12 @@ def FallthroughDocs : Documentation {
let Content = [{
The ``fallthrough`` (or ``clang::fallthrough``) attribute is used
to annotate intentional fall-through
-between switch labels. It can only be applied to a null statement placed at a
-point of execution between any statement and the next switch label. It is
+between switch labels. It can only be applied to a null statement placed at a
+point of execution between any statement and the next switch label. It is
common to mark these places with a specific comment, but this attribute is
meant to replace comments with a more strict annotation, which can be checked
-by the compiler. This attribute doesn't change semantics of the code and can
-be used wherever an intended fall-through occurs. It is designed to mimic
+by the compiler. This attribute doesn't change semantics of the code and can
+be used wherever an intended fall-through occurs. It is designed to mimic
control-flow statements like ``break;``, so it can be placed in most places
where ``break;`` can, but only if there are no statements on the execution path
between it and the next switch label.
@@ -1922,7 +1922,7 @@ only be added to function declarations and change the code generated
by the compiler when directly calling the function. The ``near`` attribute
allows calls to the function to be made using the ``jal`` instruction, which
requires the function to be located in the same naturally aligned 256MB
-segment as the caller. The ``long_call`` and ``far`` attributes are synonyms
+segment as the caller. The ``long_call`` and ``far`` attributes are synonyms
and require the use of a
diff erent call sequence that works regardless
of the distance between the functions.
@@ -1944,7 +1944,7 @@ and change the code generated by the compiler when directly calling
the function. The ``short_call`` and ``near`` attributes are synonyms and
allow calls to the function to be made using the ``jal`` instruction, which
requires the function to be located in the same naturally aligned 256MB segment
-as the caller. The ``long_call`` and ``far`` attributes are synonyms and
+as the caller. The ``long_call`` and ``far`` attributes are synonyms and
require the use of a
diff erent call sequence that works regardless
of the distance between the functions.
@@ -2035,7 +2035,7 @@ x86/x86-64 targets, which can be used to create multiple implementations of the
same function that will be resolved at runtime based on the priority of their
``target`` attribute strings. A function is considered a multiversioned function
if either two declarations of the function have
diff erent ``target`` attribute
-strings, or if it has a ``target`` attribute string of ``default``. For
+strings, or if it has a ``target`` attribute string of ``default``. For
example:
.. code-block:: c++
@@ -2259,7 +2259,7 @@ On 32-bit x86 targets, this attribute changes the calling convention of a
function to clear parameters off of the stack on return. This convention does
not support variadic calls or unprototyped functions in C, and has no effect on
x86_64 targets. This calling convention is used widely by the Windows API and
-COM applications. See the documentation for `__stdcall`_ on MSDN.
+COM applications. See the documentation for `__stdcall`_ on MSDN.
.. _`__stdcall`: http://msdn.microsoft.com/en-us/library/zxk0tw93.aspx
}];
@@ -2274,7 +2274,7 @@ the stack on return. This convention does not support variadic calls or
unprototyped functions in C, and has no effect on x86_64 targets. This calling
convention is supported primarily for compatibility with existing code. Users
seeking register parameters should use the ``regparm`` attribute, which does
-not require callee-cleanup. See the documentation for `__fastcall`_ on MSDN.
+not require callee-cleanup. See the documentation for `__fastcall`_ on MSDN.
.. _`__fastcall`: http://msdn.microsoft.com/en-us/library/6xa169sk.aspx
}];
@@ -2314,7 +2314,7 @@ convention of a function to pass vector parameters in SSE registers.
On 32-bit x86 targets, this calling convention is similar to ``__fastcall``.
The first two integer parameters are passed in ECX and EDX. Subsequent integer
-parameters are passed in memory, and callee clears the stack. On x86_64
+parameters are passed in memory, and callee clears the stack. On x86_64
targets, the callee does *not* clear the stack, and integer parameters are
passed in RCX, RDX, R8, and R9 as is done for the default Windows x64 calling
convention.
@@ -2345,7 +2345,7 @@ def SetTypestateDocs : Documentation {
let Category = DocCatConsumed;
let Content = [{
Annotate methods that transition an object into a new state with
-``__attribute__((set_typestate(new_state)))``. The new state must be
+``__attribute__((set_typestate(new_state)))``. The new state must be
unconsumed, consumed, or unknown.
}];
}
@@ -2354,8 +2354,8 @@ def CallableWhenDocs : Documentation {
let Category = DocCatConsumed;
let Content = [{
Use ``__attribute__((callable_when(...)))`` to indicate what states a method
-may be called in. Valid states are unconsumed, consumed, or unknown. Each
-argument to this attribute must be a quoted string. E.g.:
+may be called in. Valid states are unconsumed, consumed, or unknown. Each
+argument to this attribute must be a quoted string. E.g.:
``__attribute__((callable_when("unconsumed", "unknown")))``
}];
@@ -2372,9 +2372,9 @@ returns true if the object is in the specified state..
def ParamTypestateDocs : Documentation {
let Category = DocCatConsumed;
let Content = [{
-This attribute specifies expectations about function parameters. Calls to an
+This attribute specifies expectations about function parameters. Calls to an
function with annotated parameters will issue a warning if the corresponding
-argument isn't in the expected state. The attribute is also used to set the
+argument isn't in the expected state. The attribute is also used to set the
initial state of the parameter when analyzing the function's body.
}];
}
@@ -2384,12 +2384,12 @@ def ReturnTypestateDocs : Documentation {
let Content = [{
The ``return_typestate`` attribute can be applied to functions or parameters.
When applied to a function the attribute specifies the state of the returned
-value. The function's body is checked to ensure that it always returns a value
-in the specified state. On the caller side, values returned by the annotated
+value. The function's body is checked to ensure that it always returns a value
+in the specified state. On the caller side, values returned by the annotated
function are initialized to the given state.
When applied to a function parameter it modifies the state of an argument after
-a call to the function returns. The function's body is checked to ensure that
+a call to the function returns. The function's body is checked to ensure that
the parameter is in the expected state before returning.
}];
}
@@ -2398,7 +2398,7 @@ def ConsumableDocs : Documentation {
let Category = DocCatConsumed;
let Content = [{
Each ``class`` that uses any of the typestate annotations must first be marked
-using the ``consumable`` attribute. Failure to do so will result in a warning.
+using the ``consumable`` attribute. Failure to do so will result in a warning.
This attribute accepts a single parameter that must be one of the following:
``unknown``, ``consumed``, or ``unconsumed``.
@@ -2486,7 +2486,7 @@ checks, ensure that -Wtype-safety is enabled. Use cases include:
* checking types of variadic functions' arguments for functions like
``fcntl()`` and ``ioctl()``.
-You can detect support for these attributes with ``__has_attribute()``. For
+You can detect support for these attributes with ``__has_attribute()``. For
example:
.. code-block:: c++
@@ -2496,7 +2496,7 @@ example:
__has_attribute(pointer_with_type_tag) && \
__has_attribute(type_tag_for_datatype)
# define ATTR_MPI_PWT(buffer_idx, type_idx) __attribute__((pointer_with_type_tag(mpi,buffer_idx,type_idx)))
- /* ... other macros ... */
+ /* ... other macros ... */
# endif
#endif
@@ -2651,14 +2651,14 @@ values for this optional third argument:
/* In user code */
struct my_pair { double a; int b; };
struct my_pair *buffer;
- MPI_Send(buffer, 1, MPI_DOUBLE_INT /*, ... */); // no warning because the
+ MPI_Send(buffer, 1, MPI_DOUBLE_INT /*, ... */); // no warning because the
// layout of my_pair is
// compatible with that of
// internal_mpi_double_int
struct my_int_pair { int a; int b; }
struct my_int_pair *buffer2;
- MPI_Send(buffer2, 1, MPI_DOUBLE_INT /*, ... */); // warning because the
+ MPI_Send(buffer2, 1, MPI_DOUBLE_INT /*, ... */); // warning because the
// layout of my_int_pair
// does not match that of
// internal_mpi_double_int
@@ -2683,7 +2683,7 @@ values for this optional third argument:
/* In user code */
struct my_pair { double a; int b; };
struct my_pair *buffer;
- MPI_Send(buffer, 1, MPI_DATATYPE_NULL /*, ... */); // warning: MPI_DATATYPE_NULL
+ MPI_Send(buffer, 1, MPI_DATATYPE_NULL /*, ... */); // warning: MPI_DATATYPE_NULL
// was specified but buffer
// is not a null pointer
}];
@@ -2714,18 +2714,18 @@ Clang implements two kinds of checks with this attribute.
#. Clang checks that the function with the ``format`` attribute is called with
a format string that uses format specifiers that are allowed, and that
- arguments match the format string. This is the ``-Wformat`` warning, it is
+ arguments match the format string. This is the ``-Wformat`` warning, it is
on by default.
-#. Clang checks that the format string argument is a literal string. This is
+#. Clang checks that the format string argument is a literal string. This is
the ``-Wformat-nonliteral`` warning, it is off by default.
Clang implements this mostly the same way as GCC, but there is a
diff erence
for functions that accept a ``va_list`` argument (for example, ``vprintf``).
GCC does not emit ``-Wformat-nonliteral`` warning for calls to such
- functions. Clang does not warn if the format string comes from a function
+ functions. Clang does not warn if the format string comes from a function
parameter, where the function is annotated with a compatible attribute,
- otherwise it warns. For example:
+ otherwise it warns. For example:
.. code-block:: c
@@ -2756,7 +2756,7 @@ Clang implements two kinds of checks with this attribute.
}
In this case Clang does not warn because the format string ``s`` and
- the corresponding arguments are annotated. If the arguments are
+ the corresponding arguments are annotated. If the arguments are
incorrect, the caller of ``foo`` will receive a warning.
}];
}
@@ -2796,7 +2796,14 @@ def AsmLabelDocs : Documentation {
let Content = [{
This attribute can be used on a function or variable to specify its symbol name.
-On some targets, all C symbols are prefixed by default with a single character, typically ``_``. This was done historically to distinguish them from symbols used by other languages. (This prefix is also added to the standard Itanium C++ ABI prefix on "mangled" symbol names, so that e.g. on such targets the true symbol name for a C++ variable declared as ``int cppvar;`` would be ``__Z6cppvar``; note the two underscores.) This prefix is *not* added to the symbol names specified by the ``asm`` attribute; programmers wishing to match a C symbol name must compensate for this.
+On some targets, all C symbols are prefixed by default with a single character,
+typically ``_``. This was done historically to distinguish them from symbols
+used by other languages. (This prefix is also added to the standard Itanium
+C++ ABI prefix on "mangled" symbol names, so that e.g. on such targets the true
+symbol name for a C++ variable declared as ``int cppvar;`` would be
+``__Z6cppvar``; note the two underscores.) This prefix is *not* added to the
+symbol names specified by the ``asm`` attribute; programmers wishing to match a
+C symbol name must compensate for this.
For example, consider the following C code:
@@ -2811,7 +2818,11 @@ For example, consider the following C code:
Clang's implementation of this attribute is compatible with GCC's, `documented here <https://gcc.gnu.org/onlinedocs/gcc/Asm-Labels.html>`_.
-While it is possible to use this attribute to name a special symbol used internally by the compiler, such as an LLVM intrinsic, this is neither recommended nor supported and may cause the compiler to crash or miscompile. Users who wish to gain access to intrinsic behavior are strongly encouraged to request new builtin functions.
+While it is possible to use this attribute to name a special symbol used
+internally by the compiler, such as an LLVM intrinsic, this is neither
+recommended nor supported and may cause the compiler to crash or miscompile.
+Users who wish to gain access to intrinsic behavior are strongly encouraged to
+request new builtin functions.
}];
}
@@ -2937,7 +2948,8 @@ Attribute ``trivial_abi`` has no effect in the following cases:
- The class directly declares a virtual base or virtual methods.
- Copy constructors and move constructors of the class are all deleted.
- The class has a base class that is non-trivial for the purposes of calls.
-- The class has a non-static data member whose type is non-trivial for the purposes of calls, which includes:
+- The class has a non-static data member whose type is non-trivial for the
+purposes of calls, which includes:
- classes that are non-trivial for the purposes of calls
- __weak-qualified types in Objective-C++
@@ -2957,7 +2969,7 @@ varies in size and alignment depending on the definition of the underlying
class.
However, this is problematic when a forward declaration is only available and
-no definition has been made yet. In such cases, Clang is forced to utilize the
+no definition has been made yet. In such cases, Clang is forced to utilize the
most general representation that is available to it.
These keywords make it possible to use a pointer-to-member representation other
@@ -3006,9 +3018,9 @@ def OptnoneDocs : Documentation {
let Content = [{
The ``optnone`` attribute suppresses essentially all optimizations
on a function or method, regardless of the optimization level applied to
-the compilation unit as a whole. This is particularly useful when you
+the compilation unit as a whole. This is particularly useful when you
need to debug a particular function, but it is infeasible to build the
-entire application without optimization. Avoiding optimization on the
+entire application without optimization. Avoiding optimization on the
specified function can improve the quality of the debugging information
for that function.
@@ -3053,7 +3065,7 @@ time:
}
Specifying the optional parameter, ``#pragma unroll _value_``, directs the
-unroller to unroll the loop ``_value_`` times. The parameter may optionally be
+unroller to unroll the loop ``_value_`` times. The parameter may optionally be
enclosed in parentheses:
.. code-block:: c++
@@ -3080,7 +3092,7 @@ Specifying ``#pragma nounroll`` indicates that the loop should not be unrolled:
``#pragma unroll`` and ``#pragma unroll _value_`` have identical semantics to
``#pragma clang loop unroll(full)`` and
``#pragma clang loop unroll_count(_value_)`` respectively. ``#pragma nounroll``
-is equivalent to ``#pragma clang loop unroll(disable)``. See
+is equivalent to ``#pragma clang loop unroll(disable)``. See
`language extensions
<http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-loop-hint-optimizations>`_
for further details including limitations of the unroll hints.
@@ -3350,9 +3362,25 @@ extended when converted to a 64-bit pointer.
def NullabilityDocs : DocumentationCategory<"Nullability Attributes"> {
let Content = [{
-Whether a particular pointer may be "null" is an important concern when working with pointers in the C family of languages. The various nullability attributes indicate whether a particular pointer can be null or not, which makes APIs more expressive and can help static analysis tools identify bugs involving null pointers. Clang supports several kinds of nullability attributes: the ``nonnull`` and ``returns_nonnull`` attributes indicate which function or method parameters and result types can never be null, while nullability type qualifiers indicate which pointer types can be null (``_Nullable``) or cannot be null (``_Nonnull``).
-
-The nullability (type) qualifiers express whether a value of a given pointer type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning for null (the ``_Nonnull`` qualifier), or for which the purpose of null is unclear (the ``_Null_unspecified`` qualifier). Because nullability qualifiers are expressed within the type system, they are more general than the ``nonnull`` and ``returns_nonnull`` attributes, allowing one to express (for example) a nullable pointer to an array of nonnull pointers. Nullability qualifiers are written to the right of the pointer to which they apply. For example:
+Whether a particular pointer may be "null" is an important concern when working
+with pointers in the C family of languages. The various nullability attributes
+indicate whether a particular pointer can be null or not, which makes APIs more
+expressive and can help static analysis tools identify bugs involving null
+pointers. Clang supports several kinds of nullability attributes: the
+``nonnull`` and ``returns_nonnull`` attributes indicate which function or
+method parameters and result types can never be null, while nullability type
+qualifiers indicate which pointer types can be null (``_Nullable``) or cannot
+be null (``_Nonnull``).
+
+The nullability (type) qualifiers express whether a value of a given pointer
+type can be null (the ``_Nullable`` qualifier), doesn't have a defined meaning
+for null (the ``_Nonnull`` qualifier), or for which the purpose of null is
+unclear (the ``_Null_unspecified`` qualifier). Because nullability qualifiers
+are expressed within the type system, they are more general than the
+``nonnull`` and ``returns_nonnull`` attributes, allowing one to express (for
+example) a nullable pointer to an array of nonnull pointers. Nullability
+qualifiers are written to the right of the pointer to which they apply. For
+example:
.. code-block:: c
@@ -3367,7 +3395,9 @@ The nullability (type) qualifiers express whether a value of a given pointer typ
// A nullable pointer to non-null pointers to const characters.
const char *join_strings(const char * _Nonnull * _Nullable strings, unsigned n);
-In Objective-C, there is an alternate spelling for the nullability qualifiers that can be used in Objective-C methods and properties using context-sensitive, non-underscored keywords. For example:
+In Objective-C, there is an alternate spelling for the nullability qualifiers
+that can be used in Objective-C methods and properties using context-sensitive,
+non-underscored keywords. For example:
.. code-block:: objective-c
@@ -3382,20 +3412,28 @@ In Objective-C, there is an alternate spelling for the nullability qualifiers th
def TypeNonNullDocs : Documentation {
let Category = NullabilityDocs;
let Content = [{
-The ``_Nonnull`` nullability qualifier indicates that null is not a meaningful value for a value of the ``_Nonnull`` pointer type. For example, given a declaration such as:
+The ``_Nonnull`` nullability qualifier indicates that null is not a meaningful
+value for a value of the ``_Nonnull`` pointer type. For example, given a
+declaration such as:
.. code-block:: c
int fetch(int * _Nonnull ptr);
-a caller of ``fetch`` should not provide a null value, and the compiler will produce a warning if it sees a literal null value passed to ``fetch``. Note that, unlike the declaration attribute ``nonnull``, the presence of ``_Nonnull`` does not imply that passing null is undefined behavior: ``fetch`` is free to consider null undefined behavior or (perhaps for backward-compatibility reasons) defensively handle null.
+a caller of ``fetch`` should not provide a null value, and the compiler will
+produce a warning if it sees a literal null value passed to ``fetch``. Note
+that, unlike the declaration attribute ``nonnull``, the presence of
+``_Nonnull`` does not imply that passing null is undefined behavior: ``fetch``
+is free to consider null undefined behavior or (perhaps for
+backward-compatibility reasons) defensively handle null.
}];
}
def TypeNullableDocs : Documentation {
let Category = NullabilityDocs;
let Content = [{
-The ``_Nullable`` nullability qualifier indicates that a value of the ``_Nullable`` pointer type can be null. For example, given:
+The ``_Nullable`` nullability qualifier indicates that a value of the
+``_Nullable`` pointer type can be null. For example, given:
.. code-block:: c
@@ -3408,14 +3446,22 @@ a caller of ``fetch_or_zero`` can provide null.
def TypeNullUnspecifiedDocs : Documentation {
let Category = NullabilityDocs;
let Content = [{
-The ``_Null_unspecified`` nullability qualifier indicates that neither the ``_Nonnull`` nor ``_Nullable`` qualifiers make sense for a particular pointer type. It is used primarily to indicate that the role of null with specific pointers in a nullability-annotated header is unclear, e.g., due to overly-complex implementations or historical factors with a long-lived API.
+The ``_Null_unspecified`` nullability qualifier indicates that neither the
+``_Nonnull`` nor ``_Nullable`` qualifiers make sense for a particular pointer
+type. It is used primarily to indicate that the role of null with specific
+pointers in a nullability-annotated header is unclear, e.g., due to
+overly-complex implementations or historical factors with a long-lived API.
}];
}
def NonNullDocs : Documentation {
let Category = NullabilityDocs;
let Content = [{
-The ``nonnull`` attribute indicates that some function parameters must not be null, and can be used in several
diff erent ways. It's original usage (`from GCC <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes>`_) is as a function (or Objective-C method) attribute that specifies which parameters of the function are nonnull in a comma-separated list. For example:
+The ``nonnull`` attribute indicates that some function parameters must not be
+null, and can be used in several
diff erent ways. It's original usage
+(`from GCC <https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes>`_)
+is as a function (or Objective-C method) attribute that specifies which
+parameters of the function are nonnull in a comma-separated list. For example:
.. code-block:: c
@@ -3423,34 +3469,48 @@ The ``nonnull`` attribute indicates that some function parameters must not be nu
__attribute__((nonnull (1, 2)));
Here, the ``nonnull`` attribute indicates that parameters 1 and 2
-cannot have a null value. Omitting the parenthesized list of parameter indices means that all parameters of pointer type cannot be null:
+cannot have a null value. Omitting the parenthesized list of parameter indices
+means that all parameters of pointer type cannot be null:
.. code-block:: c
extern void * my_memcpy (void *dest, const void *src, size_t len)
__attribute__((nonnull));
-Clang also allows the ``nonnull`` attribute to be placed directly on a function (or Objective-C method) parameter, eliminating the need to specify the parameter index ahead of type. For example:
+Clang also allows the ``nonnull`` attribute to be placed directly on a function
+(or Objective-C method) parameter, eliminating the need to specify the
+parameter index ahead of type. For example:
.. code-block:: c
extern void * my_memcpy (void *dest __attribute__((nonnull)),
const void *src __attribute__((nonnull)), size_t len);
-Note that the ``nonnull`` attribute indicates that passing null to a non-null parameter is undefined behavior, which the optimizer may take advantage of to, e.g., remove null checks. The ``_Nonnull`` type qualifier indicates that a pointer cannot be null in a more general manner (because it is part of the type system) and does not imply undefined behavior, making it more widely applicable.
+Note that the ``nonnull`` attribute indicates that passing null to a non-null
+parameter is undefined behavior, which the optimizer may take advantage of to,
+e.g., remove null checks. The ``_Nonnull`` type qualifier indicates that a
+pointer cannot be null in a more general manner (because it is part of the type
+system) and does not imply undefined behavior, making it more widely applicable.
}];
}
def ReturnsNonNullDocs : Documentation {
let Category = NullabilityDocs;
let Content = [{
-The ``returns_nonnull`` attribute indicates that a particular function (or Objective-C method) always returns a non-null pointer. For example, a particular system ``malloc`` might be defined to terminate a process when memory is not available rather than returning a null pointer:
+The ``returns_nonnull`` attribute indicates that a particular function (or
+Objective-C method) always returns a non-null pointer. For example, a
+particular system ``malloc`` might be defined to terminate a process when
+memory is not available rather than returning a null pointer:
.. code-block:: c
extern void * malloc (size_t size) __attribute__((returns_nonnull));
-The ``returns_nonnull`` attribute implies that returning a null pointer is undefined behavior, which the optimizer may take advantage of. The ``_Nonnull`` type qualifier indicates that a pointer cannot be null in a more general manner (because it is part of the type system) and does not imply undefined behavior, making it more widely applicable
+The ``returns_nonnull`` attribute implies that returning a null pointer is
+undefined behavior, which the optimizer may take advantage of. The ``_Nonnull``
+type qualifier indicates that a pointer cannot be null in a more general manner
+(because it is part of the type system) and does not imply undefined behavior,
+making it more widely applicable
}];
}
@@ -3521,7 +3581,7 @@ attribute appertains is bridged to the named Swift type.
@end
In this example, the Objective-C interface ``I`` will be made available to Swift
-with the name ``BridgedI``. It would be possible for the compiler to refer to
+with the name ``BridgedI``. It would be possible for the compiler to refer to
``I`` still in order to bridge the type back to Objective-C.
}];
}
@@ -3567,7 +3627,7 @@ which dynamic convention it uses.
All of these conventions except ``none`` require the function to have an error
parameter. Currently, the error parameter is always the last parameter of type
-``NSError**`` or ``CFErrorRef*``. Swift will remove the error parameter from
+``NSError**`` or ``CFErrorRef*``. Swift will remove the error parameter from
the imported API. When calling the API, Swift will always pass a valid address
initialized to a null pointer.
@@ -3608,7 +3668,7 @@ built into the Swift compiler.
The argument is a string literal that contains the Swift name of the function,
variable, or type. When renaming a function, the name may be a compound Swift
-name. For a type, enum constant, property, or variable declaration, the name
+name. For a type, enum constant, property, or variable declaration, the name
must be a simple or qualified identifier.
.. code-block:: objc
@@ -3628,7 +3688,7 @@ def SwiftNewTypeDocs : Documentation {
let Content = [{
The ``swift_newtype`` attribute indicates that the typedef to which the
attribute appertains is imported as a new Swift type of the typedef's name.
-Previously, the attribute was spelt ``swift_wrapper``. While the behaviour of
+Previously, the attribute was spelt ``swift_wrapper``. While the behaviour of
the attribute is identical with either spelling, ``swift_wrapper`` is
deprecated, only exists for compatibility purposes, and should not be used in
new code.
@@ -3806,7 +3866,10 @@ option.
def NotTailCalledDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
-The ``not_tail_called`` attribute prevents tail-call optimization on statically bound calls. It has no effect on indirect calls. Virtual functions, objective-c methods, and functions marked as ``always_inline`` cannot be marked as ``not_tail_called``.
+The ``not_tail_called`` attribute prevents tail-call optimization on statically
+bound calls. It has no effect on indirect calls. Virtual functions, objective-c
+methods, and functions marked as ``always_inline`` cannot be marked as
+``not_tail_called``.
For example, it prevents tail-call optimization in the following case:
@@ -3827,8 +3890,8 @@ However, it doesn't prevent tail-call optimization in this case:
int foo2(int a) {
int (*fn)(int) = &foo1;
- // not_tail_called has no effect on an indirect call even if the call can be
- // resolved at compile time.
+ // not_tail_called has no effect on an indirect call even if the call can
+ // be resolved at compile time.
return (*fn)(a);
}
@@ -3872,10 +3935,12 @@ guaranteed to not throw an exception.
def InternalLinkageDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
-The ``internal_linkage`` attribute changes the linkage type of the declaration to internal.
-This is similar to C-style ``static``, but can be used on classes and class methods. When applied to a class definition,
-this attribute affects all methods and static data members of that class.
-This can be used to contain the ABI of a C++ library by excluding unwanted class methods from the export tables.
+The ``internal_linkage`` attribute changes the linkage type of the declaration
+to internal. This is similar to C-style ``static``, but can be used on classes
+and class methods. When applied to a class definition, this attribute affects
+all methods and static data members of that class. This can be used to contain
+the ABI of a C++ library by excluding unwanted class methods from the export
+tables.
}];
}
@@ -3944,7 +4009,8 @@ templates.
def DisableTailCallsDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
-The ``disable_tail_calls`` attribute instructs the backend to not perform tail call optimization inside the marked function.
+The ``disable_tail_calls`` attribute instructs the backend to not perform tail
+call optimization inside the marked function.
For example:
@@ -4062,13 +4128,13 @@ The ``swiftcall`` attribute indicates that a function should be called
using the Swift calling convention for a function or function pointer.
The lowering for the Swift calling convention, as described by the Swift
-ABI documentation, occurs in multiple phases. The first, "high-level"
+ABI documentation, occurs in multiple phases. The first, "high-level"
phase breaks down the formal parameters and results into innately direct
and indirect components, adds implicit parameters for the generic
signature, and assigns the context and error ABI treatments to parameters
-where applicable. The second phase breaks down the direct parameters
+where applicable. The second phase breaks down the direct parameters
and results from the first phase and assigns them to registers or the
-stack. The ``swiftcall`` convention only handles this second phase of
+stack. The ``swiftcall`` convention only handles this second phase of
lowering; the C function type must accurately reflect the results
of the first phase, as follows:
@@ -4108,12 +4174,12 @@ of the first phase, as follows:
The parameter ABI treatment attributes are aspects of the function type.
A function type which applies an ABI treatment attribute to a
parameter is a
diff erent type from an otherwise-identical function type
-that does not. A single parameter may not have multiple ABI treatment
+that does not. A single parameter may not have multiple ABI treatment
attributes.
Support for this feature is target-dependent, although it should be
-supported on every target that Swift supports. Query for this support
-with ``__has_attribute(swiftcall)``. This implies support for the
+supported on every target that Swift supports. Query for this support
+with ``__has_attribute(swiftcall)``. This implies support for the
``swift_context``, ``swift_error_result``, and ``swift_indirect_result``
attributes.
}];
@@ -4151,16 +4217,16 @@ This is modeled in C by pretending that the register is addressable memory:
the call; if the call returns normally, the value is copied back into the
variable.
-- The callee appears to receive the address of a variable. This address
+- The callee appears to receive the address of a variable. This address
is actually a hidden location in its own stack, initialized with the
- value of the register upon entry. When the function returns normally,
+ value of the register upon entry. When the function returns normally,
the value in that hidden location is written back to the register.
A ``swift_error_result`` parameter must be the last parameter, and it must be
preceded by a ``swift_context`` parameter.
A ``swift_error_result`` parameter must have type ``T**`` or ``T*&`` for some
-type T. Note that no qualifiers are permitted on the intermediate level.
+type T. Note that no qualifiers are permitted on the intermediate level.
It is undefined behavior if the caller does not pass a pointer or
reference to a valid object.
@@ -4179,8 +4245,8 @@ function as having the special indirect-result ABI treatment.
This treatment gives the parameter the target's normal indirect-result
ABI treatment, which may involve passing it
diff erently from an ordinary
-parameter. However, only the first indirect result will receive this
-treatment. Furthermore, low-level lowering may decide that a direct result
+parameter. However, only the first indirect result will receive this
+treatment. Furthermore, low-level lowering may decide that a direct result
must be returned indirectly; if so, this will take priority over the
``swift_indirect_result`` parameters.
@@ -4188,7 +4254,7 @@ A ``swift_indirect_result`` parameter must either be the first parameter or
follow another ``swift_indirect_result`` parameter.
A ``swift_indirect_result`` parameter must have type ``T*`` or ``T&`` for
-some object type ``T``. If ``T`` is a complete type at the point of
+some object type ``T``. If ``T`` is a complete type at the point of
definition of a function, it is undefined behavior if the argument
value does not point to storage of adequate size and alignment for a
value of type ``T``.
@@ -4330,13 +4396,23 @@ string argument which is the message to display when emitting the warning.
def IFuncDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
-``__attribute__((ifunc("resolver")))`` is used to mark that the address of a declaration should be resolved at runtime by calling a resolver function.
+``__attribute__((ifunc("resolver")))`` is used to mark that the address of a
+declaration should be resolved at runtime by calling a resolver function.
-The symbol name of the resolver function is given in quotes. A function with this name (after mangling) must be defined in the current translation unit; it may be ``static``. The resolver function should return a pointer.
+The symbol name of the resolver function is given in quotes. A function with
+this name (after mangling) must be defined in the current translation unit; it
+may be ``static``. The resolver function should return a pointer.
-The ``ifunc`` attribute may only be used on a function declaration. A function declaration with an ``ifunc`` attribute is considered to be a definition of the declared entity. The entity must not have weak linkage; for example, in C++, it cannot be applied to a declaration if a definition at that location would be considered inline.
+The ``ifunc`` attribute may only be used on a function declaration. A function
+declaration with an ``ifunc`` attribute is considered to be a definition of the
+declared entity. The entity must not have weak linkage; for example, in C++,
+it cannot be applied to a declaration if a definition at that location would be
+considered inline.
-Not all targets support this attribute. ELF target support depends on both the linker and runtime linker, and is available in at least lld 4.0 and later, binutils 2.20.1 and later, glibc v2.11.1 and later, and FreeBSD 9.1 and later. Non-ELF targets currently do not support this attribute.
+Not all targets support this attribute. ELF target support depends on both the
+linker and runtime linker, and is available in at least lld 4.0 and later,
+binutils 2.20.1 and later, glibc v2.11.1 and later, and FreeBSD 9.1 and later.
+Non-ELF targets currently do not support this attribute.
}];
}
@@ -4354,7 +4430,7 @@ def RenderScriptKernelAttributeDocs : Documentation {
RenderScript.
In RenderScript, ``kernel`` functions are used to express data-parallel
-computations. The RenderScript runtime efficiently parallelizes ``kernel``
+computations. The RenderScript runtime efficiently parallelizes ``kernel``
functions to run on computational resources such as multi-core CPUs and GPUs.
See the RenderScript_ documentation for more information.
@@ -4366,13 +4442,23 @@ def XRayDocs : Documentation {
let Category = DocCatFunction;
let Heading = "xray_always_instrument, xray_never_instrument, xray_log_args";
let Content = [{
-``__attribute__((xray_always_instrument))`` or ``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++), methods (in Objective C), and free functions (in C, C++, and Objective C) to be instrumented with XRay. This will cause the function to always have space at the beginning and exit points to allow for runtime patching.
+``__attribute__((xray_always_instrument))`` or
+``[[clang::xray_always_instrument]]`` is used to mark member functions (in C++),
+methods (in Objective C), and free functions (in C, C++, and Objective C) to be
+instrumented with XRay. This will cause the function to always have space at
+the beginning and exit points to allow for runtime patching.
-Conversely, ``__attribute__((xray_never_instrument))`` or ``[[clang::xray_never_instrument]]`` will inhibit the insertion of these instrumentation points.
+Conversely, ``__attribute__((xray_never_instrument))`` or
+``[[clang::xray_never_instrument]]`` will inhibit the insertion of these
+instrumentation points.
-If a function has neither of these attributes, they become subject to the XRay heuristics used to determine whether a function should be instrumented or otherwise.
+If a function has neither of these attributes, they become subject to the XRay
+heuristics used to determine whether a function should be instrumented or
+otherwise.
-``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is used to preserve N function arguments for the logging function. Currently, only N==1 is supported.
+``__attribute__((xray_log_args(N)))`` or ``[[clang::xray_log_args(N)]]`` is
+used to preserve N function arguments for the logging function. Currently,
+only N==1 is supported.
}];
}
@@ -4430,8 +4516,8 @@ def ObjCDirectDocs : Documentation {
let Category = DocCatDecl;
let Content = [{
The ``objc_direct`` attribute can be used to mark an Objective-C method as
-being *direct*. A direct method is treated statically like an ordinary method,
-but dynamically it behaves more like a C function. This lowers some of the costs
+being *direct*. A direct method is treated statically like an ordinary method,
+but dynamically it behaves more like a C function. This lowers some of the costs
associated with the method but also sacrifices some of the ordinary capabilities
of Objective-C methods.
@@ -4478,7 +4564,7 @@ It is an error to do any of the following:
If any of these rules would be violated if every method defined in an
``@implementation`` within a single linkage unit were declared in an
appropriate class interface, the program is ill-formed with no diagnostic
-required. If a violation of this rule is not diagnosed, behavior remains
+required. If a violation of this rule is not diagnosed, behavior remains
well-defined; this paragraph is simply reserving the right to diagnose such
conflicts in the future, not to treat them as undefined behavior.
@@ -4490,11 +4576,11 @@ For the purpose of these rules, a "class interface" includes a class's primary
and all the class interfaces of its superclasses.
An Objective-C property can be declared with the ``direct`` property
-attribute. If a direct property declaration causes an implicit declaration of
+attribute. If a direct property declaration causes an implicit declaration of
a getter or setter method (that is, if the given method is not explicitly
declared elsewhere), the method is declared to be direct.
-Some programmers may wish to make many methods direct at once. In order
+Some programmers may wish to make many methods direct at once. In order
to simplify this, the ``objc_direct_members`` attribute is provided; see its
documentation for more information.
}];
@@ -4505,12 +4591,12 @@ def ObjCDirectMembersDocs : Documentation {
let Content = [{
The ``objc_direct_members`` attribute can be placed on an Objective-C
``@interface`` or ``@implementation`` to mark that methods declared
-therein should be considered direct by default. See the documentation
+therein should be considered direct by default. See the documentation
for ``objc_direct`` for more information about direct methods.
When ``objc_direct_members`` is placed on an ``@interface`` block, every
-method in the block is considered to be declared as direct. This includes any
-implicit method declarations introduced by property declarations. If the method
+method in the block is considered to be declared as direct. This includes any
+implicit method declarations introduced by property declarations. If the method
redeclares a non-direct method, the declaration is ill-formed, exactly as if the
method was annotated with the ``objc_direct`` attribute.
@@ -4637,8 +4723,8 @@ accessed. The following are examples of valid expressions where may not be diagn
p = &s->a;
p = &(*s).a;
-``noderef`` is currently only supported for pointers and arrays and not usable for
-references or Objective-C object pointers.
+``noderef`` is currently only supported for pointers and arrays and not usable
+for references or Objective-C object pointers.
.. code-block: c++
@@ -5285,7 +5371,7 @@ other than overloading.
def ArmCmseNSCallDocs : Documentation {
let Category = DocCatType;
let Content = [{
-This attribute declares a non-secure function type. When compiling for secure
+This attribute declares a non-secure function type. When compiling for secure
state, a call to such a function would switch from secure to non-secure state.
All non-secure function calls must happen only through a function pointer, and
a non-secure function type should only be used as a base type of a pointer.
More information about the cfe-commits
mailing list