[clang] Proofread *.rst (#166897)
This patch is limited to single-word replacements to fix spelling and/or grammar to ease the review process. Punctuation and markdown fixes are specifically excluded.
This commit is contained in:
parent
f55b393ea0
commit
a3b5b4bd79
@ -242,7 +242,7 @@ ARM EABI
|
||||
Compiler-Wide Topics
|
||||
--------------------
|
||||
The following people are responsible for functionality that does not fit into
|
||||
a single part of the compiler, but instead span multiple components within the
|
||||
a single part of the compiler, but instead spans multiple components within the
|
||||
compiler.
|
||||
|
||||
Attributes
|
||||
|
||||
@ -159,7 +159,7 @@ eliminating this check (``-fsanitize-address-use-after-return=never``).
|
||||
|
||||
To summarize: ``-fsanitize-address-use-after-return=<mode>``
|
||||
* ``never``: Completely disables detection of UAR errors (reduces code size).
|
||||
* ``runtime``: Adds the code for detection, but it can be disable via the
|
||||
* ``runtime``: Adds the code for detection, but it can be disabled via the
|
||||
runtime environment (``ASAN_OPTIONS=detect_stack_use_after_return=0``).
|
||||
* ``always``: Enables detection of UAR errors in all cases. (reduces code
|
||||
size, but not as much as ``never``).
|
||||
@ -239,7 +239,7 @@ from adding redzones around it and detecting out of bounds accesses.
|
||||
|
||||
AddressSanitizer also supports
|
||||
``__attribute__((disable_sanitizer_instrumentation))``. This attribute
|
||||
works similar to ``__attribute__((no_sanitize("address")))``, but it also
|
||||
works similarly to ``__attribute__((no_sanitize("address")))``, but it also
|
||||
prevents instrumentation performed by other sanitizers.
|
||||
|
||||
Suppressing Errors in Recompiled Code (Ignorelist)
|
||||
@ -305,7 +305,7 @@ Limitations
|
||||
===========
|
||||
|
||||
* AddressSanitizer uses more real memory than a native run. Exact overhead
|
||||
depends on the allocations sizes. The smaller the allocations you make the
|
||||
depends on the allocation sizes. The smaller the allocations you make the
|
||||
bigger the overhead is.
|
||||
* AddressSanitizer uses more stack memory. We have seen up to 3x increase.
|
||||
* On 64-bit platforms AddressSanitizer maps (but not reserves) 16+ Terabytes of
|
||||
|
||||
@ -279,7 +279,7 @@ copy. The net effect is that instance variables can be mutated.
|
||||
|
||||
The :block-term:`Block_copy` operator retains all objects held in
|
||||
variables of automatic storage referenced within the Block expression
|
||||
(or form strong references if running under garbage collection).
|
||||
(or forms strong references if running under garbage collection).
|
||||
Object variables of ``__block`` storage type are assumed to hold
|
||||
normal pointers with no provision for retain and release messages.
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ adopt, offering these properties that make it widely adoptable in practice:
|
||||
* It has a relatively low adoption cost.
|
||||
|
||||
This document discusses the key designs of ``-fbounds-safety``. The document is
|
||||
subject to be actively updated with a more detailed specification.
|
||||
subject to active updates with a more detailed specification.
|
||||
|
||||
Programming Model
|
||||
=================
|
||||
@ -574,7 +574,7 @@ When ``sizeof()`` takes a type name, the compiler doesn't apply an implicit
|
||||
bounds annotation on the named pointer types. This means if a bounds annotation
|
||||
is not specified, the evaluated pointer type is treated identically to a plain C
|
||||
pointer type. Therefore, ``sizeof(int*)`` remains the same with or without
|
||||
``-fbounds-safety``. That said, programmers can explicitly add attribute to the
|
||||
``-fbounds-safety``. That said, programmers can explicitly add attributes to the
|
||||
types, e.g., ``sizeof(int *__bidi_indexable)``, in which case the sizeof
|
||||
evaluates to the size of type ``int *__bidi_indexable`` (the value equivalent to
|
||||
``3 * sizeof(int*)``).
|
||||
|
||||
@ -154,7 +154,7 @@ verify its bounds safety. The implementation relies on LLVM optimizations to
|
||||
remove redundant run-time checks. Using this optimization strategy, if the
|
||||
original source code already has bounds checks, the fewer additional checks
|
||||
``-fbounds-safety`` will introduce. The LLVM ``ConstraintElimination`` pass is
|
||||
design to remove provable redundant checks (please check Florian Hahn’s
|
||||
designed to remove provable redundant checks (please check Florian Hahn’s
|
||||
presentation in 2021 LLVM Dev Meeting and the implementation to learn more). In
|
||||
the following example, ``-fbounds-safety`` implicitly adds the redundant bounds
|
||||
checks that the optimizer can remove:
|
||||
|
||||
@ -27,7 +27,7 @@ only for the linker wrapper will be forwarded to the wrapped linker job.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
USAGE: clang-linker-wrapper [options] -- <options to passed to the linker>
|
||||
USAGE: clang-linker-wrapper [options] -- <options to pass to the linker>
|
||||
|
||||
OPTIONS:
|
||||
--cuda-path=<dir> Set the system CUDA path
|
||||
|
||||
@ -10,7 +10,7 @@ Clang nvlink Wrapper
|
||||
Introduction
|
||||
============
|
||||
|
||||
This tools works as a wrapper around the NVIDIA ``nvlink`` linker. The purpose
|
||||
This tool works as a wrapper around the NVIDIA ``nvlink`` linker. The purpose
|
||||
of this wrapper is to provide an interface similar to the ``ld.lld`` linker
|
||||
while still relying on NVIDIA's proprietary linker to produce the final output.
|
||||
|
||||
@ -37,7 +37,7 @@ only for the linker wrapper will be forwarded to ``nvlink``.
|
||||
--arch <value> Specify the 'sm_' name of the target architecture.
|
||||
--cuda-path=<dir> Set the system CUDA path
|
||||
--dry-run Print generated commands without running.
|
||||
--feature <value> Specify the '+ptx' freature to use for LTO.
|
||||
--feature <value> Specify the '+ptx' feature to use for LTO.
|
||||
-g Specify that this was a debug compile.
|
||||
-help-hidden Display all available options
|
||||
-help Display available options (--help-hidden for more)
|
||||
|
||||
@ -150,7 +150,7 @@ passed to the plugin can.
|
||||
-fplugin-arg-call_super_plugin-help \
|
||||
test.cpp
|
||||
|
||||
If your plugin name contains dashes, either rename the plugin or used the
|
||||
If your plugin name contains dashes, either rename the plugin or use the
|
||||
cc1 command line options listed below.
|
||||
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ in a fast, command line interface. It can also accept flags to re-display the
|
||||
diagnostics in different formats with different flags, suitable for use driving
|
||||
an IDE or editor. Furthermore, it can be used in fixit-mode to directly apply
|
||||
fixit-hints offered by clang. See :doc:`HowToSetupToolingForLLVM` for
|
||||
instructions on how to setup and used `clang-check`.
|
||||
instructions on how to setup and use `clang-check`.
|
||||
|
||||
``clang-format``
|
||||
----------------
|
||||
|
||||
@ -140,7 +140,7 @@ pointer goes out of scope, dead blocks are also deallocated.
|
||||
The lifetime of blocks is managed through 3 methods stored in the
|
||||
descriptor of the block:
|
||||
|
||||
* **CtorFn**: initializes the metadata which is store in the block,
|
||||
* **CtorFn**: initializes the metadata which is stored in the block,
|
||||
alongside actual data. Invokes the default constructors of objects
|
||||
which are not trivial (``Pointer``, ``RealFP``, etc.)
|
||||
|
||||
|
||||
@ -135,7 +135,7 @@ Bad Cast Checking
|
||||
This scheme checks that pointer casts are made to an object of the correct
|
||||
dynamic type; that is, the dynamic type of the object must be a derived class
|
||||
of the pointee type of the cast. The checks are currently only introduced
|
||||
where the class being casted to is a polymorphic class.
|
||||
where the class being cast to is a polymorphic class.
|
||||
|
||||
Bad casts are not in themselves control flow integrity violations, but they
|
||||
can also create security vulnerabilities, and the implementation uses many
|
||||
|
||||
@ -243,7 +243,7 @@ labels of just ``v1`` and ``v2``.
|
||||
This signature is the same when origin tracking is disabled - in this case
|
||||
the dfsan_origin passed in it will always be 0.
|
||||
|
||||
The callback will be called when a tained value reach stack/registers
|
||||
The callback will be called when a tainted value reaches stack/registers
|
||||
in the context of a function. Tainted values can reach a function:
|
||||
* via the arguments of the function
|
||||
* via the return value of a call that occurs in the function
|
||||
|
||||
@ -15,7 +15,7 @@ Introduction
|
||||
tags every 8 bytes of the application memory with a 1 byte tag (using *shadow memory*),
|
||||
uses *redzones* to find buffer-overflows and
|
||||
*quarantine* to find use-after-free.
|
||||
The redzones, the quarantine, and, to a less extent, the shadow, are the
|
||||
The redzones, the quarantine, and, to a lesser extent, the shadow, are the
|
||||
sources of AddressSanitizer's memory overhead.
|
||||
See the `AddressSanitizer paper`_ for details.
|
||||
|
||||
|
||||
@ -54,7 +54,7 @@ python bindings also support this (since clang 3.2); see
|
||||
Format
|
||||
======
|
||||
|
||||
A compilation database is a JSON file, which consist of an array of
|
||||
A compilation database is a JSON file, which consists of an array of
|
||||
"command objects", where each command object specifies one way a
|
||||
translation unit is compiled in the project.
|
||||
|
||||
|
||||
@ -35,12 +35,12 @@ Importing one AST node copies that node into the destination ``ASTContext``.
|
||||
Why do we have to copy the node?
|
||||
Isn't enough to insert the pointer to that node into the destination context?
|
||||
One reason is that the "from" context may outlive the "to" context.
|
||||
Also, the Clang AST consider nodes (or certain properties of nodes) equivalent if they have the same address!
|
||||
Also, the Clang AST considers nodes (or certain properties of nodes) equivalent if they have the same address!
|
||||
|
||||
The import algorithm has to ensure that the structurally equivalent nodes in the different translation units are not getting duplicated in the merged AST.
|
||||
E.g. if we include the definition of the vector template (``#include <vector>``) in two translation units, then their merged AST should have only one node which represents the template.
|
||||
Also, we have to discover *one definition rule* (ODR) violations.
|
||||
For instance, if there is a class definition with the same name in both translation units, but one of the definition contains a different number of fields.
|
||||
For instance, if there is a class definition with the same name in both translation units, but one of the definitions contains a different number of fields.
|
||||
So, we look up existing definitions, and then we check the structural equivalency on those nodes.
|
||||
The following pseudo-code demonstrates the basics of the import mechanism:
|
||||
|
||||
|
||||
@ -95,7 +95,7 @@ and flexibility.
|
||||
``VariadicDynCastAllOfMatcher<Base, Derived>``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Those match all nodes of type *Base* if they can be dynamically casted to
|
||||
Those match all nodes of type *Base* if they can be dynamically cast to
|
||||
*Derived*. The names of those matchers are nouns, which closely resemble
|
||||
*Derived*. ``VariadicDynCastAllOfMatchers`` are the backbone of the matcher
|
||||
hierarchy. Most often, your match expression will start with one of them, and
|
||||
|
||||
@ -209,7 +209,7 @@ and traversal matchers to get from one kind of AST node to another. For
|
||||
a complete list of AST matchers, take a look at the `AST Matcher
|
||||
References <LibASTMatchersReference.html>`_
|
||||
|
||||
All matcher that are nouns describe entities in the AST and can be
|
||||
All matchers that are nouns describe entities in the AST and can be
|
||||
bound, so that they can be referred to whenever a match is found. To do
|
||||
so, simply call the method ``bind`` on these matchers, e.g.:
|
||||
|
||||
|
||||
@ -3,7 +3,7 @@ LibFormat
|
||||
=========
|
||||
|
||||
LibFormat is a library that implements automatic source code formatting based
|
||||
on Clang. This documents describes the LibFormat interface and design as well
|
||||
on Clang. This document describes the LibFormat interface and design as well
|
||||
as some basic style discussions.
|
||||
|
||||
If you just want to use `clang-format` as a tool or integrated into an editor,
|
||||
|
||||
@ -53,7 +53,7 @@ type of the *typedef* becomes a matrix type with the given dimensions and an
|
||||
element type of the former underlying type.
|
||||
|
||||
If a declaration of a *typedef-name* has a ``matrix_type`` attribute, then all
|
||||
declaration of that *typedef-name* shall have a matrix_type attribute with the
|
||||
declarations of that *typedef-name* shall have a matrix_type attribute with the
|
||||
same element type, number of rows, and number of columns.
|
||||
|
||||
Standard Conversions
|
||||
|
||||
@ -176,7 +176,7 @@ for `lifetime <https://eel.is/c++draft/basic.life#1>`_ definition.
|
||||
|
||||
This feature can be disabled with either:
|
||||
|
||||
#. Pass addition Clang option ``-fno-sanitize-memory-use-after-dtor`` during
|
||||
#. Pass additional Clang option ``-fno-sanitize-memory-use-after-dtor`` during
|
||||
compilation.
|
||||
#. Set environment variable `MSAN_OPTIONS=poison_in_dtor=0` before running
|
||||
the program.
|
||||
|
||||
@ -115,7 +115,7 @@ Objective-C provides syntax for importing a module via an *@import declaration*,
|
||||
|
||||
@import std;
|
||||
|
||||
The ``@import`` declaration above imports the entire contents of the ``std`` module (which would contain, e.g., the entire C or C++ standard library) and make its API available within the current translation unit. To import only part of a module, one may use dot syntax to specific a particular submodule, e.g.,
|
||||
The ``@import`` declaration above imports the entire contents of the ``std`` module (which would contain, e.g., the entire C or C++ standard library) and make its API available within the current translation unit. To import only part of a module, one may use dot syntax to specify a particular submodule, e.g.,
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user