[Git][ghc/ghc][wip/hackage-bindist] 17 commits: Add `Eq` and `Ord` instances for `Generically1`

Matthew Pickering (@mpickering) gitlab at gitlab.haskell.org
Fri Sep 23 22:16:29 UTC 2022



Matthew Pickering pushed to branch wip/hackage-bindist at Glasgow Haskell Compiler / GHC


Commits:
c4c2cca0 by John Ericson at 2022-09-20T13:11:49-04:00
Add `Eq` and `Ord` instances for `Generically1`

These are needed so the subsequent commit overhauling the `*1` classes
type-checks.

- - - - -
7beb356e by John Ericson at 2022-09-20T13:11:50-04:00
Relax instances for Functor combinators; put superclass on Class1 and Class2 to make non-breaking

This change is approved by the Core Libraries commitee in
https://github.com/haskell/core-libraries-committee/issues/10

The first change makes the `Eq`, `Ord`, `Show`, and `Read` instances for
`Sum`, `Product`, and `Compose` match those for `:+:`, `:*:`, and `:.:`.
These have the proper flexible contexts that are exactly what the
instance needs:

For example, instead of
```haskell
instance (Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where
  (==) = eq1
```
we do
```haskell
deriving instance Eq (f (g a)) => Eq (Compose f g a)
```

But, that change alone is rather breaking, because until now `Eq (f a)`
and `Eq1 f` (and respectively the other classes and their `*1`
equivalents too) are *incomparable* constraints. This has always been an
annoyance of working with the `*1` classes, and now it would rear it's
head one last time as an pesky migration.

Instead, we give the `*1` classes superclasses, like so:
```haskell
(forall a. Eq a => Eq (f a)) => Eq1 f
```
along with some laws that canonicity is preserved, like:
```haskell
liftEq (==) = (==)
```

and likewise for `*2` classes:
```haskell
(forall a. Eq a => Eq1 (f a)) => Eq2 f
```
and laws:
```haskell
liftEq2 (==) = liftEq1
```

The `*1` classes also have default methods using the `*2` classes where
possible.

What this means, as explained in the docs, is that `*1` classes really
are generations of the regular classes, indicating that the methods can
be split into a canonical lifting combined with a canonical inner, with
the super class "witnessing" the laws[1] in a fashion.

Circling back to the pragmatics of migrating, note that the superclass
means evidence for the old `Sum`, `Product`, and `Compose` instances is
(more than) sufficient, so breakage is less likely --- as long no
instances are "missing", existing polymorphic code will continue to
work.

Breakage can occur when a datatype implements the `*1` class but not the
corresponding regular class, but this is almost certainly an oversight.
For example, containers made that mistake for `Tree` and `Ord`, which I
fixed in https://github.com/haskell/containers/pull/761, but fixing the
issue by adding `Ord1` was extremely *un*controversial.

`Generically1` was also missing `Eq`, `Ord`, `Read,` and `Show`
instances. It is unlikely this would have been caught without
implementing this change.

-----

[1]: In fact, someday, when the laws are part of the language and not
only documentation, we might be able to drop the superclass field of the
dictionary by using the laws to recover the superclass in an
instance-agnostic manner, e.g. with a *non*-overloaded function with
type:

```haskell
DictEq1 f -> DictEq a -> DictEq (f a)
```

But I don't wish to get into optomizations now, just demonstrate the
close relationship between the law and the superclass.

Bump haddock submodule because of test output changing.

- - - - -
6a8c6b5e by Tom Ellis at 2022-09-20T13:12:27-04:00
Add notes to ghc-prim Haddocks that users should not import it

- - - - -
ee9d0f5c by matoro at 2022-09-20T13:13:06-04:00
docs: clarify that LLVM codegen is not available in unregisterised mode

The current docs are misleading and suggest that it is possible to use
LLVM codegen from an unregisterised build.  This is not the case;
attempting to pass `-fllvm` to an unregisterised build warns:

```
when making flags consistent: warning:
    Target platform uses unregisterised ABI, so compiling via C
```

and uses the C codegen anyway.

- - - - -
854224ed by Nicolas Trangez at 2022-09-20T20:14:29-04:00
rts: remove copy-paste error from `cabal.rts.in`

This was, likely accidentally, introduced in 4bf542bf1c.

See: 4bf542bf1cdf2fa468457fc0af21333478293476

- - - - -
c8ae3add by Matthew Pickering at 2022-09-20T20:15:04-04:00
hadrian: Add extra_dependencies edges for all different ways

The hack to add extra dependencies needed by DeriveLift extension missed
the cases for profiles and dynamic ways. For the profiled way this leads
to errors like:

```
GHC error in desugarer lookup in Data.IntSet.Internal:
  Failed to load interface for ‘Language.Haskell.TH.Lib.Internal’
  Perhaps you haven't installed the profiling libraries for package ‘template-haskell’?
  Use -v (or `:set -v` in ghci) to see a list of the files searched for.
ghc: panic! (the 'impossible' happened)
  GHC version 9.5.20220916:
        initDs
```

Therefore the fix is to add these extra edges in.

Fixes #22197

