- User Since
- Jan 8 2015, 11:07 PM (210 w, 1 d)
Thu, Jan 17
Wed, Jan 16
Wed, Jan 9
That mkTyConKindRepBinds panic is bizarre. This suggests that GHC is trying to create Typeable bindings for the kind of Foo. But Typeable doesn't support type families (like Interpret), so it shouldn't be attempting to create those bindings in the first place! Perhaps the issue is GHC simply not recognizing this fact. (I've observed similar issues here, although I haven't managed to get that exact mkTyConKindRepBinds panic before.)
Tue, Jan 8
I've migrated this over to GitLab in https://gitlab.haskell.org/ghc/ghc/merge_requests/90 (once it validates, I'll merge).
Mon, Jan 7
This was migrated to GitLab in https://gitlab.haskell.org/ghc/ghc/merge_requests/48 and later merged in c121e33f9b039acf2ac6939af8bfafe593560039.
Sat, Jan 5
Sorry to add to your pile of TODOs, but I just noticed that this patch actually fixes a Trac ticket that's not listed in the Diff description: Trac #15883. Specifically, this test case:
This was landed in 17bd163566153babbf51adaff8397f948ae363ca.
Mon, Dec 31
Fri, Dec 28
Oops, ignore what I said in https://phabricator.haskell.org/D4777#151228. That isn't a bug at all. The reason that it's defaulting to LiftedRep with GHC 8.6+ is because I didn't enable -fprint-explicit-runtime-reps, and GHC's RuntimeRep defaulting became smarter in GHC 8.6.
I'm now 100% convinced this is due to a pre-existing bug in tcHsDeriv. Consider the following program:
Thu, Dec 27
Mon, Dec 24
Fri, Dec 21
I don't have a strong opinion on whether coerce should be levity polymorphic. I'd be fine with the more general type signature, but I'd also be fine with just making a copy of coerce with a levity polymorphic type (something like coerceLevPoly) and exporting it from Data.Coerce alongside coerce. Either way, I think we should have something levity polymorphic in Data.Coerce, especially since people are asking for this in Trac #13595.
Thu, Dec 20
I'm reviewing this patch rather late it seems, but things appear to be progressing quite nicely! Some requests:
Dec 20 2018
I think I've resolved all of @simonpj's concerns here—if no one says otherwise, I'll land this some time next week.
Dec 18 2018
- @simonpj's suggestion
To be perfectly honest, the error message regressions related to wildcards aren't as bad as I thought there were going to be. For the most part, we're just swapping uses of w with _, and although that can look odd in certain places, I don't think it's necessarily wrong. Personally speaking, I'd be quite fine with this state of affairs (even if it ends up making it into the final 8.8 release), as long as we make a ticket tracking how we could make small improvements.
Dec 17 2018
Don't forget to add an entry for this flag in docs/users_guide/using-warnings.rst!
Dec 15 2018
The CI is failing for reasons unrelated to this Diff. I'd recommend rebasing on top of master, since the issue has been fixed upstream.
Make sure to add an entry for this flag in docs/users_guide/using-warnings.rst (see Note [Documenting warning flags]).
Dec 14 2018
Looks good (aside from one quibble about grammar)
Dec 13 2018
Assuming it validates, LGTM.
Have you ran the test suite? Some tests' expected stderr files are almost certainly going to change as a result of this, so you need to accept the new stderr.
- Address @simonpj's comment
Dec 11 2018
Dec 10 2018
- @simonpj's suggested refactor
Actually, I did notice one more thing as I tried to adapt some code to this patch.
As far as the parts of the code that I'm qualified to review go, everything looks quite lovely. One minor comment inline.
Dec 7 2018
Dec 6 2018
Dec 5 2018
This issue wasn't really fixed at all—see https://ghc.haskell.org/trac/ghc/ticket/11621#comment:8. In light of this, adding a test case is premature, since the fact that that particular program typechecks is a coincidence.
Dec 4 2018
I've made a sweep of some minor code and documentation issues.
I'll do another sweep of the template-haskell-specific code in a bit, but first, let me respond to the test failures:
In that case, is this patch ready to be merged?
Dec 3 2018
Dec 1 2018
- One more @simonpj suggestion
My apologies for forgetting about this patch! We should indeed land this soon.
- @simonpj's suggestion from https://ghc.haskell.org/trac/ghc/ticket/15954#comment:7
Nov 30 2018
There we go.
Nov 29 2018
It looks like there's one test case that needs to be updated, per Harbormaster: