Re: [ANNOUNCE] GHC 8.2.2 release candidate 1

I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType. I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though! Ryan S. ----- [1] https://www.stackage.org/nightly-2017-09-29 [2] https://ghc.haskell.org/trac/ghc/wiki/Migration/8.4?version=7#TypeInTypeispi...

Ryan Scott
I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType.
I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though!
It sounds like you are describing #13391. If this is the case then I'm rather confused since I didn't merge the associated patch. Something else must be going on here. Perhaps some other patch made the checks a bit more strict inadvertently? Cheers, - Ben

I would have guessed that it's actually due to #11963 [1], and
consequently, this [2] backported patch.
Ryan S.
-----
[1] https://ghc.haskell.org/trac/ghc/ticket/11963
[2]
http://git.haskell.org/ghc.git/commit/18dee8912f6afdcf13073d3d95d85513c14180...
On Oct 1, 2017 21:19, "Ben Gamari"
Ryan Scott
writes: I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType.
I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though!
It sounds like you are describing #13391. If this is the case then I'm rather confused since I didn't merge the associated patch. Something else must be going on here. Perhaps some other patch made the checks a bit more strict inadvertently?
Cheers,
- Ben

On October 1, 2017 9:29:16 PM EDT, Ryan Scott
I would have guessed that it's actually due to #11963 [1], and consequently, this [2] backported patch.
Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/11963 [2] http://git.haskell.org/ghc.git/commit/18dee8912f6afdcf13073d3d95d85513c14180...
On Oct 1, 2017 21:19, "Ben Gamari"
wrote: Ryan Scott
writes: I did a smoke test of Stackage Nightly's libraries [1] this afternoon using GHC 8.2.2. Only two libraries failed to build: extensible-0.4.5 and protolude-0.2, due to a change where type signatures like `foo :: forall k. forall (a :: k). ...` no longer compile without enabling TypeInType.
I only mention this because the migration guide for 8.4 [2] currently gives the impression that this TypeInType change won't land until GHC 8.4. This doesn't appear to be case, though!
It sounds like you are describing #13391. If this is the case then I'm rather confused since I didn't merge the associated patch. Something else must be going on here. Perhaps some other patch made the checks a bit more strict inadvertently?
Cheers,
- Ben
Ahh, good catch. Perhaps we should revert in this case. Cheers, - Ben

Hi Ben,
https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like
sparkle and others, since they crucially rely on PIE, in this case to
dynamically load executables in the JVM. It looks like you committed a
fix for this in HEAD. Any chance you could backport this to the GHC
8.2 branch?
Thanks,
--
Mathieu Boespflug
Founder at http://tweag.io.
On 2 October 2017 at 16:32, Ben Gamari
Ben Gamari
writes: Ahh, good catch. Perhaps we should revert in this case.
I've reverted this on the ghc-8.2 branch.
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

BTW, I hadn't spotted that this patch was only in HEAD since the
documentation says:
.. ghc-flag:: -pie
:shortdesc: Instruct the linker to produce a position-independent
executable.
:type: dynamic
:category: linking
:since: 8.2.1
I guess it was originally slated for that release? Should say at least 8.2.2.
--
Mathieu Boespflug
Founder at http://tweag.io.
On 2 October 2017 at 22:45, Boespflug, Mathieu
Hi Ben,
https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like sparkle and others, since they crucially rely on PIE, in this case to dynamically load executables in the JVM. It looks like you committed a fix for this in HEAD. Any chance you could backport this to the GHC 8.2 branch?
Thanks, -- Mathieu Boespflug Founder at http://tweag.io.
On 2 October 2017 at 16:32, Ben Gamari
wrote: Ben Gamari
writes: Ahh, good catch. Perhaps we should revert in this case.
I've reverted this on the ghc-8.2 branch.
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

"Boespflug, Mathieu"
BTW, I hadn't spotted that this patch was only in HEAD since the documentation says:
.. ghc-flag:: -pie :shortdesc: Instruct the linker to produce a position-independent executable. :type: dynamic :category: linking
:since: 8.2.1
I guess it was originally slated for that release? Should say at least 8.2.2.
Good catch, thanks for noticing this. I originally had intended this for 8.2.1 but it took longer to get the patch into shape than I anticipated so I deferred it. It looks like I forgot to update the documentation when I merged. I'll fix this right now. Cheers, - Ben

"Boespflug, Mathieu"
Hi Ben,
https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like sparkle and others, since they crucially rely on PIE, in this case to dynamically load executables in the JVM. It looks like you committed a fix for this in HEAD. Any chance you could backport this to the GHC 8.2 branch?
Sorry for the delay; I had to mull this over as I'm a bit weary since this is not a strict regression over 8.0. However, I'm sympathetic since this is a rather recent regression (introduced in 8.0.2) and the patch is quite low-risk. I'll merge. Cheers, - Ben

Thanks! As you say - not a regression over 8.0.2, but is a regression
over 8.0.1 (albeit a very conscious one).
--
Mathieu Boespflug
Founder at http://tweag.io.
On 3 October 2017 at 00:01, Ben Gamari
"Boespflug, Mathieu"
writes: Hi Ben,
https://ghc.haskell.org/trac/ghc/ticket/13702 break projects like sparkle and others, since they crucially rely on PIE, in this case to dynamically load executables in the JVM. It looks like you committed a fix for this in HEAD. Any chance you could backport this to the GHC 8.2 branch?
Sorry for the delay; I had to mull this over as I'm a bit weary since this is not a strict regression over 8.0. However, I'm sympathetic since this is a rather recent regression (introduced in 8.0.2) and the patch is quite low-risk. I'll merge.
Cheers,
- Ben
participants (3)
-
Ben Gamari
-
Boespflug, Mathieu
-
Ryan Scott