- - - - -
a971657d by Mon Aaraj at 2022-09-21T06:41:24+03:00
users-guide: fix incorrect ghcappdata folder for unix and windows

- - - - -
06ccad0d by sheaf at 2022-09-21T08:28:49-04:00
Don't use isUnliftedType in isTagged

The function GHC.Stg.InferTags.Rewrite.isTagged can be given
the Id of a join point, which might be representation polymorphic.
This would cause the call to isUnliftedType to crash. It's better
to use typeLevity_maybe instead.

Fixes #22212

- - - - -
c0ba775d by Teo Camarasu at 2022-09-21T14:30:37-04:00
Add fragmentation statistic to GHC.Stats

Implements #21537

- - - - -
2463df2f by Torsten Schmits at 2022-09-21T14:31:24-04:00
Rename Solo[constructor] to MkSolo

Part of proposal 475 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst)

Moves all tuples to GHC.Tuple.Prim
Updates ghc-prim version (and bumps bounds in dependents)

updates haddock submodule
updates deepseq submodule
updates text submodule

- - - - -
9034fada by Matthew Pickering at 2022-09-22T09:25:29-04:00
Update filepath to filepath-1.4.100.0

Updates submodule

* Always rely on vendored filepath
* filepath must be built as stage0 dependency because it uses
  template-haskell.

Towards #22098

- - - - -
615e2278 by Krzysztof Gogolewski at 2022-09-22T09:26:05-04:00
Minor refactor around Outputable

* Replace 'text . show' and 'ppr' with 'int'.
* Remove Outputable.hs-boot, no longer needed
* Use pprWithCommas
* Factor out instructions in AArch64 codegen

- - - - -
0238585f by Matthew Pickering at 2022-09-23T22:56:29+01:00
Don't include BufPos in interface files

Ticket #22162 pointed out that the build directory was leaking into the
ABI hash of a module because the BufPos depended on the location of the
build tree.

BufPos is only used in GHC.Parser.PostProcess.Haddock, and the
information doesn't need to be propagated outside the context of a
module.

Fixes #22162

- - - - -
bb9138a4 by Matthew Pickering at 2022-09-23T22:56:29+01:00
Add test for #22162

- - - - -
dc0fd95b by Matthew Pickering at 2022-09-23T22:56:29+01:00
ci: Add job to test interface file determinism guarantees

In this job we can run on every commit we add a test which builds the
Cabal library twice and checks that the ABI hash and interface hash is
stable across the two builds.

* We run the test 20 times to try to weed out any race conditions due to
  `-j`
* We run the builds in different temporary directories to try to weed
  out anything related to build directory affecting ABI or interface
  file hash.

Fixes #22180

- - - - -
b73d5e91 by Matthew Pickering at 2022-09-23T22:56:29+01:00
ci: Add job for testing interface stability across builds

The idea is that both the bindists should product libraries with the
same ABI and interface hash.
So the job checks with ghc-pkg to make sure the computed ABI
is the same.

In future this job can be extended to check for the other facets of
interface determinism.

Fixes #22180

- - - - -
a5b8b2fd by Matthew Pickering at 2022-09-23T23:16:16+01:00
Fix mk_mod_usage_info if the interface file is not already loaded

In #22217 it was observed that the order modules are compiled in affects
the contents of an interface file. This was because a module dependended
on another module indirectly, via a re-export but the interface file for
this module was never loaded because the symbol was never used in the
file.

If we decide that we depend on a module then we jolly well ought to
record this fact in the interface file! Otherwise it could lead to very
subtle recompilation bugs if the dependency is not tracked and the
module is updated.

Therefore the best thing to do is just to make sure the file is loaded
by calling the `loadSysInterface` function.  This first checks the
caches (like we did before) but then actually goes to find the interface
on disk if it wasn't loaded.

Fixes #22217

- - - - -


30 changed files:

- .gitlab-ci.yml
- .gitlab/ci.sh
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Types.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Cmm/DebugBlock.hs
- compiler/GHC/CmmToAsm.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/Core/Coercion/Axiom.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Hs.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Pat.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore.hs
- compiler/GHC/HsToCore/Usage.hs
- compiler/GHC/Iface/Ext/Types.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Stg/InferTags/Rewrite.hs
- compiler/GHC/Tc/Errors/Hole.hs
- compiler/GHC/Types/Avail.hs
- compiler/GHC/Types/Name/Cache.hs
- compiler/GHC/Types/SrcLoc.hs
- compiler/GHC/Unit/Types.hs-boot
- compiler/GHC/Utils/Binary.hs
- compiler/GHC/Utils/Outputable.hs
- − compiler/GHC/Utils/Outputable.hs-boot
- docs/users_guide/codegens.rst
- docs/users_guide/ghci.rst


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc6c7a6004df1549f72ea516baab3e55ae12d735...a5b8b2fdfbf966720a060b3ee7d70a8d00b4f06f

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/cc6c7a6004df1549f72ea516baab3e55ae12d735...a5b8b2fdfbf966720a060b3ee7d70a8d00b4f06f
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/20220923/a73b4894/attachment-0001.html>


More information about the ghc-commits mailing list