Bump ghc-prim to 0.4.0.0
ClosedPublic

Authored by hvr on Mar 19 2015, 6:03 PM.

Details

Summary

This major bump was made necessary by f44333eae7bc7dc7b6003b75874a02445f6b633b
which changed existing type signatures.

Test Plan

Harbormaster

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
hvr updated this revision to Diff 2486.Mar 19 2015, 6:03 PM
hvr retitled this revision from to Bump ghc-prim to 0.4.0.0.
hvr updated this object.
hvr edited the test plan for this revision. (Show Details)
hvr added a reviewer: austin.

I would just not bother since the old primops were basically broken anyways, but meh.

I'm curious why some of these stderr updates also update the version of integer-gmp to 1.0.0.0, but in others the integer-gmp version was updated already? Shouldn't the tests have been failing before then?

hvr updated this revision to Diff 2487.Mar 20 2015, 4:59 AM

rebase to master

hvr updated this object.Mar 20 2015, 5:00 AM
hvr added a comment.Mar 20 2015, 5:03 AM

I'm curious why some of these stderr updates also update the version of integer-gmp to 1.0.0.0, but in others the integer-gmp version was updated already? Shouldn't the tests have been failing before then?

In some cases, the version numbers are normalised away by the testsuite, in other cases that normalisation doesn't occur. That's why sometimes you need to update outputs but not always.

ekmett accepted this revision.Mar 20 2015, 5:16 AM
ekmett added a reviewer: ekmett.
ekmett added a subscriber: ekmett.

Personally I have very little preference.

Bumping the major version properly will cause an update ripple for ~40 packages when the final release goes out. On the other hand, the primitives that changed signatures were basically unusable before, and none of those packages are affected.

I think "doing the right thing" like this and bumping the version is the right thing to do just from a decorum standpoint, but I don't think anyone would care (or would even have noticed) if we kept the current ghc-prim version.

This revision is now accepted and ready to land.Mar 20 2015, 5:16 AM

I agree with Edward's assessment here. Put me down as slightly in favor of the major version bump, despite the marginal pain that will cause for GHC 7.10 adoption. I'll end up helping to hunt down those package with the effort to get Stackage building for GHC 7.10.

hvr added a comment.Mar 20 2015, 5:35 AM

Fwiw, here's a few more changes I see when comparing the :browse GHC.Prim output between 7.8.4 and 7.10.1:

@@ -26 +26 @@
-data GHC.Prim.Any
+type family GHC.Prim.Any :: k

@@ -69,2 +69,2 @@
-type role GHC.Prim.Proxy# nominal
-data GHC.Prim.Proxy# b
+type role GHC.Prim.Proxy# nominal nominal
+data GHC.Prim.Proxy# a b

@@ -183 +192,10 @@
-GHC.Prim.coerce :: forall (k :: BOX) (a :: k) (b :: k). GHC.Types.Coercible a b => a -> b
+GHC.Prim.coerce :: GHC.Types.Coercible a b => a -> b

@@ -2230,5 +2294,4 @@
-type role GHC.Prim.~# nominal nominal
-data (GHC.Prim.~#) b c
-data GHC.Prim.~R# b c
-type role GHC.Types.Coercible representational representational
-class GHC.Types.Coercible (a :: k) (b :: k)
+type role (GHC.Prim.~#) nominal nominal nominal
+data (GHC.Prim.~#) a b c
+type role (~R#) nominal representational representational
+data (~R#) a b c

The Any change is quite visible.

I think that changes me from being on the fence with a slight tilt towards doing the change, to being very strongly in favor of doing this bump.

This revision was automatically updated to reflect the committed changes.