forked from OSchip/llvm-project
[clang] Fix typos in documentation (NFC)
This commit is contained in:
parent
d96af2ed2d
commit
31443f8e86
|
@ -1345,7 +1345,7 @@ or transferring them.
|
|||
|
||||
Similar transfers of responsibility occur for ``__weak`` fields, but
|
||||
since both sides must use native ``__weak`` support to ensure
|
||||
calling convention compatibililty, this transfer is always handled
|
||||
calling convention compatibility, this transfer is always handled
|
||||
automatically by the compiler.
|
||||
|
||||
.. admonition:: Rationale
|
||||
|
|
|
@ -37,7 +37,7 @@ The configuration file can consist of several sections each having different
|
|||
``Language:`` parameter denoting the programming language this section of the
|
||||
configuration is targeted at. See the description of the **Language** option
|
||||
below for the list of supported languages. The first section may have no
|
||||
language set, it will set the default style options for all lanugages.
|
||||
language set, it will set the default style options for all languages.
|
||||
Configuration sections for specific language will override options set in the
|
||||
default section.
|
||||
|
||||
|
@ -3713,7 +3713,7 @@ The result is:
|
|||
break;
|
||||
}
|
||||
if (condition)
|
||||
do_somthing_completely_different();
|
||||
do_something_completely_different();
|
||||
|
||||
if (x == y)
|
||||
{
|
||||
|
|
|
@ -283,7 +283,7 @@ for CFI. For example, this is necessary when a function's address
|
|||
is taken by assembly code and then called by CFI-checking C code. The
|
||||
``__attribute__((cfi_canonical_jump_table))`` attribute may be used to make
|
||||
the jump table entry of a specific function canonical so that the external
|
||||
code will end up taking a address for the function that will pass CFI checks.
|
||||
code will end up taking an address for the function that will pass CFI checks.
|
||||
|
||||
``-fsanitize=cfi-icall`` and ``-fsanitize=function``
|
||||
----------------------------------------------------
|
||||
|
|
|
@ -718,7 +718,7 @@ General case
|
|||
------------
|
||||
For functions called multiple times a *return jump table* is constructed
|
||||
in the same manner as jump tables for indirect function calls (see above).
|
||||
The correct jump table entry (or it's index) is passed by `CALL` to `f()`
|
||||
The correct jump table entry (or its index) is passed by `CALL` to `f()`
|
||||
(as an extra argument) and then spilled to stack.
|
||||
The `RET` instruction is replaced with a load of the jump table entry,
|
||||
jump table range check, and `JMP` to the jump table entry.
|
||||
|
|
|
@ -1854,7 +1854,7 @@ Because the same entity can be defined multiple times in different modules,
|
|||
it is also possible for there to be multiple definitions of (for instance)
|
||||
a ``CXXRecordDecl``, all of which describe a definition of the same class.
|
||||
In such a case, only one of those "definitions" is considered by Clang to be
|
||||
the definiition of the class, and the others are treated as non-defining
|
||||
the definition of the class, and the others are treated as non-defining
|
||||
declarations that happen to also contain member declarations. Corresponding
|
||||
members in each definition of such multiply-defined classes are identified
|
||||
either by redeclaration chains (if the members are ``Redeclarable``)
|
||||
|
|
|
@ -132,7 +132,7 @@ macro returns a nonzero value based on the year and month in which the attribute
|
|||
was voted into the working draft. See `WG21 SD-6
|
||||
<https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations>`_
|
||||
for the list of values returned for standards-based attributes. If the attribute
|
||||
is not supported by the current compliation target, this macro evaluates to 0.
|
||||
is not supported by the current compilation target, this macro evaluates to 0.
|
||||
It can be used like this:
|
||||
|
||||
.. code-block:: c++
|
||||
|
@ -1784,7 +1784,7 @@ Extension Specification, section 1.2
|
|||
|
||||
This is not conformant behavior and it can only be used portably when the
|
||||
functions with variadic prototypes do not get generated in binary e.g. the
|
||||
variadic prototype is used to spesify a function type with any number of
|
||||
variadic prototype is used to specify a function type with any number of
|
||||
arguments in metaprogramming algorithms in C++ for OpenCL.
|
||||
|
||||
This extensions can also be used when the kernel code is intended for targets
|
||||
|
@ -2495,7 +2495,7 @@ guarantees not to call any external functions. See LLVM IR `llvm.memcpy.inline
|
|||
<https://llvm.org/docs/LangRef.html#llvm-memcpy-inline-intrinsic>`_ intrinsic
|
||||
for more information.
|
||||
|
||||
This is useful to implement a custom version of ``memcpy``, implemement a
|
||||
This is useful to implement a custom version of ``memcpy``, implement a
|
||||
``libc`` memcpy or work around the absence of a ``libc``.
|
||||
|
||||
Note that the `size` argument must be a compile time constant.
|
||||
|
|
|
@ -319,7 +319,7 @@ It is sometimes useful to tell SanitizerCoverage to instrument only a subset of
|
|||
functions in your target.
|
||||
With ``-fsanitize-coverage-allowlist=allowlist.txt``
|
||||
and ``-fsanitize-coverage-blocklist=blocklist.txt``,
|
||||
you can specify such a subset through the combination of a allowlist and a blocklist.
|
||||
you can specify such a subset through the combination of an allowlist and a blocklist.
|
||||
|
||||
SanitizerCoverage will only instrument functions that satisfy two conditions.
|
||||
First, the function should belong to a source file with a path that is both allowlisted
|
||||
|
|
|
@ -2260,14 +2260,14 @@ programs using the same instrumentation method as ``-fprofile-generate``.
|
|||
|
||||
The resulted ``cs_code.prodata`` combines ``code.profdata`` and the profile
|
||||
generated from binary ``cs_code``. Profile ``cs_code.profata`` can be used by
|
||||
``-fprofile-use`` compilaton.
|
||||
``-fprofile-use`` compilation.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ clang++ -O2 -fprofile-use=cs_code.profdata
|
||||
|
||||
The above command will read both profiles to the compiler at the identical
|
||||
point of instrumenations.
|
||||
point of instrumentations.
|
||||
|
||||
.. option:: -fprofile-use[=<pathname>]
|
||||
|
||||
|
|
|
@ -438,7 +438,7 @@ optin.cplusplus.UninitializedObject (C++)
|
|||
|
||||
This checker reports uninitialized fields in objects created after a constructor
|
||||
call. It doesn't only find direct uninitialized fields, but rather makes a deep
|
||||
inspection of the object, analyzing all of it's fields subfields.
|
||||
inspection of the object, analyzing all of its fields' subfields.
|
||||
The checker regards inherited fields as direct fields, so one will receive
|
||||
warnings for uninitialized inherited data members as well.
|
||||
|
||||
|
|
|
@ -128,7 +128,7 @@ If the conditions are right for inlining, a CallEnter node is created and added
|
|||
to the analysis work list. The CallEnter node marks the change to a new
|
||||
LocationContext representing the called function, and its state includes the
|
||||
contents of the new stack frame. When the CallEnter node is actually processed,
|
||||
its single successor will be a edge to the first CFG block in the function.
|
||||
its single successor will be an edge to the first CFG block in the function.
|
||||
|
||||
Exiting an inlined function is a bit more work, fortunately broken up into
|
||||
reasonable steps:
|
||||
|
|
Loading…
Reference in New Issue