[Git][ghc/ghc][wip/T23496-take-three] 3 commits: Bump Cabal submodule

[Ryan Scott (@RyanGlScott)]

Ryan Scott pushed to branch wip/T23496-take-three at Glasgow Haskell Compiler / GHC


Commits:
e7e9efcb by Ryan Scott at 2023-07-14T09:25:48-04:00
Bump Cabal submodule

This bumps the `Cabal` submodule to bring in the changes from
https://github.com/haskell/cabal/pull/9071, which are a pre-requisite to
splitting out a `GHC.Generics.Internal` submodule from `GHC.Generics` (to be
done in a subsequent commit). Without these changes, compiling `Cabal` would
fail, since `Cabal-syntax`'s `Distribution.Compat.Prelude` was implicitly
relying on the bug documented in #23570, and when the modules are split apart,
the bug no longer triggers.

- - - - -
bfd29444 by Ryan Scott at 2023-07-14T09:27:20-04:00
Split GHC.Generics into two modules

Most of `GHC.Generics` has now been moved to `GHC.Generics.Internal`, which
`GHC.Generics` re-exports. The only things now defined in `GHC.Generics` are
the derived `Generic(1)` instances. These need to be put in a different module
because of GHC's new approach to dependency analysis used in a fix for #23496
(to be done in a subsequent commit), which is perfectly within its rights to
typecheck a generated `Rep` instance before it typechecks any of the
definitions that are referenced in the right-hand side of the instance.
Putting the definitions in a separate module from the derived `Generic`
instances (and therefore the generated `Rep` instances) is a sure-fire way to
ensure that this doesn't happen.

This causes a fair bit of churn in the expected output of test cases in the
test suite, but all of the changes are simply from switching to displaying
"`GHC.Generics.Internal`" instead of "`GHC.Generics`".  Similarly, this bumps
the `haddock` submodule to bring in some changes to test cases in the Haddock
test suite.

- - - - -
c955449e by Ryan Scott at 2023-07-14T09:27:20-04:00
deriving: Typecheck associated family instances before instance bindings

This is a significant overhaul of the way that `deriving` clauses and
standalone `deriving` declarations are typechecked. The highlights:

* Standalone `deriving` declarations are located in the new `DerivInstD`
  constructor of `ClsInstDecl`, rather than as part of the `DerivD` constructor
  of `HsGroup`.  This move now means that standalone `deriving` instance
  declarations are located alongside other forms of instance declarations,
  which makes it easier to perform SCC analysis on them, as they are now part
  of a `TyClGroup`.

* Now that everything `deriving`-related lives in `TyClGroup`s, we now
  typecheck all of the associated type family instances that are generated from
  `deriving` clauses/declarations first (in `tcTyClGroup`) _before_
  typechecking any of the generated instance bindings, which happen after all
  of the `TyClGroup`s have been processed. Doing so is essential to ensuring
  that these associated type instances are in scope when needed to typecheck
  other code in later `TyClGroup`s, such as the failing examples seen
  in #23496. I have written an extensive `Note [Staging of deriving]` (previously
  `Note [Staging of tcDeriving]`) to describe how everything works.

The second bullet point above involves quite a bit of churn in the expected
output of several test cases.  This is for two reasons:

1. The order in which things are printed with `-ddump-deriv` is now different,
   since `deriving`-related family instances are now generated earlier in the
   typechecker.

2. If a test case errors out when typechecking a `deriving`-related family
   instance, then GHC will stop there before printing any errors involving the
   generated instance bindings. (Previously, both sorts of errors were printed
   simultaneously.) As such, some expected-to-fail test cases do not print out
   as many errors as before.

Fixes #23496.

- - - - -


23 changed files:

- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/Hs/Stats.hs
- compiler/GHC/Hs/Utils.hs
- compiler/GHC/HsToCore/Docs.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Parser.y
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Tc/Deriv.hs
- compiler/GHC/Tc/Deriv/Utils.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Instance.hs
- compiler/GHC/Tc/TyCl/Instance.hs-boot
- compiler/GHC/Tc/Utils/Env.hs
- compiler/GHC/ThToHs.hs
- compiler/Language/Haskell/Syntax/Decls.hs
- compiler/Language/Haskell/Syntax/Extension.hs
- libraries/Cabal
- libraries/base/GHC/Generics.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/57f0ceb5ff6059df0a4f229cd143c8af247feef5...c955449e244a027fc12f86c387dac6be773aa27f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/57f0ceb5ff6059df0a4f229cd143c8af247feef5...c955449e244a027fc12f86c387dac6be773aa27f
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/20230714/a9aa3887/attachment.html>