[Gardening] De-RST DependencyAnalysis

Author: CodaFi

docs/CompilerPerformance.md

@@ -1143,7 +1143,7 @@ driver. These files contain the driver's summary-view of the dependencies
 between entities defined and referenced in each source file; it is from these
 files that the driver decides when a file "needs" to be rebuilt because it
 depends on another file that needs to be rebuilt, and so on transitively. The
-file format is [documented here](DependencyAnalysis.rst).
+file format is [documented here](DependencyAnalysis.md).
 
 ### Finding areas in need of general improvement
 

docs/DependencyAnalysis.rst renamed to docs/DependencyAnalysis.md

@@ -1,6 +1,3 @@
-:orphan:
-
-===================
 Dependency Analysis
 ===================
 
@@ -20,25 +17,25 @@ Kinds of Dependency
 
 There are four major kinds of dependency between files:
 
-- ``top-level``: use of an unqualified name that is looked up at module scope,
+- `top-level`: use of an unqualified name that is looked up at module scope,
   and definition of a name at module scope. This includes free functions,
   top-level type definitions, and global constants and variables.
 
-- ``nominal``: use of a particular type, in any way, and declarations that
+- `nominal`: use of a particular type, in any way, and declarations that
   change the "shape" of the type (the original definition, and extensions that
   add conformances). The type is identified by its mangled name.
 
-- ``member``: a two-part entry that constitutes either *providing* a member or
+- `member`: a two-part entry that constitutes either *providing* a member or
   *accessing* a specific member of a type. This has some complications; see
   below.
 
-- ``dynamic-lookup``: use of a specific member accessed through ``AnyObject``,
-  which has special ``id``-like rules for member accesses, and definitions of
-  ``@objc`` members that can be accessed this way.
+- `dynamic-lookup`: use of a specific member accessed through `AnyObject`,
+  which has special `id`-like rules for member accesses, and definitions of
+  `@objc` members that can be accessed this way.
 
-The ``member`` dependency kind has a special entry where the member name is
+The `member` dependency kind has a special entry where the member name is
 empty. This is in the "provides" set of *every file that adds non-private
-members* to a type, making it a superset of provided ``nominal`` entries. When
+members* to a type, making it a superset of provided `nominal` entries. When
 listed as a dependency, it means that something in the file needs to be
 recompiled whenever *any* members are added to the type in question. This is
 currently used for cases of inheritance: superclasses and protocol conformances.
@@ -51,12 +48,12 @@ dependencies, but direct lookups into a type or module will not, nor will
 dependencies not modeled by a query of some kind. These latter dependencies
 must be handled on a case-by-case basis.
 
-.. note::
+Note:
 
-    The compiler currently does not track ``nominal`` dependencies separate from
-    ``member`` dependencies. Instead, it considers every ``member`` dependency
-    to implicitly be a ``nominal`` dependency, since adding a protocol to a type
-    may change its members drastically.
+> The compiler currently does not track `nominal` dependencies separate from
+> `member` dependencies. Instead, it considers every `member` dependency
+> to implicitly be a `nominal` dependency, since adding a protocol to a type
+> may change its members drastically.
 
 
 Cascading vs. Non-Cascading Dependencies
@@ -78,18 +75,19 @@ not a particular dependency should be considered cascading. If there's not
 enough context to decide, the compiler has to go with the conservative choice
 and record it as cascading.
 
-.. note::
 
-    In the current on-disk representation of dependency information, cascading
-    dependencies are the default. Non-cascading dependencies are marked
-    ``private`` by analogy with the Swift ``private`` keyword.
+Note:
+
+> In the current on-disk representation of dependency information, cascading
+> dependencies are the default. Non-cascading dependencies are marked
+> `private` by analogy with the Swift `private` keyword.
 
 
 External Dependencies
 =====================
 
 External dependencies, including imported Swift module files and Clang headers,
-are tracked using a special ``depends-external`` set. These dependencies refer
+are tracked using a special `depends-external` set. These dependencies refer
 to files that are external to the module. The Swift driver
 interprets this set specially and decides whether or not the cross-module
 dependencies have changed.

docs/Driver.md

@@ -15,7 +15,7 @@ compiler into their build system, rather than using Xcode or the package
 manager (`swift build`). If you're looking to work on the driver itself...well,
 this is probably still useful to you, but you should also check out
 [DriverInternals.rst](DriverInternals.rst) and maybe
-[DependencyAnalysis.rst](DependencyAnalysis.rst) as well. If you're just using
+[DependencyAnalysis.md](DependencyAnalysis.md) as well. If you're just using
 Xcode or SwiftPM and want to find out what mysterious command-line options you
 could be passing, `swiftc --help` is a better choice.
 
@@ -206,7 +206,7 @@ in becoming more like non-whole-module builds.
 ## Incremental Builds ##
 
 Incremental builds in Swift work by primarily by cross-file dependency
-analysis, described in [DependencyAnalysis.rst](DependencyAnalysis.rst).
+analysis, described in [DependencyAnalysis.md](DependencyAnalysis.md).
 Compiling a single file might be necessary because that file has changed, but
 it could also be because that file depends on something else that might have
 changed. From a build system perspective, the files in a particular module

docs/Lexicon.md

@@ -88,7 +88,7 @@ name when incremental compilation is enabled. A cascading dependency is much
 safer to produce than its private counterpart, but it comes at the cost of
 increased usage of compilation resources - even if those resources are being
 wasted on rebuilding a file that didn't actually require rebuilding.
-See [DependencyAnalysis.rst](DependencyAnalysis.rst).
+See [DependencyAnalysis.md](DependencyAnalysis.md).
 
 ## Clang importer
 
@@ -399,7 +399,7 @@ require further transitive evaluation of dependency edges by the Swift
 driver. Private dependencies are therefore cheaper than cascading
 dependencies, but must be used with the utmost care or dependent files will
 fail to rebuild and the result will most certainly be a miscompile.
-See [DependencyAnalysis.rst](DependencyAnalysis.rst).
+See [DependencyAnalysis](DependencyAnalysis.md).
 
 ## QoI
 

include/swift/AST/SimpleRequest.h

@@ -48,7 +48,7 @@ enum class RequestFlags {
   /// (e.g. \c TypeCheckSourceFileRequest) will require it.
   ///
   /// For further discussion on incremental dependencies
-  /// see DependencyAnalysis.rst.
+  /// see DependencyAnalysis.md.
   DependencySource = 1 << 3,
   /// This request introduces the sink component of a source-sink
   /// incremental dependency pair and is a consumer of the current
@@ -58,7 +58,7 @@ enum class RequestFlags {
   /// (e.g. \c DirectLookupRequest) will require it.
   ///
   /// For further discussion on incremental dependencies
-  /// see DependencyAnalysis.rst.
+  /// see DependencyAnalysis.md.
   DependencySink = 1 << 4,
 };
 

include/swift/Basic/SupplementaryOutputPaths.h

@@ -77,7 +77,7 @@ struct SupplementaryOutputPaths {
   /// visibility" within a module, that becomes very important for any sort of
   /// incremental build. These files are consumed by the Swift driver to decide
   /// whether a source file needs to be recompiled during a build. See
-  /// docs/DependencyAnalysis.rst for more information.
+  /// docs/DependencyAnalysis.md for more information.
   ///
   /// \sa swift::emitReferenceDependencies
   /// \sa DependencyGraph