Fix #1015 with dataConUserTyVars #1016

RyanGlScott · 2019-02-02T15:55:03Z

The central trick in this patch is to use dataConUserTyVars instead of univ_tvs ++ ex_tvs, which displays the foralls in a GADT constructor in a way that's more faithful to how the user originally wrote it. With these changes, the example from #1015 now renders as:

Along the way, I simplified some code that tried to calculate where a data constructor should use GADT syntax in an ad hoc fashion. Luckily, this information is cached as isGadtSyntaxTyCon, so I just used that instead.

Thankfully, there's already a test case in html-test that stress-tests this code path, so I didn't need to add the test case from #1015 (since it relies on code from base which might change in the future).

Matches b71da1feabf33efbbc517ac376bb690b5a604c2f from hackage-server. Fixes #967.

* don't forget to print explicit `forall`'s when there are arg docs * when printing an explicit `forall`, print all tyvars Fixes #973

* WIP: Load (typechecker) plugins from language pragmas * Revert "Load plugins when starting a GHC session (#905)" This reverts commit 72d82e5. * Simplify plugin initialization code

Fixes #992

The information about whether or not there is a source-level `forall` is already available on a `ConDecl` (as `con_forall`), so we should use it instead of always assuming `False`! Fixes #1002.

It looks like the new versions don't cause any breakage and loosening the bounds helps deps fit in one stack resolver.

harpocrates · 2019-02-02T17:31:44Z

