[GHC] #15815: problem with splicing type into constraint

[GHC]

#15815: problem with splicing type into constraint
-------------------------------------+-------------------------------------
        Reporter:  int-e             |                Owner:  RyanGlScott
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.6.2
       Component:  Template Haskell  |              Version:  8.6.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  GHC rejects       |  Unknown/Multiple
  valid program                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by RyanGlScott):

 * cc: goldfire (removed)
 * related:  #15760 =>
 * milestone:   => 8.6.2


Comment:

 You're right, I misspoke about #15760 fixing this issue. Forget I said
 anything about that.

 Your fix smells correct to me, and if there weren't any other extenuating
 circumstances, I'd endorse it as the one true solution. Unfortunately,
 there's a bit of a thorny issue in that this code no longer works on GHC
 8.6, and I don't see a simple way to work around the issue at the moment.
 We need to backport //something// to fix this, but the question is
 //what//.

 Alas, changing the way we desugar infix types to use `InfixT` would
 constitute a breaking change in practice, so I'm reluctant to backport
 that. There is quite a bit of code in the wild which, for better or worse,
 assumes that `InfixT` only ever appears in user written code (i.e.,
 `InfixT` never appears in desugared or reified TH ASTs). See
 [https://github.com/glguy/th-
 abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160
 this function] from `th-abstraction` as one example. I'm not sure what
 exactly would happen if we started feeding that function `InfixT`s, but I
 imagine that something or another would change at runtime, which would be
 awful for a point release.

 Therefore, I'm inclined to adopt the patch in comment:4 as a crude (and
 ideally, temporary) fix for this issue in an 8.6 point release (hopefully
 8.6.2), and work towards implementing your more robust solution for 8.8.
 Does that sound reasonable?

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15815#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler