[GHC] #14801: Multiple error messages confusing.

GHC ghc-devs at haskell.org
Mon Feb 12 22:31:52 UTC 2018


#14801: Multiple error messages confusing.
-------------------------------------+-------------------------------------
        Reporter:  augustss          |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.2
      Resolution:                    |             Keywords:
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:                    |
-------------------------------------+-------------------------------------
Description changed by augustss:

Old description:

> More often than not, ghc reports very confusing errors when you use an
> undefined (lens) variable.  The problem is that an undefined identifier
> generates subsequent type errors, and some of these type errors might be
> reported before the undefined message.  When the error list has hundreds
> of messages it can be very time consuming to find the real error.
>
> Please add an error reporting mode that does not report type errors when
> there are undefined variables.
>
> Here's a sample message:
>
> {{{
> tests/OneDUram.hs:160:5: error:
>     • Couldn't match type ‘(Vec
>                               NumRegFiles (DelayReg.DelayReg 2
> OneDUValues)
>                             -> f0 (Vec NumRegFiles (DelayReg.DelayReg 2
> OneDUValues)))
>                            -> OneDUState -> f0 OneDUState’
>                      with ‘Vec n1 a0’
>       Expected type: Vec n1 a0
>         Actual type: LensLike'
>                        f0 OneDUState (Vec NumRegFiles (DelayReg.DelayReg
> 2 OneDUValues))
>     • Probable cause: ‘osRegFileBP’ is applied to too few arguments
>       In the first argument of ‘(^.)’, namely ‘osRegFileBP’
>       In the first argument of ‘(.~)’, namely
>         ‘osRegFileBP ^. ix 0 . atDelay 1’
>       In the second argument of ‘(&)’, namely
>         ‘osRegFileBP ^. ix 0 . atDelay 1
>            .~ fromList (mkTensor val "r0" [8])’
>     |
> 160 |   & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8])
>     |     ^^^^^^^^^^^
>
> tests/OneDUram.hs:160:23: error:
>     Variable not in scope:
>       atDelay
>         :: Integer
>            -> (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)
>                -> Constant
>                     (LensLike f OneDUState OneDUState b0 (Vec n0
> OneDUValue)) b'0)
>            -> a0
>            -> Constant
>                 (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue))
> a0
>     |
> 160 |   & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8])
>     |                       ^^^^^^^
>
> tests/OneDUram.hs:160:36: error:
>     • No instance for (GHC.TypeNats.KnownNat n0)
>         arising from a use of ‘fromList’
>     • In the second argument of ‘(.~)’, namely
>         ‘fromList (mkTensor val "r0" [8])’
>       In the second argument of ‘(&)’, namely
>         ‘osRegFileBP ^. ix 0 . atDelay 1
>            .~ fromList (mkTensor val "r0" [8])’
>       In the expression:
>         oneDU & osDbgInstrs .~ Just instrs2
>           & osRegFileBP ^. ix 0 . atDelay 1
>               .~ fromList (mkTensor val "r0" [8])
>     |
> 160 |   & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8])
>     |                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> }}}
>
> I only want to see the second message.

New description:

 More often than not, ghc reports very confusing errors when you use an
 undefined (lens) variable.  The problem is that an undefined identifier
 generates subsequent type errors, and some of these type errors might be
 reported before the undefined message.  When the error list has hundreds
 of messages it can be very time consuming to find the real error.

 Please add an error reporting mode that does not report type errors when
 there are undefined variables.

--

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


More information about the ghc-tickets mailing list