So this is something already fixed in the Hi Haddock branch at a53c131. There are a bunch of fixes to Convert in that branch which exist nowhere else. Rather than re-fix them in ghc-head and face hell when the time comes to rebase that branch, I think the right thing to do would be split them out of wip/hi-haddock (since that's probably not going to get merged in time for 8.8).

If @sjakobi isn't planning on working on Hi Haddock this weekend, I could try to do that now. Thoughts @sjakobi?

RyanGlScott · 2019-02-02T17:37:42Z

Looking at a53c131, it looks like that commit tackles the problem in a much different way. Intead of using dataConUserTyVars, it simply hardcodes con_forall to False! If I'm reading that correctly, that means that Haddock will never render the foralls in a GADT constructor's type signature, which feels rather strange.

harpocrates · 2019-02-02T17:45:14Z

You are right, this is the right way to fix things! I just want to get ahead of the Hi Haddock merge conflicts before merging this.

…

On Feb 2, 2019, at 9:37 AM, Ryan Scott ***@***.***> wrote: Looking at a53c131 <a53c131>, it looks like that commit tackles the problem in a much different way. Intead of using dataConUserTyVars, it simply hardcodes con_forall to False! If I'm reading that correctly, that means that Haddock will never render the foralls in a GADT constructor's type signature, which feels rather strange. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1016 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKRHAcN7t1jS1brJZBU0jGxzdsib0XLhks5vJczmgaJpZM4afphn>.

harpocrates · 2019-02-04T16:40:47Z

@RyanGlScott I've split out of wip/hi-haddock and into ghc-head the changes I was worried would conflict. Do you mind rebasing this onto ghc-head?

RyanGlScott · 2019-02-04T16:46:10Z

I take it, then, that you don't want me to target this PR against ghc-8.6 (as it is currently)?

harpocrates · 2019-02-04T16:47:44Z

Yep, that’s right. Sorry for all of the hassle :(

…

On Feb 4, 2019, at 8:46 AM, Ryan Scott ***@***.***> wrote: I take it, then, that you don't want me to target this PR against ghc-8.6 (as it is currently)? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1016 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKRHAXDktv56JvPpE-qE0QymK9YN1R7Sks5vKGPTgaJpZM4afphn>.

RyanGlScott · 2019-02-04T16:51:30Z

That's fine—I'm just wondering if this could be cherry-picked into ghc-8.6, since @kosmikus was asking for this in well-typed/generics-sop#92 (comment).

harpocrates · 2019-02-04T16:54:53Z

Oh I see. Sigh.

I guess we can merge this now in ghc-8.6 and deal with the conflicts when next merging into ghc-head. Do you know if there is even a new Haddock release planned for the 8.6 release? (Is there even another 8.6 release planned?) I haven't heard anything from Ben.

RyanGlScott · 2019-02-04T16:59:55Z

Perhaps I'm operating under a misconception. I was under the impression that Haddock releases occurred independently of GHC, and that the ghc-8.6 branch was the main upstream for that release cycle (while ghc-head tracks a separate development cycle that's geared specifically to GHC HEAD's needs). Moreover, I was imagining that, at periodic intervals, there would be a mass merging of commits from one branch to the other. But perhaps this is not the case?

harpocrates · 2019-02-04T17:11:51Z

I was under the impression that Haddock releases occurred independently of GHC

That's not the case. Since most people get Haddock from their GHC installation (NB: the binary-dists that get released include a Haddock executable), I've been syncing releases up with GHC releases. I guess we could release more often, but I doubt people would remember to install a newer version of Haddock. And even if they did:

Cabal/Stack have some magic around trying to guess the right Haddock executable for cabal/stack haddock, which I don't think would pick up the newer executables (unless explicitly directed to do so). I haven't tested this...
The Haddock distributed with GHC is built under slightly different circumstances (for now at least, see flag(in-ghc-tree)), so it's nice to minimize the "flavours" of Haddock executables floating around in the wild. I hope to get rid of this once the Make system disappears and only Hadrian remains.

...and that the ghc-8.6 branch was the main upstream for that release cycle (while ghc-head tracks a separate development cycle that's geared specifically to GHC HEAD's needs). Moreover, I was imagining that, at periodic intervals, there would be a mass merging of commits from one branch to the other.

This part is spot on. We regularly merge branches for older release cycles into ones for newer release cycles. This sort of merge is generally not very pleasant though.

If you have any ideas for improving this state of affairs, I'm all ears. 😄

RyanGlScott · 2019-02-04T17:25:00Z

I wasn't aware of the nuances that go into Haddock releases, thanks for letting me know. I certainly don't want to create more work for you, so forget I said anything about cherry-picking into ghc-8.6. We'll have to wait slightly longer to use this feature with a non-HEAD compiler, but good things take time anyway :)

I'll see if I can wrangle GitHub to change the branch I'm targeting against.

RyanGlScott · 2019-02-04T18:02:19Z

It looks like the haddock repo disallows force-pushing (even for branches), so rebasing this as-is proves to be trickier than I thought. I think I'll just opt to close this and open a fresh PR against ghc-head.

RyanGlScott · 2019-02-04T18:04:18Z

Closing in favor of #1022.

harpocrates and others added 9 commits November 11, 2018 20:01

Rename 'NewOcean' theme to 'Linuwial'

a7a5cce

Add blockquote styling

8c785e2

Matches b71da1feabf33efbbc517ac376bb690b5a604c2f from hackage-server. Fixes #967.

More uniform handling of forall's in HTML/LaTeX

a36ab92

* don't forget to print explicit `forall`'s when there are arg docs * when printing an explicit `forall`, print all tyvars Fixes #973

Load plugins when compiling each module (#983)

39251d3

* WIP: Load (typechecker) plugins from language pragmas * Revert "Load plugins when starting a GHC session (#905)" This reverts commit 72d82e5. * Simplify plugin initialization code

Print kinded tyvars in constructors for Hoogle (#993)

a650450

Fixes #992

Keep forall on H98 existential data constructors (#1003)

53997f3

The information about whether or not there is a source-level `forall` is already available on a `ConDecl` (as `con_forall`), so we should use it instead of always assuming `False`! Fixes #1002.

Fix #1004 with a pinch of dropForAlls

fd56ac4

Loosen 'QuickCheck' and 'hspec' bounds

7abad07

It looks like the new versions don't cause any breakage and loosening the bounds helps deps fit in one stack resolver.

Fix #1015 with dataConUserTyVars

d044f64

RyanGlScott mentioned this pull request Feb 2, 2019

Hackage Haddocks give incorrect signatures well-typed/generics-sop#92

Closed

RyanGlScott changed the base branch from ghc-8.6 to ghc-head February 4, 2019 17:25

RyanGlScott mentioned this pull request Feb 4, 2019

Fix #1015 with dataConUserTyVars #1022

Merged

RyanGlScott closed this Feb 4, 2019

RyanGlScott deleted the T1015 branch February 4, 2019 18:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix #1015 with dataConUserTyVars #1016

Fix #1015 with dataConUserTyVars #1016

Uh oh!

RyanGlScott commented Feb 2, 2019

Uh oh!

harpocrates commented Feb 2, 2019

Uh oh!

RyanGlScott commented Feb 2, 2019

Uh oh!

harpocrates commented Feb 2, 2019 via email

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019 via email

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

Uh oh!

Fix #1015 with dataConUserTyVars #1016

Fix #1015 with dataConUserTyVars #1016

Uh oh!

Conversation

RyanGlScott commented Feb 2, 2019

Uh oh!

harpocrates commented Feb 2, 2019

Uh oh!

RyanGlScott commented Feb 2, 2019

Uh oh!

harpocrates commented Feb 2, 2019 via email

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019 via email

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

harpocrates commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

RyanGlScott commented Feb 4, 2019

Uh oh!

Uh oh!