Fix trailing whitespace.
llvm-svn: 200182
diff --git a/lld/docs/C++11.rst b/lld/docs/C++11.rst
index 6eca731..9128fd6 100644
--- a/lld/docs/C++11.rst
+++ b/lld/docs/C++11.rst
@@ -21,7 +21,7 @@
* Forward enum declarations
* Lambdas
* Local and unnamed types as template args
-* Trailing return type
+* Trailing return type
* nullptr
* >> instead of > >
* R-Value references excluding R-Value references for this
diff --git a/lld/docs/Driver.rst b/lld/docs/Driver.rst
index 49010ee..5f2d946 100644
--- a/lld/docs/Driver.rst
+++ b/lld/docs/Driver.rst
@@ -23,7 +23,7 @@
-------
Each of these different interfaces is referred to as a flavor. There is also an
-extra flavor "core" which is used to exercise the core functionality of the
+extra flavor "core" which is used to exercise the core functionality of the
linker it the test suite.
* gnu
@@ -51,7 +51,7 @@
#. Add to :cpp:class:`lld::FlavorLinkingContext` a getter and setter method
for the option.
-
+
#. Modify :cpp:func:`lld::FlavorDriver::parse` in :file:
`lib/Driver/{Flavor}Driver.cpp` to call the targetInfo setter
for corresponding to the option.
@@ -66,7 +66,7 @@
:cpp:class:`lld::UniversalDriver::Flavor`.
#. Add an entry in :file:`lib/Driver/UniversalDriver.cpp` to
- :cpp:func:`lld::Driver::strToFlavor` and
+ :cpp:func:`lld::Driver::strToFlavor` and
:cpp:func:`lld::UniversalDriver::link`.
This allows the flavor to be selected via symlink and :option:`-flavor`.
@@ -76,4 +76,4 @@
must also be added to :file:`lib/Driver/CMakeLists.txt`.
#. Add a ``{flavor}Driver`` as a subclass of :cpp:class:`lld::Driver`
- in :file:`lib/Driver/{flavor}Driver.cpp`.
+ in :file:`lib/Driver/{flavor}Driver.cpp`.
diff --git a/lld/docs/Readers.rst b/lld/docs/Readers.rst
index ddda473..6ad58e0 100644
--- a/lld/docs/Readers.rst
+++ b/lld/docs/Readers.rst
@@ -20,7 +20,7 @@
.. cpp:class:: ReaderOptionsFoo : public ReaderOptions
- This Options class is the only way to configure how the Reader will
+ This Options class is the only way to configure how the Reader will
parse any file into an `lld::Reader`:cpp:class: object. This class
should be declared in the `lld`:cpp:class: namespace.
diff --git a/lld/docs/design.rst b/lld/docs/design.rst
index 2a79bd0..21ebcbf 100644
--- a/lld/docs/design.rst
+++ b/lld/docs/design.rst
@@ -46,20 +46,20 @@
* DefinedAtom
95% of all atoms. This is a chunk of code or data
-
- * UndefinedAtom
+
+ * UndefinedAtom
This is a place holder in object files for a reference to some atom
outside the translation unit.During core linking it is usually replaced
by (coalesced into) another Atom.
-
+
* SharedLibraryAtom
- If a required symbol name turns out to be defined in a dynamic shared
- library (and not some object file). A SharedLibraryAtom is the
+ If a required symbol name turns out to be defined in a dynamic shared
+ library (and not some object file). A SharedLibraryAtom is the
placeholder Atom used to represent that fact.
-
- It is similar to an UndefinedAtom, but it also tracks information
+
+ It is similar to an UndefinedAtom, but it also tracks information
about the associated shared library.
-
+
* AbsoluteAtom
This is for embedded support where some stuff is implemented in ROM at
some fixed address. This atom has no content. It is just an address
@@ -112,7 +112,7 @@
Linking Steps
-------------
-Through the use of abstract Atoms, the core of linking is architecture
+Through the use of abstract Atoms, the core of linking is architecture
independent and file format independent. All command line parsing is factored
out into a separate "options" abstraction which enables the linker to be driven
with different command line sets.
@@ -136,27 +136,27 @@
Input Files
~~~~~~~~~~~
-Existing developer tools using different file formats for object files.
+Existing developer tools using different file formats for object files.
A goal of lld is to be file format independent. This is done
through a plug-in model for reading object files. The lld::Reader is the base
class for all object file readers. A Reader follows the factory method pattern.
A Reader instantiates an lld::File object (which is a graph of Atoms) from a
given object file (on disk or in-memory).
-Every Reader subclass defines its own "options" class (for instance the mach-o
-Reader defines the class ReaderOptionsMachO). This options class is the
+Every Reader subclass defines its own "options" class (for instance the mach-o
+Reader defines the class ReaderOptionsMachO). This options class is the
one-and-only way to control how the Reader operates when parsing an input file
into an Atom graph. For instance, you may want the Reader to only accept
certain architectures. The options class can be instantiated from command
-line options, or it can be subclassed and the ivars programmatically set.
+line options, or it can be subclassed and the ivars programmatically set.
Resolving
~~~~~~~~~
-The resolving step takes all the atoms' graphs from each object file and
-combines them into one master object graph. Unfortunately, it is not as simple
-as appending the atom list from each file into one big list. There are many
+The resolving step takes all the atoms' graphs from each object file and
+combines them into one master object graph. Unfortunately, it is not as simple
+as appending the atom list from each file into one big list. There are many
cases where atoms need to be coalesced. That is, two or more atoms need to be
coalesced into one atom. This is necessary to support: C language "tentative
definitions", C++ weak symbols for templates and inlines defined in headers,
@@ -241,30 +241,30 @@
place the content of the atoms into it.
lld uses a plug-in model for writing output files. All concrete writers (e.g.
-ELF, mach-o, etc) are subclasses of the lld::Writer class.
+ELF, mach-o, etc) are subclasses of the lld::Writer class.
Unlike the Reader class which has just one method to instantiate an lld::File,
-the Writer class has multiple methods. The crucial method is to generate the
+the Writer class has multiple methods. The crucial method is to generate the
output file, but there are also methods which allow the Writer to contribute
-Atoms to the resolver and specify passes to run.
+Atoms to the resolver and specify passes to run.
An example of contributing
atoms is that if the Writer knows a main executable is being linked and such
an executable requires a specially named entry point (e.g. "_main"), the Writer
-can add an UndefinedAtom with that special name to the resolver. This will
-cause the resolver to issue an error if that symbol is not defined.
+can add an UndefinedAtom with that special name to the resolver. This will
+cause the resolver to issue an error if that symbol is not defined.
Sometimes a Writer supports lazily created symbols, such as names for the start
-of sections. To support this, the Writer can create a File object which vends
-no initial atoms, but does lazily supply atoms by name as needed.
+of sections. To support this, the Writer can create a File object which vends
+no initial atoms, but does lazily supply atoms by name as needed.
-Every Writer subclass defines its own "options" class (for instance the mach-o
-Writer defines the class WriterOptionsMachO). This options class is the
-one-and-only way to control how the Writer operates when producing an output
+Every Writer subclass defines its own "options" class (for instance the mach-o
+Writer defines the class WriterOptionsMachO). This options class is the
+one-and-only way to control how the Writer operates when producing an output
file from an Atom graph. For instance, you may want the Writer to optimize
-the output for certain OS versions, or strip local symbols, etc. The options
-class can be instantiated from command line options, or it can be subclassed
-and the ivars programmatically set.
+the output for certain OS versions, or strip local symbols, etc. The options
+class can be instantiated from command line options, or it can be subclassed
+and the ivars programmatically set.
lld::File representations
@@ -317,11 +317,11 @@
data in existing native object files.
With this model for the native file format, files can be read and turned
-into the in-memory graph of lld::Atoms with just a few memory allocations.
+into the in-memory graph of lld::Atoms with just a few memory allocations.
And the format can easily adapt over time to new features.
-The binary file format follows the ReaderWriter patterns used in lld. The lld
-library comes with the classes: ReaderNative and WriterNative. So, switching
+The binary file format follows the ReaderWriter patterns used in lld. The lld
+library comes with the classes: ReaderNative and WriterNative. So, switching
between file formats is as easy as switching which Reader subclass is used.
@@ -335,7 +335,7 @@
simple hello world program expressed in YAML::
target-triple: x86_64-apple-darwin11
-
+
atoms:
- name: _main
scope: global
@@ -349,10 +349,10 @@
- offset: 0E
kind: call32
target: _fprintf
-
+
- type: c-string
content: [ 73, 5A, 00 ]
-
+
...
The biggest use for the textual format will be writing test cases. Writing test
@@ -362,8 +362,8 @@
format, we can exactly specify every attribute of every atom and thus target
specific linker logic.
-The textual/YAML format follows the ReaderWriter patterns used in lld. The lld
-library comes with the classes: ReaderYAML and WriterYAML.
+The textual/YAML format follows the ReaderWriter patterns used in lld. The lld
+library comes with the classes: ReaderYAML and WriterYAML.
Testing
@@ -397,11 +397,11 @@
file::
# RUN: lld-core %s | FileCheck %s
-
+
#
# Test that undefined atoms are replaced with defined atoms.
#
-
+
---
atoms:
- name: foo
@@ -412,7 +412,7 @@
scope: global
type: code
...
-
+
# CHECK: name: foo
# CHECK: scope: global
# CHECK: type: code
diff --git a/lld/docs/llvm-theme/static/llvm.css b/lld/docs/llvm-theme/static/llvm.css
index da4f648..32802bb 100644
--- a/lld/docs/llvm-theme/static/llvm.css
+++ b/lld/docs/llvm-theme/static/llvm.css
@@ -140,7 +140,7 @@
/* -- body styles ----------------------------------------------------------- */
-p {
+p {
margin: 0.8em 0 0.5em 0;
}