Opened 2 years ago

Closed 2 years ago

#14000 closed bug (fixed)

Out of scope errors with type families do not mention scope

Reported by: EyalLotem Owned by:
Priority: normal Milestone: 8.2.2
Component: Compiler Version: 8.0.2
Keywords: TypeFamilies Cc: RyanGlScott, simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Poor/confusing error message Test Case: typecheck/should_fail/T14000
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by bgamari)

{-# LANGUAGE TypeFamilies #-}
class C a where
    type T a
    c :: a -> T a
main = c noSuchThing

yields:

test_bad_error.hs:6:1: error:
    • Couldn't match expected type ‘T a’ with actual type ‘T a0’
      NB: ‘T’ is a type function, and may not be injective
      The type variable ‘a0’ is ambiguous
    • In the ambiguity check for the inferred type for ‘main’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      When checking the inferred type
        main :: forall a. T a

This makes simple out-of-scope error seem very perplexing and is a huge regression in error quality.

Change History (9)

comment:1 Changed 2 years ago by RyanGlScott

Cc: RyanGlScott added
Keywords: TypeFamilies added
Type of failure: None/UnknownPoor/confusing error message

Indeed, the error message in GHC 7.10.3 and earlier was simply:

$ /opt/ghc/7.10.3/bin/ghci Bug.hs
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( Bug.hs, interpreted )

Bug.hs:5:10: Not in scope: ‘noSuchThing’
Failed, modules loaded: none.

comment:2 Changed 2 years ago by RyanGlScott

Interestingly, I tried a random commit from before GHC 8.0.1 (707b2be97539b83efb91cd9f17f94c91397ad2b4), and I received more information in the error messages:

$ inplace/bin/ghc-stage2 --interactive ../Bug.hs
GHCi, version 8.0.0.20160109: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Main             ( ../Bug.hs, interpreted )

../Bug.hs:5:1: error:
    • Couldn't match expected type ‘T a’ with actual type ‘T a0’
      NB: ‘T’ is a type function, and may not be injective
      The type variable ‘a0’ is ambiguous
    • In the ambiguity check for the inferred type for ‘main’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      When checking the inferred type
        main :: forall a. T a

../Bug.hs:5:10: error: Variable not in scope: noSuchThing

So at separate commits, GHC (1) started complaining about this Couldn't match expected type business (which is questionable), and (2) stopped complaining about noSuchThing not being in scope (which is definitely wrong). I've yet to figure out which commits are responsible.

comment:3 Changed 2 years ago by RyanGlScott

Version: 8.0.18.0.2

Actually, the Variable not in scope error was dropped somewhere between 8.0.1 and 8.0.2, since in 8.0.1, you get:

$ /opt/ghc/8.0.1/bin/ghci ../Bug.hs
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main             ( ../Bug.hs, interpreted )

../Bug.hs:5:1: error:
    • Couldn't match expected type ‘T a’ with actual type ‘T a0’
      NB: ‘T’ is a type function, and may not be injective
      The type variable ‘a0’ is ambiguous
    • In the ambiguity check for the inferred type for ‘main’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      When checking the inferred type
        main :: forall a. T a

../Bug.hs:5:10: error: Variable not in scope: noSuchThing

But in GHC 8.0.2:

$ /opt/ghc/8.0.2/bin/ghci ../Bug.hs
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main             ( ../Bug.hs, interpreted )

../Bug.hs:5:1: error:
    • Couldn't match expected type ‘T a’ with actual type ‘T a0’
      NB: ‘T’ is a type function, and may not be injective
      The type variable ‘a0’ is ambiguous
    • In the ambiguity check for the inferred type for ‘main’
      To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
      When checking the inferred type
        main :: forall a. T a
Last edited 2 years ago by RyanGlScott (previous) (diff)

comment:4 Changed 2 years ago by RyanGlScott

Cc: simonpj added

The Variable not in scope error was dropped in 5662ceaeb4da4fdee0f9fc01f72855168471377f (Improve error handling in TcRnMonad).

comment:5 Changed 2 years ago by RyanGlScott

The Couldn't match expected type error snuck in after fb7b6922573af76a954d939c85e6af7c39a19896 (Treat out-of-scope variables as holes).

comment:6 Changed 2 years ago by Simon Peyton Jones <simonpj@…>

In 452755de/ghc:

Do not discard insolubles in implications

Trac #14000 showed up two errors

* In TcRnTypes.dropInsolubles we dropped all implications, which
  might contain the very insolubles we wanted to keep.  This was
  an outright error, and is why the out-of-scope error was actually
  lost altogether in Trac #14000

* In TcSimplify.simplifyInfer, if there are definite (insoluble)
  errors, it's better to suppress the following ambiguity test,
  because the type may be bogus anyway.  See TcSimplify
  Note [Quantification with errors].  This fix seems a bit clunky,
  but it'll do for now.

comment:7 Changed 2 years ago by simonpj

Resolution: fixed
Status: newclosed
Test Case: typecheck/should_fail/T14000

Excellent report; fixed.

comment:8 Changed 2 years ago by simonpj

Milestone: 8.2.2
Status: closedmerge

Might be worth merging.

comment:9 Changed 2 years ago by bgamari

Description: modified (diff)
Status: mergeclosed
Note: See TracTickets for help on using tickets.