- User Since
- Jan 8 2015, 11:07 PM (218 w, 6 d)
Fri, Mar 15
Wed, Mar 13
Tue, Mar 12
Thu, Mar 7
Wed, Mar 6
Mon, Mar 4
Feb 14 2019
@dfeuer is correct. (You'll notice that if you comment out the deriving stock instance Eq (Foo LiftedRep) part of the program, then it compiles, as it should.)
Feb 10 2019
This patch also exposes a dark corner in :info:
Feb 9 2019
UnliftedNewtypes have a mildly unpleasant interaction with Template Haskell reification:
Feb 8 2019
I'm not sure if this should count as a bug or not, but you also can't use record selectors with levity polymorphic fields:
Feb 7 2019
Another ticket to file after this patch lands: it seems that the symptoms of Trac #15883 aren't completely cured by this patch. In particular, this still panics:
Also, since it looks like most of the in-depth reviewing has quiesced, it would be worth migrating this patch over to GitLab, as it'll need to exist in MR format in order to be merged anyway.
Feb 6 2019
Jan 25 2019
On second thought, I think my comments in https://phabricator.haskell.org/D4777#151665 might be null and void, since kind-changing newtypes actually appear to be quite bogus. At the very least, permitting them allows me to write the following program, which segfaults:
I've been trying out this patch recently, and one thing keeps nagging me at the back of my mind: should Coercible be heterogeneously kinded? The reason I ask is that the UnliftedNewtypes extension lets you define "kind-changing" newtypes like this one:
Jan 17 2019
Jan 16 2019
Jan 9 2019
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.)
Jan 8 2019
I've migrated this over to GitLab in https://gitlab.haskell.org/ghc/ghc/merge_requests/90 (once it validates, I'll merge).
Jan 7 2019
This was migrated to GitLab in https://gitlab.haskell.org/ghc/ghc/merge_requests/48 and later merged in c121e33f9b039acf2ac6939af8bfafe593560039.
Jan 5 2019
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.
Dec 31 2018
Dec 28 2018
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:
Dec 27 2018
Dec 24 2018
Dec 21 2018
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.
Dec 20 2018
I'm reviewing this patch rather late it seems, but things appear to be progressing quite nicely! Some requests:
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.