-
Notifications
You must be signed in to change notification settings - Fork 236
Conversation
I'm currently relying on Travis to validate the test suite, since I'm unable to run it myself:
@harpocrates, do you know what might be causing this? |
I was not aware of If your
Not sure why Travis is taking so long to start the job. Perhaps I've been hammering CI with too much lately. I'll race Travis to test/accept locally. |
Unfortunately,
|
It only works on |
Ack, reading is hard. Sorry for being dense. At least now it's failing with a different error:
|
Looks like the same error message to me... However, this time you should have a slightly more helpful |
Ah, indeed I do!
OK, now I think I see what's going on. I had build GHC using the |
Just ran tests locally, and it looks like everything already passes. 😄 I'll wait for CI to catch up before merging though. Once Hi Haddock gets merged, it'll be worth combing over |
Woohoo! I managed to get the testsuite to pass just as you posted that :) |
CI agreed this doesn't break anything, so I merged. Thanks again Ryan for all of these subtle fixes - they are very much appreciated. |
(This is a second attempt at #1016, but targeted against
ghc-head
this time.)The central trick in this patch is to use
dataConUserTyVars
instead ofuniv_tvs ++ ex_tvs
, which displays theforall
s 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 frombase
which might change in the future).