mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2024-11-23 05:40:09 +00:00
[clang] Fix typos in documentation
This commit is contained in:
parent
d9377c1ded
commit
2db0812882
@ -1306,7 +1306,7 @@ or between ARC and non-ARC modes) under the following conditions:
|
||||
|
||||
- The types must be compatible ignoring ownership qualifiers according
|
||||
to the baseline, non-ARC rules (e.g. C struct compatibility or C++'s
|
||||
ODR). This condition implies a pairwise correspondance between
|
||||
ODR). This condition implies a pairwise correspondence between
|
||||
fields.
|
||||
|
||||
Note that an Objective-C++ class with base classes, a user-provided
|
||||
@ -1351,7 +1351,7 @@ automatically by the compiler.
|
||||
.. admonition:: Rationale
|
||||
|
||||
In earlier releases, when non-trivial ownership was only permitted
|
||||
on fields in Objective-C++, the ABI used for such classees was the
|
||||
on fields in Objective-C++, the ABI used for such classes was the
|
||||
ordinary ABI for non-trivial C++ classes, which passes arguments and
|
||||
returns indirectly and does not transfer responsibility for arguments.
|
||||
When support for Objective-C structs was added, it was decided to
|
||||
|
@ -2453,7 +2453,7 @@ the configuration (without a prefix: ``Auto``).
|
||||
* ``BBCDS_Allowed`` (in configuration: ``Allowed``)
|
||||
Breaking between template declaration and ``concept`` is allowed. The
|
||||
actual behavior depends on the content and line breaking rules and
|
||||
penalities.
|
||||
penalties.
|
||||
|
||||
* ``BBCDS_Always`` (in configuration: ``Always``)
|
||||
Always break before ``concept``, putting it in the line after the
|
||||
|
@ -140,7 +140,7 @@ For example:
|
||||
For instrumented functions, the ABI list supports a ``force_zero_labels``
|
||||
category, which will make all stores and return values set zero labels.
|
||||
Functions should never be labelled with both ``force_zero_labels``
|
||||
and ``uninstrumented`` or any of the unistrumented wrapper kinds.
|
||||
and ``uninstrumented`` or any of the uninstrumented wrapper kinds.
|
||||
|
||||
For example:
|
||||
|
||||
|
@ -2613,7 +2613,7 @@ In the format string, a suitable format specifier will be used for builtin
|
||||
types that Clang knows how to format. This includes standard builtin types, as
|
||||
well as aggregate structures, ``void*`` (printed with ``%p``), and ``const
|
||||
char*`` (printed with ``%s``). A ``*%p`` specifier will be used for a field
|
||||
that Clang doesn't know how to format, and the corresopnding argument will be a
|
||||
that Clang doesn't know how to format, and the corresponding argument will be a
|
||||
pointer to the field. This allows a C++ templated formatting function to detect
|
||||
this case and implement custom formatting. A ``*`` will otherwise not precede a
|
||||
format specifier.
|
||||
@ -2963,7 +2963,7 @@ data into the cache before it gets used.
|
||||
**Description**:
|
||||
|
||||
The ``__builtin_prefetch(addr, rw, locality)`` builtin is expected to be used to
|
||||
avoid cache misses when the developper has a good understanding of which data
|
||||
avoid cache misses when the developer has a good understanding of which data
|
||||
are going to be used next. ``addr`` is the address that needs to be brought into
|
||||
the cache. ``rw`` indicates the expected access mode: ``0`` for *read* and ``1``
|
||||
for *write*. In case of *read write* access, ``1`` is to be used. ``locality``
|
||||
@ -3432,7 +3432,7 @@ longer usable unless re-initialized with a call to ``__builtin_va_start`` or
|
||||
|
||||
A builtin function for the target-specific ``va_arg`` function-like macro. This
|
||||
function returns the value of the next variadic argument to the call. It is
|
||||
undefined behavior to call this builtin when there is no next varadic argument
|
||||
undefined behavior to call this builtin when there is no next variadic argument
|
||||
to retrieve or if the next variadic argument does not have a type compatible
|
||||
with the given ``type-name``. The return type of the function is the
|
||||
``type-name`` given as the second argument. It is undefined behavior to call
|
||||
|
@ -106,7 +106,7 @@ C++23 Feature Support
|
||||
Explicitly defaulted functions no longer have to be constexpr-compatible but merely constexpr suitable.
|
||||
We do not support outside of defaulted special memeber functions the change that constexpr functions no
|
||||
longer have to be constexpr compatible but rather support a less restricted requirements for constexpr
|
||||
functions. Which include allowing non-literal types as return values and paremeters, allow calling of
|
||||
functions. Which include allowing non-literal types as return values and parameters, allow calling of
|
||||
non-constexpr functions and constructors.
|
||||
|
||||
Resolutions to C++ Defect Reports
|
||||
@ -181,7 +181,7 @@ Non-comprehensive list of changes in this release
|
||||
- Clang now supports expressions in ``#pragma clang __debug dump``.
|
||||
- Clang now supports declaration of multi-dimensional arrays with
|
||||
``__declspec(property)``.
|
||||
- A new builtin type trait ``__is_trivially_equaltiy_comparable`` has been added,
|
||||
- A new builtin type trait ``__is_trivially_equality_comparable`` has been added,
|
||||
which checks whether comparing two instances of a type is equivalent to
|
||||
``memcmp(&lhs, &rhs, sizeof(T)) == 0``.
|
||||
- Clang now ignores null directives outside of the include guard when deciding
|
||||
@ -253,7 +253,7 @@ Improvements to Clang's diagnostics
|
||||
- Clang now avoids duplicate warnings on unreachable ``[[fallthrough]];`` statements
|
||||
previously issued from ``-Wunreachable-code`` and ``-Wunreachable-code-fallthrough``
|
||||
by prioritizing ``-Wunreachable-code-fallthrough``.
|
||||
- Clang now correctly diagnoses statement attributes ``[[clang::always_inine]]`` and
|
||||
- Clang now correctly diagnoses statement attributes ``[[clang::always_inline]]`` and
|
||||
``[[clang::noinline]]`` when used on a statement with dependent call expressions.
|
||||
- Clang now checks for completeness of the second and third arguments in the
|
||||
conditional operator.
|
||||
@ -315,12 +315,12 @@ Bug Fixes in This Version
|
||||
- Fix crash when using ``[[clang::always_inline]]`` or ``[[clang::noinline]]``
|
||||
statement attributes on a call to a template function in the body of a
|
||||
template function.
|
||||
- Fix coroutines issue where ``get_return_object()`` result was always eargerly
|
||||
- Fix coroutines issue where ``get_return_object()`` result was always eagerly
|
||||
converted to the return type. Eager initialization (allowing RVO) is now only
|
||||
perfomed when these types match, otherwise deferred initialization is used,
|
||||
performed when these types match, otherwise deferred initialization is used,
|
||||
enabling short-circuiting coroutines use cases. This fixes
|
||||
(`#56532 <https://github.com/llvm/llvm-project/issues/56532>`_) in
|
||||
antecipation of `CWG2563 <https://cplusplus.github.io/CWG/issues/2563.html>_`.
|
||||
anticipation of `CWG2563 <https://cplusplus.github.io/CWG/issues/2563.html>_`.
|
||||
- Fix highlighting issue with ``_Complex`` and initialization list with more than
|
||||
2 items. (`#61518 <https://github.com/llvm/llvm-project/issues/61518>`_)
|
||||
- Fix ``getSourceRange`` on ``VarTemplateSpecializationDecl`` and
|
||||
@ -421,7 +421,7 @@ Bug Fixes to C++ Support
|
||||
- Fix incorrect deletion of the default constructor of unions in some
|
||||
cases. (`#48416 <https://github.com/llvm/llvm-project/issues/48416>`_)
|
||||
- No longer issue a pre-C++23 compatibility warning in ``-pedantic`` mode
|
||||
regading overloaded `operator[]` with more than one parmeter or for static
|
||||
regarding overloaded `operator[]` with more than one parameter or for static
|
||||
lambdas. (`#61582 <https://github.com/llvm/llvm-project/issues/61582>`_)
|
||||
- Stop stripping CV qualifiers from the type of ``this`` when capturing it by value in
|
||||
a lambda.
|
||||
@ -602,7 +602,7 @@ libclang
|
||||
|
||||
- Added check in ``clang_getFieldDeclBitWidth`` for whether a bit-field
|
||||
has an evaluable bit width. Fixes undefined behavior when called on a
|
||||
bit-field whose width depends on a template paramter.
|
||||
bit-field whose width depends on a template parameter.
|
||||
|
||||
Static Analyzer
|
||||
---------------
|
||||
|
@ -105,7 +105,7 @@ Built Module Interface file
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
A ``Built Module Interface file`` stands for the precompiled result of an importable module unit.
|
||||
It is also called the acronym ``BMI`` genrally.
|
||||
It is also called the acronym ``BMI`` generally.
|
||||
|
||||
Global module fragment
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -331,7 +331,7 @@ How to specify the dependent BMIs
|
||||
|
||||
There are 3 methods to specify the dependent BMIs:
|
||||
|
||||
* (1) ``-fprebuilt-module-path=<path/to/direcotry>``.
|
||||
* (1) ``-fprebuilt-module-path=<path/to/directory>``.
|
||||
* (2) ``-fmodule-file=<path/to/BMI>`` (Deprecated).
|
||||
* (3) ``-fmodule-file=<module-name>=<path/to/BMI>``.
|
||||
|
||||
@ -351,7 +351,7 @@ for the module specified by ``<module-name>`` when necessary. The main differenc
|
||||
with ``-fprebuilt-module-path``. The option ``-fmodule-file=<path/to/BMI>`` for named modules is deprecated
|
||||
and is planning to be removed in future versions.
|
||||
|
||||
In case all ``-fprebuilt-module-path=<path/to/direcotry>``, ``-fmodule-file=<path/to/BMI>`` and
|
||||
In case all ``-fprebuilt-module-path=<path/to/directory>``, ``-fmodule-file=<path/to/BMI>`` and
|
||||
``-fmodule-file=<module-name>=<path/to/BMI>`` exist, the ``-fmodule-file=<path/to/BMI>`` option
|
||||
takes highest precedence and ``-fmodule-file=<module-name>=<path/to/BMI>`` will take the second
|
||||
highest precedence.
|
||||
@ -366,7 +366,7 @@ the primary module interface unit.
|
||||
A module-declaration that contains neither an export-keyword nor a module-partition implicitly
|
||||
imports the primary module interface unit of the module as if by a module-import-declaration.
|
||||
|
||||
All of the 3 options ``-fprebuilt-module-path=<path/to/direcotry>``, ``-fmodule-file=<path/to/BMI>``
|
||||
All of the 3 options ``-fprebuilt-module-path=<path/to/directory>``, ``-fmodule-file=<path/to/BMI>``
|
||||
and ``-fmodule-file=<module-name>=<path/to/BMI>`` may occur multiple times.
|
||||
For example, the command line to compile ``M.cppm`` in
|
||||
the above example could be rewritten into:
|
||||
@ -791,7 +791,7 @@ Discover Dependencies
|
||||
=====================
|
||||
|
||||
Prior to modules, all the translation units can be compiled parallelly.
|
||||
But it is not true for the module units. The presense of module units requires
|
||||
But it is not true for the module units. The presence of module units requires
|
||||
us to compile the translation units in a (topological) order.
|
||||
|
||||
The clang-scan-deps scanner implemented
|
||||
@ -1011,10 +1011,10 @@ Then clang-scan-deps will extract the necessary information from the options.
|
||||
Note that we need to specify the path to the compiler executable instead of saying
|
||||
``clang++`` simply.
|
||||
|
||||
The users may want the scanner to get the tranditional dependency information for headers.
|
||||
The users may want the scanner to get the transitional dependency information for headers.
|
||||
Otherwise, the users have to scan twice for the project, once for headers and once for modules.
|
||||
To address the requirement, clang-scan-deps will recognize the specified preprocessor options
|
||||
in the given command line and generate the corresponding dependency informaiton. For example,
|
||||
in the given command line and generate the corresponding dependency information. For example,
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -1034,7 +1034,7 @@ We will get:
|
||||
...
|
||||
|
||||
When clang-scan-deps detects ``-MF`` option, clang-scan-deps will try to write the
|
||||
dependency informaiton for headers to the file specified by ``-MF``.
|
||||
dependency information for headers to the file specified by ``-MF``.
|
||||
|
||||
Possible Questions
|
||||
==================
|
||||
|
@ -810,7 +810,7 @@ compilations steps.
|
||||
|
||||
The report file specified in the option is locked for write, so this option
|
||||
can be used to collect statistics in parallel builds. The report file is not
|
||||
cleared, new data is appended to it, thus making posible to accumulate build
|
||||
cleared, new data is appended to it, thus making possible to accumulate build
|
||||
statistics.
|
||||
|
||||
You can also use environment variables to control the process statistics reporting.
|
||||
@ -3954,7 +3954,7 @@ mapping of default visibility to an explicit shared object export
|
||||
* ``-mdefault-visibility-export-mapping=none``: no additional export
|
||||
information is created for entities with default visibility.
|
||||
* ``-mdefault-visibility-export-mapping=explicit``: mark entities for export
|
||||
if they have explict (e.g. via an attribute) default visibility from the
|
||||
if they have explicit (e.g. via an attribute) default visibility from the
|
||||
source, including RTTI.
|
||||
* ``-mdefault-visibility-export-mapping=all``: set XCOFF exported visibility
|
||||
for all entities with default visibility from any source. This gives a
|
||||
|
@ -2317,7 +2317,7 @@ Corresponds to SEI CERT Rules ENV31-C and ENV34-C.
|
||||
|
||||
ENV31-C:
|
||||
Rule is about the possible problem with `main` function's third argument, environment pointer,
|
||||
"envp". When enviornment array is modified using some modification function
|
||||
"envp". When environment array is modified using some modification function
|
||||
such as putenv, setenv or others, It may happen that memory is reallocated,
|
||||
however "envp" is not updated to reflect the changes and points to old memory
|
||||
region.
|
||||
|
@ -1480,7 +1480,7 @@ code. This issue is expected to be rectified soon.
|
||||
<details><summary>Clang 17 (Partial)</summary>
|
||||
We do not support outside of defaulted special memeber functions the change that constexpr functions no
|
||||
longer have to be constexpr compatible but rather support a less restricted requirements for constexpr
|
||||
functions. Which include allowing non-literal types as return values and paremeters, allow calling of
|
||||
functions. Which include allowing non-literal types as return values and parameters, allow calling of
|
||||
non-constexpr functions and constructors.
|
||||
</details></td>
|
||||
</td>
|
||||
|
Loading…
Reference in New Issue
Block a user