[llvm] e8fa901 - [llvm] Fix typos in documentation (NFC)
Kazu Hirata via llvm-commits
llvm-commits at lists.llvm.org
Sat Feb 27 10:09:51 PST 2021
Author: Kazu Hirata
Date: 2021-02-27T10:09:23-08:00
New Revision: e8fa9014cce41e1057e295b035dda73420612686
URL: https://github.com/llvm/llvm-project/commit/e8fa9014cce41e1057e295b035dda73420612686
DIFF: https://github.com/llvm/llvm-project/commit/e8fa9014cce41e1057e295b035dda73420612686.diff
LOG: [llvm] Fix typos in documentation (NFC)
Added:
Modified:
llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
llvm/docs/AMDGPUModifierSyntax.rst
llvm/docs/AMDGPUUsage.rst
llvm/docs/BitCodeFormat.rst
llvm/docs/CommandGuide/llvm-install-name-tool.rst
llvm/docs/CommandGuide/tblgen.rst
llvm/docs/CommandLine.rst
llvm/docs/Coroutines.rst
llvm/docs/Frontend/PerformanceTips.rst
llvm/docs/JITLink.rst
llvm/docs/LangRef.rst
llvm/docs/Lexicon.rst
llvm/docs/MIRLangRef.rst
llvm/docs/MemorySSA.rst
llvm/docs/MergeFunctions.rst
llvm/docs/ORCv2.rst
llvm/docs/Passes.rst
llvm/docs/ProgrammersManual.rst
llvm/docs/StackMaps.rst
llvm/docs/Statepoints.rst
llvm/docs/TableGen/ProgRef.rst
llvm/docs/XRay.rst
llvm/docs/YamlIO.rst
llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
Removed:
################################################################################
diff --git a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
index 9ac9ea0c1d5d..0d57674e70a0 100644
--- a/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
+++ b/llvm/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.rst
@@ -500,7 +500,7 @@ If a DWARF expression is ill-formed, then the result is undefined.
The following sections detail the rules for when a DWARF expression is
ill-formed or results in an evaluation error.
-A DWARF expression can either be encoded as a operation expression (see
+A DWARF expression can either be encoded as an operation expression (see
:ref:`amdgpu-dwarf-operation-expressions`), or as a location list expression
(see :ref:`amdgpu-dwarf-location-list-expressions`).
diff --git a/llvm/docs/AMDGPUModifierSyntax.rst b/llvm/docs/AMDGPUModifierSyntax.rst
index 7851a3efce97..d6a387908ef0 100644
--- a/llvm/docs/AMDGPUModifierSyntax.rst
+++ b/llvm/docs/AMDGPUModifierSyntax.rst
@@ -422,7 +422,7 @@ GFX7, GFX8 and GFX10 only.
r128 Specifies 128 bits texture resource size.
=================== ================================================
-.. WARNING:: Using this modifier should descrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature.
+.. WARNING:: Using this modifier should decrease *rsrc* operand size from 8 to 4 dwords, but assembler does not currently support this feature.
tfe
~~~
@@ -831,7 +831,7 @@ GFX10 only.
Unified format is a replacement for :ref:`data<amdgpu_synid_format_data>`
and :ref:`numeric<amdgpu_synid_format_num>` formats. For compatibility with older ISA,
-:ref:`syntax with data and numeric formats<amdgpu_synid_fmt>` is still accepthed
+:ref:`syntax with data and numeric formats<amdgpu_synid_fmt>` is still accepted
provided that the combination of formats can be mapped to a unified format.
Supported unified formats and equivalent combinations of data and numeric formats
diff --git a/llvm/docs/AMDGPUUsage.rst b/llvm/docs/AMDGPUUsage.rst
index b496c30e4fcd..5177ccea64ae 100644
--- a/llvm/docs/AMDGPUUsage.rst
+++ b/llvm/docs/AMDGPUUsage.rst
@@ -528,7 +528,7 @@ AMDGPU supports target IDs. See `Clang Offload Bundler
description. The AMDGPU target specific information is:
**processor**
- Is a AMDGPU processor or alternative processor name specified in
+ Is an AMDGPU processor or alternative processor name specified in
:ref:`amdgpu-processor-table`. The non-canonical form target ID allows both
the primary processor and alternative processor names. The canonical form
target ID only allow the primary processor name.
@@ -4580,7 +4580,7 @@ There are
diff erent methods used for initializing flat scratch:
Private Segment Buffer
++++++++++++++++++++++
-Private Segment Buffer SGPR register is used to initilize 4 SGPRs
+Private Segment Buffer SGPR register is used to initialize 4 SGPRs
that are used as a V# to access scratch. CP uses the value provided by the
runtime. It is used, together with Scratch Wavefront Offset as an offset, to
access the private memory space using a segment address. See
@@ -6042,7 +6042,7 @@ For GFX90A:
wavefront.
* No special action is required for coherence between wavefronts in the same
- work-group since they exeute on the same CU. The exception is when in
+ work-group since they execute on the same CU. The exception is when in
tgsplit execution mode as wavefronts of the same work-group can be in
diff erent CUs and so a ``buffer_wbinvl1_vol`` is required as described in
the following item.
diff --git a/llvm/docs/BitCodeFormat.rst b/llvm/docs/BitCodeFormat.rst
index cf2c6113e85d..df0e195c6809 100644
--- a/llvm/docs/BitCodeFormat.rst
+++ b/llvm/docs/BitCodeFormat.rst
@@ -264,7 +264,7 @@ Abbreviated Record Encoding
``[<abbrevid>, fields...]``
-An abbreviated record is a abbreviation id followed by a set of fields that are
+An abbreviated record is an abbreviation id followed by a set of fields that are
encoded according to the `abbreviation definition`_. This allows records to be
encoded significantly more densely than records encoded with the
`UNABBREV_RECORD`_ type, and allows the abbreviation types to be specified in
diff --git a/llvm/docs/CommandGuide/llvm-install-name-tool.rst b/llvm/docs/CommandGuide/llvm-install-name-tool.rst
index 33eb998ab655..9309215cd6ab 100644
--- a/llvm/docs/CommandGuide/llvm-install-name-tool.rst
+++ b/llvm/docs/CommandGuide/llvm-install-name-tool.rst
@@ -35,7 +35,7 @@ the same `<rpath>` value.
Change an install name ``<old_install_name>`` to ``<new_install_name>`` in the
specified binary. Can be specified multiple times to change multiple dependent shared
library install names. Option is ignored if ``<old_install_name>`` is not listed
- in the specfied binary.
+ in the specified binary.
.. option:: -delete_rpath <rpath>
@@ -54,7 +54,7 @@ the same `<rpath>` value.
.. option:: -id <name>
Change shared library's identification name under LC_ID_DYLIB to ``<name>`` in the
- specfied binary. If specified multiple times, only the last :option:`-id` option is
+ specified binary. If specified multiple times, only the last :option:`-id` option is
selected. Option is ignored if the specified Mach-O binary is not a dynamic shared library.
.. option:: -rpath <old_rpath> <new_rpath>
diff --git a/llvm/docs/CommandGuide/tblgen.rst b/llvm/docs/CommandGuide/tblgen.rst
index 530649646828..042d64953cfe 100644
--- a/llvm/docs/CommandGuide/tblgen.rst
+++ b/llvm/docs/CommandGuide/tblgen.rst
@@ -126,7 +126,7 @@ llvm-tblgen Options
.. option:: -gen-attrs
- Geneerate attributes.
+ Generate attributes.
.. option:: -gen-automata
@@ -218,7 +218,7 @@ llvm-tblgen Options
.. option:: -gicombiner-show-expansions
- Make -gen-global-isel-combiner use C++ comments to indicate occurences
+ Make -gen-global-isel-combiner use C++ comments to indicate occurrences
of code expansion.
.. option:: -gicombiner-stop-after-build
diff --git a/llvm/docs/CommandLine.rst b/llvm/docs/CommandLine.rst
index c67e73373ebd..e549d49bd90f 100644
--- a/llvm/docs/CommandLine.rst
+++ b/llvm/docs/CommandLine.rst
@@ -387,7 +387,7 @@ now is:
-quiet - Don't print informational messages
In this case, it is sort of awkward that flag names correspond directly to enum
-names, because we probably don't want a enum definition named "``g``" in our
+names, because we probably don't want an enum definition named "``g``" in our
program. Because of this, we can alternatively write this example like this:
.. code-block:: c++
diff --git a/llvm/docs/Coroutines.rst b/llvm/docs/Coroutines.rst
index 268e9c79ac8f..72ef3f897e52 100644
--- a/llvm/docs/Coroutines.rst
+++ b/llvm/docs/Coroutines.rst
@@ -190,7 +190,7 @@ coroutine. Therefore an async coroutine returns `void`.
define swiftcc void @async_coroutine(i8* %async.ctxt, i8*, i8*) {
}
-Values live accross a suspend point need to be stored in the coroutine frame to
+Values live across a suspend point need to be stored in the coroutine frame to
be available in the continuation function. This frame is stored as a tail to the
`async context`.
@@ -1206,7 +1206,7 @@ The third argument is the `async context` argument in the current coroutine.
The fourth argument is the address of the `async function pointer` struct.
Lowering will update the context size requirement in this struct by adding the
coroutine frame size requirement to the initial size requirement as specified by
-the first argument of this intrinisc.
+the first argument of this intrinsic.
Semantics:
@@ -1572,7 +1572,7 @@ The second argument is the `context projection function`. It should describe
how-to restore the `async context` in the continuation function from the first
argument of the continuation function. Its type is `i8* (i8*)`.
-The third argument is the function that models tranfer to the callee at the
+The third argument is the function that models transfer to the callee at the
suspend point. It should take 3 arguments. Lowering will `musttail` call this
function.
diff --git a/llvm/docs/Frontend/PerformanceTips.rst b/llvm/docs/Frontend/PerformanceTips.rst
index f9e23fdbf885..5889329e25fc 100644
--- a/llvm/docs/Frontend/PerformanceTips.rst
+++ b/llvm/docs/Frontend/PerformanceTips.rst
@@ -81,7 +81,7 @@ Prefer zext over sext when legal
On some architectures (X86_64 is one), sign extension can involve an extra
instruction whereas zero extension can be folded into a load. LLVM will try to
replace a sext with a zext when it can be proven safe, but if you have
-information in your source language about the range of a integer value, it can
+information in your source language about the range of an integer value, it can
be profitable to use a zext rather than a sext.
Alternatively, you can :ref:`specify the range of the value using metadata
diff --git a/llvm/docs/JITLink.rst b/llvm/docs/JITLink.rst
index e19471834950..3b808cec6b27 100644
--- a/llvm/docs/JITLink.rst
+++ b/llvm/docs/JITLink.rst
@@ -16,7 +16,7 @@ accessible. If it is not, please submit a patch (:doc:`Contributing`) or file a
bug (:doc:`HowToSubmitABug`).
JITLink is a library for :ref:`jit_linking`. It was built to support the ORC JIT
-APIs and is most commonly accesed via ORC's ObjectLinkingLayer API. JITLink was
+APIs and is most commonly accessed via ORC's ObjectLinkingLayer API. JITLink was
developed with the aim of supporting the full set of features provided by each
object format; including static initializers, exception handling, thread local
variables, and language runtime registration. Supporting these features enables
@@ -520,7 +520,7 @@ certain points by the introduction of JITLink :ref:`passes`:
working memory and fixed up. Passes run at this stage can make late
optimizations to the graph and content based on address layout.
- Notable use cases: GOT and PLT relaxation, where GOT and PLT acceses are
+ Notable use cases: GOT and PLT relaxation, where GOT and PLT accesses are
bypassed for fixup targets that are directly accessible under the assigned
memory layout.
@@ -787,7 +787,7 @@ for them by an ``ObjectLinkingLayer`` instance, but they can be created manually
``ObjectLinkingLayer`` usually creates ``LinkGraphs``.
#. ``createLinkGraph_<Object-Format>_<Architecture>`` can be used when
- both the object format and achitecture are known ahead of time.
+ both the object format and architecture are known ahead of time.
#. ``createLinkGraph_<Object-Format>`` can be used when the object format is
known ahead of time, but the architecture is not. In this case the
@@ -894,7 +894,7 @@ main function using the -args option:
printf("arg %i is \"%s\"\n", i, argv[i]);
}
- % cat pring-args-main.c
+ % cat print-args-main.c
void print_args(int argc, char *argv[]);
int main(int argc, char *argv[]) {
@@ -1093,7 +1093,7 @@ Major outstanding projects include:
JITLink Availability and Feature Status
---------------------------------------
-.. list-table:: Avalability and Status
+.. list-table:: Availability and Status
:widths: 10 30 30 30
:header-rows: 1
diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index 46eab12cb4d1..76a75145f6a0 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -4329,7 +4329,7 @@ ARM and ARM's Thumb2 mode:
- ``L``: An immediate integer whose negation is valid for a data-processing
instruction. (Can be used with template modifier "``n``" to print the negated
value).
-- ``M``: A power of two or a integer between 0 and 32.
+- ``M``: A power of two or an integer between 0 and 32.
- ``N``: Invalid immediate constraint.
- ``O``: Invalid immediate constraint.
- ``r``: A general-purpose 32-bit integer register (``r0-r15``).
@@ -4723,7 +4723,7 @@ debug information. There are two metadata primitives: strings and nodes.
Metadata does not have a type, and is not a value. If referenced from a
``call`` instruction, it uses the ``metadata`` type.
-All metadata are identified in syntax by a exclamation point ('``!``').
+All metadata are identified in syntax by an exclamation point ('``!``').
.. _metadata-string:
@@ -12000,7 +12000,7 @@ arrays in C99.
Semantics:
""""""""""
-This intrinsic returns a opaque pointer value that can be passed to
+This intrinsic returns an opaque pointer value that can be passed to
:ref:`llvm.stackrestore <int_stackrestore>`. When an
``llvm.stackrestore`` intrinsic is executed with a value saved from
``llvm.stacksave``, it effectively restores the state of the stack to
@@ -12053,7 +12053,7 @@ Overview:
The '``llvm.get.dynamic.area.offset.*``' intrinsic family is used to
get the offset from native stack pointer to the address of the most
recent dynamic alloca on the caller's stack. These intrinsics are
- intendend for use in combination with
+ intended for use in combination with
:ref:`llvm.stacksave <int_stacksave>` to get a
pointer to the most recent dynamic alloca. This is useful, for example,
for AddressSanitizer's stack unpoisoning routines.
@@ -12170,7 +12170,7 @@ Semantics:
""""""""""
When directly supported, reading the cycle counter should not modify any
-memory. Implementations are allowed to either return a application
+memory. Implementations are allowed to either return an application
specific value or a system wide value. On backends without support, this
is lowered to a constant 0.
diff --git a/llvm/docs/Lexicon.rst b/llvm/docs/Lexicon.rst
index 03090827ffe4..761aa4b8b3d9 100644
--- a/llvm/docs/Lexicon.rst
+++ b/llvm/docs/Lexicon.rst
@@ -98,7 +98,7 @@ E
**ento**
This namespace houses the
`Clang Static Analyzer <https://clang.llvm.org/docs/ClangStaticAnalyzer.html>`_.
- It is an abbreviaton of `entomology <https://en.wikipedia.org/wiki/Entomology>`_.
+ It is an abbreviation of `entomology <https://en.wikipedia.org/wiki/Entomology>`_.
*"Entomology is the scientific study of insects."*
diff --git a/llvm/docs/MIRLangRef.rst b/llvm/docs/MIRLangRef.rst
index ba6bdcbbed90..6398fd7f6b75 100644
--- a/llvm/docs/MIRLangRef.rst
+++ b/llvm/docs/MIRLangRef.rst
@@ -834,7 +834,7 @@ represented by an empty ``DebugLoc`` object in the machine instruction.
Fixed variable locations
^^^^^^^^^^^^^^^^^^^^^^^^
-There are several ways of specifying variable locations. The simpliest is
+There are several ways of specifying variable locations. The simplest is
describing a variable that is permanently located on the stack. In the stack
or fixedStack attribute of the machine function, the variable, scope, and
any qualifying location modifier are provided:
diff --git a/llvm/docs/MemorySSA.rst b/llvm/docs/MemorySSA.rst
index 224b57d54255..b5c2bad97557 100644
--- a/llvm/docs/MemorySSA.rst
+++ b/llvm/docs/MemorySSA.rst
@@ -176,7 +176,7 @@ Going from the top down:
this block could either be ``2`` or ``3``.
- ``MemoryUse(5)`` notes that ``load i8, i8* %p1`` is a use of memory, and that
it's clobbered by ``5``.
-- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; it's
+- ``4 = MemoryDef(5)`` notes that ``store i8 2, i8* %p2`` is a definition; its
reaching definition is ``5``.
- ``MemoryUse(1)`` notes that ``load i8, i8* %p3`` is just a user of memory,
and the last thing that could clobber this use is above ``while.cond`` (e.g.
@@ -233,7 +233,7 @@ queries ``GlobalsAA``, one that always stops at ``MemoryPhi`` nodes, etc).
Default walker APIs
^^^^^^^^^^^^^^^^^^^
-There are two main APIs used to retrive the clobbering access using the walker:
+There are two main APIs used to retrieve the clobbering access using the walker:
- ``MemoryAccess *getClobberingMemoryAccess(MemoryAccess *MA);`` return the
clobbering memory access for ``MA``, caching all intermediate results
diff --git a/llvm/docs/MergeFunctions.rst b/llvm/docs/MergeFunctions.rst
index 13294129538c..02344bca6f45 100644
--- a/llvm/docs/MergeFunctions.rst
+++ b/llvm/docs/MergeFunctions.rst
@@ -134,7 +134,7 @@ How it could this be done? Just convert each function to a number, and gather
all of them in a special hash-table. Functions with equal hashes are equal.
Good hashing means, that every function part must be taken into account. That
means we have to convert every function part into some number, and then add it
-into the hash. The lookup-up time would be small, but such a approach adds some
+into the hash. The lookup-up time would be small, but such an approach adds some
delay due to the hashing routine.
Logarithmical search
diff --git a/llvm/docs/ORCv2.rst b/llvm/docs/ORCv2.rst
index 06f743d1139d..4c3974bec144 100644
--- a/llvm/docs/ORCv2.rst
+++ b/llvm/docs/ORCv2.rst
@@ -829,7 +829,7 @@ Further Future Work
*speculative* JIT compilation: compilation of code that is not needed yet,
but which we have reason to believe will be needed in the future. This can be
used to hide compile latency and improve JIT throughput. A proof-of-concept
- exmaple of speculative compilation with ORC has already been developed (see
+ example of speculative compilation with ORC has already been developed (see
``llvm/examples/SpeculativeJIT``). Future work on this is likely to focus on
re-using and improving existing profiling support (currently used by PGO) to
feed speculation decisions, as well as built-in tools to simplify use of
diff --git a/llvm/docs/Passes.rst b/llvm/docs/Passes.rst
index d146ce745282..869408fbdf32 100644
--- a/llvm/docs/Passes.rst
+++ b/llvm/docs/Passes.rst
@@ -336,7 +336,7 @@ graph at only two spots. Furthermore, a hierarchical region tree is built.
``-scalar-evolution``: Scalar Evolution Analysis
------------------------------------------------
-The ``ScalarEvolution`` analysis can be used to analyze and catagorize scalar
+The ``ScalarEvolution`` analysis can be used to analyze and categorize scalar
expressions in loops. It specializes in recognizing general induction
variables, representing them with the abstract and opaque ``SCEV`` class.
Given this analysis, trip counts of loops and other important properties can be
@@ -1114,7 +1114,7 @@ algorithm:
return returns something else (like constant 0), and can still be TRE'd. It
can be TRE'd if *all other* return instructions in the function return the
exact same value.
-#. If it can prove that callees do not access theier caller stack frame, they
+#. If it can prove that callees do not access their caller stack frame, they
are marked as eligible for tail call elimination (by the code generator).
Utility Passes
diff --git a/llvm/docs/ProgrammersManual.rst b/llvm/docs/ProgrammersManual.rst
index 7713a353ae1d..c10629d19e50 100644
--- a/llvm/docs/ProgrammersManual.rst
+++ b/llvm/docs/ProgrammersManual.rst
@@ -2468,7 +2468,7 @@ Basic Inspection and Traversal Routines
The LLVM compiler infrastructure have many
diff erent data structures that may be
traversed. Following the example of the C++ standard template library, the
techniques used to traverse these various data structures are all basically the
-same. For a enumerable sequence of values, the ``XXXbegin()`` function (or
+same. For an enumerable sequence of values, the ``XXXbegin()`` function (or
method) returns an iterator to the start of the sequence, the ``XXXend()``
function returns an iterator pointing to one past the last valid element of the
sequence, and there is some ``XXXiterator`` data type that is common between the
diff --git a/llvm/docs/StackMaps.rst b/llvm/docs/StackMaps.rst
index 7c9cead3647d..1501ddd85876 100644
--- a/llvm/docs/StackMaps.rst
+++ b/llvm/docs/StackMaps.rst
@@ -24,7 +24,7 @@ containing the stack map.
LLVM emits stack map data into the object code within a designated
:ref:`stackmap-section`. This stack map data contains a record for
each stack map. The record stores the stack map's instruction address
-and contains a entry for each mapped value. Each entry encodes a
+and contains an entry for each mapped value. Each entry encodes a
value's location as a register, stack offset, or constant.
A patch point is an instruction address at which space is reserved for
diff --git a/llvm/docs/Statepoints.rst b/llvm/docs/Statepoints.rst
index 7a4337201e1f..8141e2eb8cc0 100644
--- a/llvm/docs/Statepoints.rst
+++ b/llvm/docs/Statepoints.rst
@@ -393,7 +393,7 @@ to unmanaged code. The resulting relocation sequence is:
ret i8 addrspace(1)* %obj.relocated
}
-During lowering, this will result in a instruction selection DAG that looks
+During lowering, this will result in an instruction selection DAG that looks
something like:
::
@@ -703,7 +703,7 @@ Safepoint Semantics & Verification
The fundamental correctness property for the compiled code's
correctness w.r.t. the garbage collector is a dynamic one. It must be
-the case that there is no dynamic trace such that a operation
+the case that there is no dynamic trace such that an operation
involving a potentially relocated pointer is observably-after a
safepoint which could relocate it. 'observably-after' is this usage
means that an outside observer could observe this sequence of events
diff --git a/llvm/docs/TableGen/ProgRef.rst b/llvm/docs/TableGen/ProgRef.rst
index f5a7760b2885..c60bffef3ed2 100644
--- a/llvm/docs/TableGen/ProgRef.rst
+++ b/llvm/docs/TableGen/ProgRef.rst
@@ -509,7 +509,7 @@ primary value. Here are the possible suffixes for some primary *value*.
The paste operator
------------------
-The paste operator (``#``) is the only infix operator availabe in TableGen
+The paste operator (``#``) is the only infix operator available in TableGen
expressions. It allows you to concatenate strings or lists, but has a few
unusual features.
diff --git a/llvm/docs/XRay.rst b/llvm/docs/XRay.rst
index 72768fa8410a..969f7ee2c2a3 100644
--- a/llvm/docs/XRay.rst
+++ b/llvm/docs/XRay.rst
@@ -316,7 +316,7 @@ Minimizing Binary Size
XRay supports several
diff erent instrumentation points including ``function-entry``,
``function-exit``, ``custom``, and ``typed`` points. These can be enabled individually
-using the ``-fxray-instrumentaton-bundle=`` flag. For example if you only wanted to
+using the ``-fxray-instrumentation-bundle=`` flag. For example if you only wanted to
instrument function entry and custom points you could specify:
::
diff --git a/llvm/docs/YamlIO.rst b/llvm/docs/YamlIO.rst
index 9dbb2b2766f9..68bc0e4c51f4 100644
--- a/llvm/docs/YamlIO.rst
+++ b/llvm/docs/YamlIO.rst
@@ -288,7 +288,7 @@ ScalarEnumerationTraits
-----------------------
YAML I/O supports translating between in-memory enumerations and a set of string
values in YAML documents. This is done by specializing ScalarEnumerationTraits<>
-on your enumeration type and define a enumeration() method.
+on your enumeration type and define an enumeration() method.
For instance, suppose you had an enumeration of CPUs and a struct with it as
a field:
@@ -391,7 +391,7 @@ on MyFlags and provide the bit values and their names.
With the above, YAML I/O (when writing) will test mask each value in the
bitset trait against the flags field, and each that matches will
cause the corresponding string to be added to the flow sequence. The opposite
-is done when reading and any unknown string values will result in a error. With
+is done when reading and any unknown string values will result in an error. With
the above schema, a same valid YAML document is:
.. code-block:: yaml
@@ -439,7 +439,7 @@ to the flow sequence.
Custom Scalar
-------------
Sometimes for readability a scalar needs to be formatted in a custom way. For
-instance your internal data structure may use a integer for time (seconds since
+instance your internal data structure may use an integer for time (seconds since
some epoch), but in YAML it would be much nicer to express that integer in
some time format (e.g. 4-May-2012 10:30pm). YAML I/O has a way to support
custom formatting and parsing of scalar types by specializing ScalarTraits<> on
diff --git a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
index dd7d54778982..d575e0a5cfc6 100644
--- a/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
+++ b/llvm/docs/tutorial/MyFirstLanguageFrontend/LangImpl10.rst
@@ -30,7 +30,7 @@ need not be a scary or mystical process! Now that you've seen some of
the basics, I strongly encourage you to take the code and hack on it.
For example, try adding:
-- **global variables** - While global variables have questional value
+- **global variables** - While global variables have questionable value
in modern software engineering, they are often useful when putting
together quick little hacks like the Kaleidoscope compiler itself.
Fortunately, our current setup makes it very easy to add global
More information about the llvm-commits
mailing list