Skip to content
  • Ryan Scott's avatar
    Revamp the treatment of auxiliary bindings for derived instances · ce987865
    Ryan Scott authored and Marge Bot's avatar Marge Bot committed
    This started as a simple fix for #18321 that organically grew into a
    much more sweeping refactor of how auxiliary bindings for derived
    instances are handled. I have rewritten `Note [Auxiliary binders]`
    in `GHC.Tc.Deriv.Generate` to explain all of the moving parts, but
    the highlights are:
    
    * Previously, the OccName of each auxiliary binding would be given
      a suffix containing a hash of its package name, module name, and
      parent data type to avoid name clashes. This was needlessly
      complicated, so we take the more direct approach of generating
      `Exact` `RdrName`s for each auxiliary binding with the same
      `OccName`, but using an underlying `System` `Name` with a fresh
      `Unique` for each binding. Unlike hashes, allocating new `Unique`s
      does not require any cleverness and avoid name clashes all the
      same...
    * ...speaking of which, in order to convince the renamer that multiple
      auxiliary bindings with the same `OccName` (but different
      `Unique`s) are kosher, we now use `rnLocalValBindsLHS` instead of
      `rnTopBindsLHS` to rename auxiliary bindings. Again, see
      `Note [Auxiliary binders]` for the full story.
    * I have removed the `DerivHsBind` constructor for
      `DerivStuff`—which was only used for `Data.Data`-related
      auxiliary bindings—and refactored `gen_Data_binds` to use
      `DerivAuxBind` instead. This brings the treatment of
      `Data.Data`-related auxiliary bindings in line with every other
      form of auxiliary binding.
    
    Fixes #18321.
    ce987865