Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 16 additions & 16 deletions clang/docs/InternalsManual.rst
Original file line number Diff line number Diff line change
Expand Up @@ -312,7 +312,7 @@ Description:
* number: A simple decimal number matches if the argument is the same as the
number. Example: ``"%plural{1:mouse|:mice}0"``
* range: A range in square brackets matches if the argument is within the
range. Then range is inclusive on both ends. Example:
range. The range is inclusive on both ends. Example:
``"%plural{0:none|1:one|[2,5]:some|:many}0"``
* modulo: A modulo operator is followed by a number, and equals sign and
either a number or a range. The tests are the same as for plain numbers
Expand Down Expand Up @@ -341,7 +341,7 @@ Example:
Class:
Integers
Description:
This is a formatter which represents the argument number in a human readable
This is a formatter which represents the argument number in a human-readable
format: the value ``123`` stays ``123``, ``12345`` becomes ``12.34k``,
``6666666` becomes ``6.67M``, and so on for 'G' and 'T'.

Expand Down Expand Up @@ -561,7 +561,7 @@ documentation for the ``-verify`` mode can be found at

There are many other possible implementations of this interface, and this is
why we prefer diagnostics to pass down rich structured information in
arguments. For example, an HTML output might want declaration names be
arguments. For example, an HTML output might want declaration names to be
linkified to where they come from in the source. Another example is that a GUI
might let you click on typedefs to expand them. This application would want to
pass significantly more information about types through to the GUI than a
Expand Down Expand Up @@ -846,7 +846,7 @@ Option Marshalling Infrastructure
The option marshalling infrastructure automates the parsing of the Clang
``-cc1`` frontend command line arguments into ``CompilerInvocation`` and their
generation from ``CompilerInvocation``. The system replaces lots of repetitive
C++ code with simple, declarative tablegen annotations and it's being used for
C++ code with simple, declarative tablegen annotations and is being used for
the majority of the ``-cc1`` command line interface. This section provides an
overview of the system.

Expand Down Expand Up @@ -986,7 +986,7 @@ line.
NegFlag<SetFalse, [], [], "Use the new pass manager in LLVM">,
BothFlags<[], [ClangOption, CC1Option]>>;

With most such pair of flags, the ``-cc1`` frontend accepts only the flag that
With most such pairs of flags, the ``-cc1`` frontend accepts only the flag that
changes the default key path value. The Clang driver is responsible for
accepting both and either forwarding the changing flag or discarding the flag
that would just set the key path to its default.
Expand Down Expand Up @@ -1042,8 +1042,8 @@ and the result is assigned to the key path on success.
The key path defaults to the value specified in ``MarshallingInfoEnum`` prefixed
by the contents of ``NormalizedValuesScope`` and ``::``. This ensures correct
reference to an enum case is formed even if the enum resides in different
namespace or is an enum class. If the value present on command line does not
match any of the comma-separated values from ``Values``, an error diagnostics is
namespace or is an enum class. If the value present on the command line does not
match any of the comma-separated values from ``Values``, an error diagnostic is
issued. Otherwise, the corresponding element from ``NormalizedValues`` at the
same index is assigned to the key path (also correctly scoped). The number of
comma-separated string values and elements of the array within
Expand Down Expand Up @@ -1111,7 +1111,7 @@ The Token class
---------------

The ``Token`` class is used to represent a single lexed token. Tokens are
intended to be used by the lexer/preprocess and parser libraries, but are not
intended to be used by the lexer/preprocessor and parser libraries, but are not
intended to live beyond them (for example, they should not live in the ASTs).

Tokens most often live on the stack (or some other location that is efficient
Expand Down Expand Up @@ -1253,7 +1253,7 @@ In order to do this, whenever the parser expects a ``tok::identifier`` or
``tok::coloncolon``, it should call the ``TryAnnotateTypeOrScopeToken`` or
``TryAnnotateCXXScopeToken`` methods to form the annotation token. These
methods will maximally form the specified annotation tokens and replace the
current token with them, if applicable. If the current tokens is not valid for
current token with them, if applicable. If the current token is not valid for
an annotation token, it will remain an identifier or "``::``" token.

.. _Lexer:
Expand All @@ -1276,7 +1276,7 @@ The lexer has a couple of interesting modal features:
This mode is used for lexing within an "``#if 0``" block, for example.
* The lexer can capture and return comments as tokens. This is required to
support the ``-C`` preprocessor mode, which passes comments through, and is
used by the diagnostic checker to identifier expect-error annotations.
used by the diagnostic checker to identify expect-error annotations.
* The lexer can be in ``ParsingFilename`` mode, which happens when
preprocessing after reading a ``#include`` directive. This mode changes the
parsing of "``<``" to return an "angled string" instead of a bunch of tokens
Expand Down Expand Up @@ -1308,7 +1308,7 @@ The ``TokenLexer`` class
------------------------

The ``TokenLexer`` class is a token provider that returns tokens from a list of
tokens that came from somewhere else. It typically used for two things: 1)
tokens that came from somewhere else. It is typically used for two things: 1)
returning tokens from a macro definition as it is being expanded 2) returning
tokens from an arbitrary buffer of tokens. The later use is used by
``_Pragma`` and will most likely be used to handle unbounded look-ahead for the
Expand Down Expand Up @@ -1509,7 +1509,7 @@ type checker must verify that the operand has a pointer type. It would not be
correct to check that with "``isa<PointerType>(SubExpr->getType())``", because
this predicate would fail if the subexpression had a typedef type.

The solution to this problem are a set of helper methods on ``Type``, used to
The solution to this problem is a set of helper methods on ``Type``, used to
check their properties. In this case, it would be correct to use
"``SubExpr->getType()->isPointerType()``" to do the check. This predicate will
return true if the *canonical type is a pointer*, which is true any time the
Expand Down Expand Up @@ -1632,7 +1632,7 @@ the names are inside the ``DeclarationName`` class).

``CXXLiteralOperatorName``

The name is a C++11 user defined literal operator. User defined
The name is a C++11 user-defined literal operator. User-defined
Literal operators are named according to the suffix they define,
e.g., "``_foo``" for "``operator "" _foo``". Use
``N.getCXXLiteralIdentifier()`` to retrieve the corresponding
Expand Down Expand Up @@ -2215,7 +2215,7 @@ Consequently, we must either set the virtual flag for the definition (but then
we create a malformed AST which the parser would never create), or we import
the whole redeclaration chain of the function. The most recent version of the
``ASTImporter`` uses the latter mechanism. We do import all function
declarations - regardless if they are definitions or prototypes - in the order
declarations - regardless of whether they are definitions or prototypes - in the order
as they appear in the "from" context.

.. One definition
Expand Down Expand Up @@ -2338,7 +2338,7 @@ library receive an Error object, which they must check.
During import of a specific declaration, it may happen that some AST nodes had
already been created before we recognize an error. In this case, we signal back
the error to the caller, but the "to" context remains polluted with those nodes
which had been created. Ideally, those nodes should not had been created, but
which had been created. Ideally, those nodes should not have been created, but
that time we did not know about the error, the error happened later. Since the
AST is immutable (most of the cases we can't remove existing nodes) we choose
to mark these nodes as erroneous.
Expand Down Expand Up @@ -2579,7 +2579,7 @@ that there are global declarations which collide with declarations from other
translation units, but they are not referenced outside from their translation
unit. These declarations should be in an unnamed namespace ideally. If we treat
these collisions liberally then CTU analysis can find more results. Note, the
feature be able to choose between name conflict handling strategies is still an
feature to be able to choose between name conflict handling strategies is still an
ongoing work.

.. _CFG:
Expand Down
Loading