[Git][ghc/ghc][wip/jade/ast] Apply 1 suggestion(s) to 1 file(s)
Hassan Al-Awwadi (@hassan.awwadi)
gitlab at gitlab.haskell.org
Fri Oct 4 09:18:55 UTC 2024
Hassan Al-Awwadi pushed to branch wip/jade/ast at Glasgow Haskell Compiler / GHC
Commits:
bb2bb34e by Hassan Al-Awwadi at 2024-10-04T09:18:52+00:00
Apply 1 suggestion(s) to 1 file(s)
Co-authored-by: Rodrigo Mesquita <rodrigo.m.mesquita at gmail.com>
- - - - -
1 changed file:
- compiler/GHC/Hs/Type.hs
Changes:
=====================================
compiler/GHC/Hs/Type.hs
=====================================
@@ -1088,47 +1088,54 @@ also forbids them in types involved with `deriving`:
* *
************************************************************************
-Note [Lifecycle of an UpdFieldOcc]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When we have an update to a field occurrence (UpdFieldOcc) of the form
-rec{ label = value }, its possible that what label refers to is ambiguous,
-aka: that there are multiple record types with label as a field. In this case
-we can't go from a RdrName in the GhcPs stage to a Name in the GhcRn stage,
-because we have multiple Names we could choose from. Once we typecheck, we
-also do type-directed disambiguation, so at that stage we can go directly from
-a Name to an Id, modulo the disambiguation succeeding.
-
-To account for this the UpdFieldOcc occurrence has an instantiation for its
-XXUpdFieldOcc type family: AmbiguousFieldOcc. AmbiguousFieldOcc just stores
-the RdrName directly, whereas the FieldOcc (GhcPass p) field will go from
-RdrName to Name to Id as the stage shifts. Note that FieldOcc also stores
-the RdrName throughout its lifecycle, for exact printing purpose, after the
-Parse stage this RdrName just shifts from the foLabel field to the foExt field.
-
-Summarised the lifecycle of a FieldOcc is like this:
-* GhcPs: FieldOcc noExtField RdrName
-* GhcRn: FieldOcc RdrName Name
-* GhcTc: FieldOcc RdrName Id
+Note [Lifecycle of FieldOcc/UpdFieldOcc]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+When renaming a "record field update" (`some_record{ field = expr }`), the field
+occurrence may be ambiguous if there are multiple record types with that same
+field label in scope. Instead of failing, we may attempt to do type-directed
+disambiguation: if we typecheck the record field update, we can disambiguate
+the `field` based on the record and field type.
+
+In practice, this means an identifier of an update field occurrence
+(`UpdFieldOcc`) may have to go straight from `RdrName` to `Id`, since field
+ambiguity makes it impossible to construct a `Name` for the field.
+
+Since type-directed disambiguation is a GHC property rather than a property of
+the GHC-Haskell AST, we still parametrise an `UpdFieldOcc` occurrence by `IdP p`,
+but introduce a constructor `AmbiguousFieldOcc` in the `XXUpdFieldOcc` extension point.
+That is:
+
+ * `AmbiguousFieldOcc @GhcRn :: RdrName -> UpdFieldOcc`
+ * `UpdFieldOcc @GhcRn :: Name -> UpdFieldOcc`
-With its extra constructor `XFieldOcc currently being unused and disabled by
-instantiation XXFieldOcc (GhcPass p) = DataConCantHappen. In most cases just
-having this FieldOcc datatype is enough, but as mentioned the UpdFieldOcc case
-requires a case for ambiguity.
+If the update field occurrence is ambiguous, the renamer will construct it with
+`AmbiguousFieldOcc`. Otherwise, it'll use `UpdFieldOcc` -- an unambiguous
+update field occurrence.
+
+In @GhcTc the `UpdFieldOcc` extension point is "deleted" since all field
+occurrences after type checking must be unambiguous.
+
+A `FieldOcc` is a field occurrence that /does not/ occur in a record update, c.f. `UpdFieldOcc`.
+Non-update field occurrences are always unambiguous.
The lifecycle of an UpdFieldOcc is as follows
* GhcPs:
- * UpdFieldOcc noExtField (FieldOcc GhcPs)
- * XUpdFieldOcc DataConCantHappen
+ - UpdFieldOcc noExtField (FieldOcc GhcPs)
+ - XUpdFieldOcc DataConCantHappen
* GhcRn:
- * UpdFieldOcc noExtField (FieldOCc GhcRn)
- * XUpdFieldOcc AmbiguousFieldOcc
+ - UpdFieldOcc noExtField (FieldOCc GhcRn)
+ - XUpdFieldOcc /AmbiguousFieldOcc/
* GhcTc:
- * UpdFieldOcc noExtField (FieldOCc GhcRn)
- * XUpdFieldOcc DataConCantHappen
+ - UpdFieldOcc noExtField (FieldOCc GhcRn)
+ - XUpdFieldOcc DataConCantHappen
+
+The lifecycle of a FieldOcc is more straightforward:
+* GhcPs: FieldOcc noExtField RdrName
+* GhcRn: FieldOcc RdrName Name
+* GhcTc: FieldOcc RdrName Id
-so using DataConCantHappen we statically guarantee that when we go to a
-UpdFieldOcc GhcRn to UpdFieldOcc GhcTc we either succesfully disambiguate or
-error when we can't.
+NB: FieldOcc preserves the RdrName throughout its lifecycle for
+exact printing purposes.
-}
-- | Ambiguous Field Occurrence
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/bb2bb34e6b07d1dd75330ed6d8dfd25d48a6cf18
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/bb2bb34e6b07d1dd75330ed6d8dfd25d48a6cf18
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/20241004/87612f3b/attachment-0001.html>
More information about the ghc-commits
mailing list