Merge TranslationUnit into Module, and eliminate the term "translation unit".

This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.

Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).

The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)

Swift SVN r10837

Author: jrose-apple

Diff for: docs/LangRef.html

@@ -134,13 +134,13 @@ <h2>Phases of Translation</h2>
      are:</p>
 
   <ul>
-  <li><a href="#lexical">Lexing</a>: A translation unit is broken into tokens
+  <li><a href="#lexical">Lexing</a>: A source file is broken into tokens
     according to a (nearly, /**/ comments can be nested) regular grammar.</li>
   <li>Parsing and AST Building: The tokens are parsed according to the grammar
     set out below.  The grammar is context free and does not require any "type
     feedback" from the lexer or later stages.  During parsing, name binding for
     references to local variables and other declarations that are not at
-    translation unit (and eventually namespace) scope are bound.
+    module (and eventually namespace) scope are bound.
   </li>
   <li><a href="#namebind">Name Binding</a>: At this phase, references to
       non-local types and values are bound, and <a href="#decl-import">import
@@ -157,7 +157,7 @@ <h2>Phases of Translation</h2>
   </ul>
 
   <p>
-  FIXME: "import swift" implicitly added as the last import in translation unit.
+  FIXME: "import swift" implicitly added as the last import in a source file.
   </p>
 
   <!-- ********************************************************************* -->
@@ -617,17 +617,16 @@ <h2 id="decl">Declarations</h2>
 
 
   <!-- ===================================================================== -->
-  <h3 id="decl-translation-unit">Translation Unit</h3>
+  <h3 id="decl-top-level">Module-Scope Declarations</h3>
   <!-- ===================================================================== -->
 
   <pre class="grammar">
-    translation-unit ::= <a href="#brace-item-list">brace-item</a>*
+    top-level ::= <a href="#brace-item-list">brace-item</a>*
   </pre>
 
   <p>The top level of a swift source file is grammatically identical to the
-  contents of a func decl.  Some declarations
-  have semantic restrictions that only allow them within a translation unit
-  though.
+  contents of a func decl.  Some declarations, however, are restricted to
+  module scope.
   </p>
 
   <!-- _____________________________________________________________________ -->
@@ -644,7 +643,7 @@ <h4 id="brace-item-list">Brace Enclosed Items</h4>
   <p>The brace item list provides a sequencing operation which evaluates the
   members of its body in order.  Function bodies and the bodies of control
   flow statements use braces.  Also, the <a
-    href="#decl-translation-unit">translation unit</a> itself is effectively a
+    href="#decl-top-level">source file</a> itself is effectively a
   brace item list, but without the braces.
   </p>
 
@@ -670,9 +669,9 @@ <h3 id="decl-import">import Declarations</h3>
   local names, even when they are defined in other modules and namespaces.  See
   the section on <a href="#namebind">name binding</a> for more
   information on how these work.  import declarations are only allowed at
-  translation unit scope.</p>
+  module scope.</p>
 
-  <p>'import' directives only impact a single translation unit: imports in one
+  <p>'import' directives only impact a single source file: imports in one
   swift file do not affect name lookup in another file. import directives can
   only occur at the top level of a file, not within a function or namespace.</p>
 
@@ -731,7 +730,7 @@ <h3 id="decl-extension">extension Declarations</h3>
   </pre>
 
   <p>'extension' declarations allow adding member declarations to existing
-     types, even in other translation units and modules.  There are different
+     types, even in other source files and modules.  There are different
      semantic rules for each type that is extended.
   </p>
 
@@ -3727,7 +3726,7 @@ <h3 id="namebind_typevalue_lookup">Name Lookup for Type and Value Names</h3>
   <li>Search the current scope tree for a local name.  Local names cannot be
       forward referenced.</li>
   <li>Bind to names defined in the current component, including the current
-      translation unit. TODO: is this a good thing?  We could require explicit
+      module. TODO: is this a good thing?  We could require explicit
       imports if we wanted to.</li>
   <li>Bind to identifiers that are imported with an import directive.  Imports
       are searched in order of introduction (top-down).  The location of an
@@ -3785,7 +3784,7 @@ <h2 id="stdlib">Standard Library</h2>
      the library.</p>
 
   <p>All of this code is published by the 'swift' module, which is
-     implicitly imported into each translation unit, unless some sort of pragma
+     implicitly imported into each source file, unless some sort of pragma
      in the code (attribute on an import?) is used to change or disable this
      behavior.</p>
 

Diff for: docs/Literals.rst

@@ -106,7 +106,7 @@ How about cases where there is no context? ::
   var str = "abc"
 
 Here we have nothing to go on, so instead the type checker looks for a global
-type named ``StringLiteralType`` in the current translation unit, and uses
+type named ``StringLiteralType`` in the current module-scope context, and uses
 that type if it is actually a StringLiteralConvertible type. This both allows
 different standard libraries to set different default literal types, and allows
 a user to *override* the default type in their own source file.

Diff for: include/swift/AST/ASTContext.h

@@ -63,7 +63,6 @@ namespace swift {
   class Module;
   class ModuleLoader;
   class NominalTypeDecl;
-  class TranslationUnit;
   class TupleTypeElt;
   class EnumElementDecl;
   class ProtocolDecl;
@@ -166,7 +165,7 @@ class ASTContext {
   llvm::StringMap<Module*> LoadedModules;
 
   /// The builtin module.
-  TranslationUnit * const TheBuiltinModule;
+  Module * const TheBuiltinModule;
 
   /// The standard library module.
   mutable Module *TheStdlibModule = nullptr;

Diff for: include/swift/AST/Decl.h

@@ -1042,11 +1042,11 @@ class PatternBindingDecl : public Decl {
 
 /// TopLevelCodeDecl - This decl is used as a container for top-level
 /// expressions and statements in the main module.  It is always a direct
-/// child of the body of a TranslationUnit.  The primary reason for
-/// building these is to give top-level statements a DeclContext which is
-/// distinct from the TranslationUnit itself.  This, among other things,
-/// makes it easier to distinguish between local top-level variables (which
-/// are not live past the end of the statement) and global variables.
+/// child of a SourceFile.  The primary reason for building these is to give
+/// top-level statements a DeclContext which is distinct from the file itself.
+/// This, among other things, makes it easier to distinguish between local
+/// top-level variables (which are not live past the end of the statement) and
+/// global variables.
 class TopLevelCodeDecl : public Decl, public DeclContext {
   BraceStmt *Body;
 

Diff for: include/swift/AST/DeclContext.h

@@ -234,12 +234,9 @@ class alignas(8) DeclContext {
                        LazyResolver *typeResolver,
                        SmallVectorImpl<ValueDecl *> &decls) const;
 
-  /// getASTContext - Return the ASTContext for a specified DeclContext by
+  /// Return the ASTContext for a specified DeclContext by
   /// walking up to the enclosing module and returning its ASTContext.
-  ASTContext &getASTContext();
-  const ASTContext &getASTContext() const {
-    return const_cast<DeclContext *>(this)->getASTContext();
-  }
+  ASTContext &getASTContext() const;
 
   /// \returns true if traversal was aborted, false otherwise.
   bool walkContext(ASTWalker &Walker);

Diff for: include/swift/AST/ExternalNameLookup.h

@@ -31,8 +31,8 @@ class ExternalNameLookup {
   virtual ~ExternalNameLookup() = default;
 
   /// ExternalNameLookup is consulted at two times during name
-  /// lookup.  This is the first time: after all names in the
-  /// TranslationUnit have been checked but before external
+  /// lookup.  This is the first time: after all names in a
+  /// source file have been checked but before external
   /// Modules are checked.  The results in the ResultVector will
   /// be consulted first.  Return true if results have been added
   /// to RV.