[Git][ghc/ghc][master] 3 commits: Comments

Marge Bot (@marge-bot) gitlab at gitlab.haskell.org
Thu Jul 13 03:20:28 UTC 2023



Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC


Commits:
84c1a4a2 by Bartłomiej Cieślar at 2023-07-12T23:20:08-04:00
Comments

- - - - -
b2846cb5 by Bartłomiej Cieślar at 2023-07-12T23:20:08-04:00
updates to comments

- - - - -
2af23f0e by Bartłomiej Cieślar at 2023-07-12T23:20:08-04:00
changes

- - - - -


2 changed files:

- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Types/Name.hs


Changes:

=====================================
compiler/GHC/Iface/Tidy.hs
=====================================
@@ -8,7 +8,34 @@
 (c) The GRASP/AQUA Project, Glasgow University, 1992-1998
 -}
 
--- | Tidying up Core
+{-| Tidying up Core
+
+This module's purpose is to prepare the Core program for two distinct purposes:
+* To be serialised into the module's interface file
+* To feed to the code generator
+
+The most important tasks are:
+* Determine which `Name`s should ultimately be `Internal` and `External`
+  (which may differ to whether they were originally `Internal` or `External`).
+  See `Note [About the NameSorts]` in GHC.Types.Name.
+  For example, in:
+          module M where
+            f x = x + y
+              where y = factorial 4
+  could be optimized during the Core pass to:
+          module M where
+            y = factorial 4
+            f x = x + y
+  in which case `y` would be changed from `Internal` to `External`.
+
+* Rename local identifiers to avoid name clashes, so that unfoldings etc can
+  be serialialised using the OccName, without Uniques.
+
+  For example (`x_5` means `x` with a `Unique` of `5`):
+          f x_12 x_23 = x_12
+  would be changed to:
+          f x_12 x1_23 = x_12
+-}
 module GHC.Iface.Tidy
   ( TidyOpts (..)
   , UnfoldingExposure (..)


=====================================
compiler/GHC/Types/Name.hs
=====================================
@@ -143,12 +143,16 @@ data Name = Name
 -- See Note [About the NameSorts]
 data NameSort
   = External Module
+        -- Either an import from another module
+        -- or a top-level name
+        -- See Note [About the NameSorts]
 
   | WiredIn Module TyThing BuiltInSyntax
         -- A variant of External, for wired-in things
 
-  | Internal            -- A user-defined Id or TyVar
+  | Internal            -- A user-defined local Id or TyVar
                         -- defined in the module being compiled
+                        -- See Note [About the NameSorts]
 
   | System              -- A system-defined Id or TyVar.  Typically the
                         -- OccName is very uninformative (like 's')
@@ -213,21 +217,32 @@ TL;DR: we make the `n_occ` field lazy.
 {-
 Note [About the NameSorts]
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-1.  Initially, top-level Ids (including locally-defined ones) get External names,
-    and all other local Ids get Internal names
-
-2.  In any invocation of GHC, an External Name for "M.x" has one and only one
+1.  Initially:
+    * All types, classes, data constructors get Extenal Names
+    * Top-level Ids (including locally-defined ones) get External Names,
+    * All other local (non-top-level) Ids get Internal names
+
+2.  In the Tidy phase (GHC.Iface.Tidy):
+      * An Id that is "externally-visible" is given an External Name,
+        even if the name was Internal up to that point
+      * An Id that is not externally visible is given an Internal Name.
+        even if the name was External up to that point
+    See GHC.Iface.Tidy.tidyTopName
+
+    An Id is externally visible if it is mentioned in the interface file; e.g.
+        - it is exported
+        - it is mentioned in an unfolding
+    See GHC.Iface.Tidy.chooseExternalIds
+
+3.  In any invocation of GHC, an External Name for "M.x" has one and only one
     unique.  This unique association is ensured via the Name Cache;
     see Note [The Name Cache] in GHC.Iface.Env.
 
-3.  Things with a External name are given C static labels, so they finally
-    appear in the .o file's symbol table.  They appear in the symbol table
-    in the form M.n.  If originally-local things have this property they
-    must be made @External@ first.
+4.  In code generation, things with a External name are given C static
+    labels, so they finally appear in the .o file's symbol table.  They
+    appear in the symbol table in the form M.n. That is why
+    externally-visible things are made External (see (2) above).
 
-4.  In the tidy-core phase, a External that is not visible to an importer
-    is changed to Internal, and a Internal that is visible is changed to External
 
 5.  A System Name differs in the following ways:
         a) has unique attached when printing dumps
@@ -239,13 +254,13 @@ Note [About the NameSorts]
     If any desugarer sys-locals have survived that far, they get changed to
     "ds1", "ds2", etc.
 
-Built-in syntax => It's a syntactic form, not "in scope" (e.g. [])
+6. A WiredIn Name is used for things (Id, TyCon) that are fully known to the compiler,
+   not read from an interface file. E.g. Bool, True, Int, Float, and many others.
 
-Wired-in thing  => The thing (Id, TyCon) is fully known to the compiler,
-                   not read from an interface file.
-                   E.g. Bool, True, Int, Float, and many others
+   A WiredIn Name contains contains a TyThing, so we don't have to look it up.
 
-All built-in syntax is for wired-in things.
+   The BuiltInSyntax flag => It's a syntactic form, not "in scope" (e.g. [])
+   All built-in syntax thigs are WiredIn.
 -}
 
 instance HasOccName Name where



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/bf9b9de0685e23c191722dfdb78d28b44f1cba05...2af23f0e84eec0eb30d77134abd99858a02d7a18

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/bf9b9de0685e23c191722dfdb78d28b44f1cba05...2af23f0e84eec0eb30d77134abd99858a02d7a18
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230712/9f25aa7c/attachment-0001.html>


More information about the ghc-commits mailing list