GHC 8.10 backports?

[Andreas Klebinger]

Yes, only changing the rule did indeed cause regressions.
Whichwhen not including the string changes. I don't think it's worth
having one without the other.

But it seems you already backported this?
See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5263

Cheers
Andreas

Am 22/03/2021 um 07:02 schrieb Moritz Angermann:
> The commit message from
> https://gitlab.haskell.org/ghc/ghc/-/commit/f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495
> <https://gitlab.haskell.org/ghc/ghc/-/commit/f10d11fa49fa9a7a506c4fdbdf86521c2a8d3495>,
>
> makes the changes to string seem required. Applying the commit on its
> own doesn't apply cleanly and pulls in quite a
> bit of extra dependent commits. Just applying the elem rules appears
> rather risky. Thus will I agree that having that
> would be a nice fix to have, the amount of necessary code changes
> makes me rather uncomfortable for a minor release :-/
>
> On Mon, Mar 22, 2021 at 1:58 PM Gergő Érdi <gergo at erdi.hu
> <mailto:gergo at erdi.hu>> wrote:
>
>     Thanks, that makes it less appealing. In the original thread, I
>     got no further replies after my email announcing my "discovery" of
>     that commit, so I thought that was the whole story.
>
>     On Mon, Mar 22, 2021, 13:53 Viktor Dukhovni
>     <ietf-dane at dukhovni.org <mailto:ietf-dane at dukhovni.org>> wrote:
>
>         On Mon, Mar 22, 2021 at 12:39:28PM +0800, Gergő Érdi wrote:
>
>         > I'd love to have this in a GHC 8.10 release:
>         >
>         https://mail.haskell.org/pipermail/ghc-devs/2021-March/019629.html
>         <https://mail.haskell.org/pipermail/ghc-devs/2021-March/019629.html>
>
>         This is already in 9.0, 9.2 and master, but it is a rather
>         non-trivial
>         change, given all the new work that went into the String
>         case.  So I am
>         not sure it is small/simple enough to make for a compelling
>         backport.
>
>         There's a lot of recent activity in this space.  See also
>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5259
>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5259>>,
>         which is not
>         yet merged into master, and might still be eta-reduced one
>         more step).
>
>         I don't know whether such optimisation tweaks (not a bugfix)
>         are in
>         scope for backporting, we certainly need to be confident
>         they'll not
>         cause any new problems.  FWIW, 5259 is dramatically simpler...
>
>         Of course we also have
>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4890
>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4890>> in
>         much the
>         same territory, but there we're still blocked on someone
>         figuring out
>         what's going on with the 20% compile-time hit with T13056, and
>         whether
>         that's acceptable or not...
>
>         --
>             Viktor.
>         _______________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20210324/3a3cf886/attachment.html>