[GHC] #15321: Typed holes in Template Haskell splices produce bewildering error messages

[GHC]

#15321: Typed holes in Template Haskell splices produce bewildering error messages
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.8.1
       Component:  Template Haskell  |              Version:  8.4.3
      Resolution:                    |             Keywords:  TypedHoles
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Poor/confusing    |  Unknown/Multiple
  error message                      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by mgsloan):

 Ah, that makes sense Simon, thanks for the input!

 I have a concern with using `tryTcDiscardingErrors` here - it could hide
 problems.  Errant omission of output is hard to notice in a mechanism like
 hole fitting - you would need to somehow notice a pattern of omission.
 Limiting the number of results also contributes to this.

 Based on this reasoning, here's what I'm thinking should be done:

 * First, the implementation you suggest.  I'm not sure where things are in
 the release process, but having holes be so broken in GHCi isn't so good
 (https://ghc.haskell.org/trac/ghc/ticket/15202), and a change related to
 your suggestion would fix it.

 * In a subsequent change, using `tryTc` and recording the errors that are
 encountered, while still getting results for hole fitting.  Then,
 including one of the exceptions as a "Please report this as a GHC bug"
 type of message.  This way, we get hole fitting results, but errors like
 this get noticed and resolved.

 Breaking it up into these 2 steps is mainly motivated by the potential for
 the first portion to be included in the release.

 Coincidentally, before I read your comment I implemented a change that
 catches errors for the entire hole fitting process, rather than just
 portions - https://phabricator.haskell.org/D4908 .  I'm favoring
 abandoning that approach and doing this more fine-grained catching.

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