Opened 2 years ago

Last modified 8 months ago

#13834 new bug

Error cascade with type applications

Reported by: mpickering Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: TypeApplications, TypeErrorMessages Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #12794 Differential Rev(s):
Wiki Page:

Description

Using type applications with an out of scope identifier causes an unfortunate error cascade.

foo = notInScope @Bool

Leads to the right out of scope error but also an error about using type application when notInScope is not a polytype. I think the second error should be suppressed.

t.hs:4:7: error: Variable not in scope: notInScope
  |
4 | foo = notInScope @Bool
  |       ^^^^^^^^^^

t.hs:4:7: error:
    • Cannot apply expression of type ‘t1’
      to a visible type argument ‘Bool’ notInScope
    • In the expression: notInScope @Bool
      In an equation for ‘foo’: foo = notInScope @Bool
  |
4 | foo = notInScope @Bool
  |       ^^^^^^^^^^^^^^^^

Change History (8)

comment:1 Changed 2 years ago by simonpj

Here is what is happening:

  • The `Cannot apply expression..." error is spat out immediately, during constraint generation, not by TcErrors
  • The Variable not in scope.. error is deferred; we spit out a constraint (a CHoleCan in fact). The constraint solver does its work; doing so will not solve the CHoleCan, but it often /does/ figure out what type the out-of-scope variable should have. The error is finally reported by TcErrors, when it reports errors from unsolved constraints

Fixing this would be possible but fiddly. The obvious thing would be to add a new form of constraint, or generalise CHoleCan, to allow the "Cannot apply" error to be deferred.

Then the error-message-prioritisation scheme in TcErrors could give the out-of-scope error priority over the cannot-apply one.

If we did this, it should probably be just part of a generic way of deferring error messages. There are othe errors that are spat out immediately rather than going through the constraint solver.

Last edited 2 years ago by simonpj (previous) (diff)

comment:2 Changed 2 years ago by simonpj

Keywords: TypeErrorMessages added

comment:3 Changed 2 years ago by goldfire

Keywords: newcomer removed

If I'm daunted by fixing it, it's not for a newcomer.

comment:4 Changed 16 months ago by RyanGlScott

See #12794 for the -fdefer-type-errors version of this issue.

comment:5 Changed 8 months ago by RyanGlScott

As dbaynard noted in https://ghc.haskell.org/trac/ghc/ticket/12092#comment:4, things are even worse on GHC 8.6 than they used to be. That is, while you'd get these errors on GHC 8.4.4:

$ /opt/ghc/8.4.4/bin/ghc -XTypeApplications -e "notInScope @Bool"

<interactive>:0:1: error: Variable not in scope: notInScope

<interactive>:0:1: error:
    • Cannot apply expression of type ‘t1’
      to a visible type argument ‘Bool’
    • In the expression: notInScope @Bool
      In an equation for ‘it’: it = notInScope @Bool

You don't even get the Variable not in scope error on GHC 8.6.3:

$ /opt/ghc/8.6.3/bin/ghc -XTypeApplications -e "notInScope @Bool"

<interactive>:0:1: error:
    • Cannot apply expression of type ‘t1’
      to a visible type argument ‘Bool’
    • In the expression: notInScope @Bool
      In an equation for ‘it’: it = notInScope @Bool

comment:6 Changed 8 months ago by RyanGlScott

Ah, but the regression has disappeared on GHC HEAD!

$ ghc4/inplace/bin/ghc-stage2 -XTypeApplications -e "notInScope @Bool"

<interactive>:0:1: error: Variable not in scope: notInScope

<interactive>:0:1: error:
    • Cannot apply expression of type ‘t1’
      to a visible type argument ‘Bool’
    • In the expression: notInScope @Bool
      In an equation for ‘it’: it = notInScope @Bool

So... false alarm?

comment:7 Changed 8 months ago by simonpj

Well

  • I think it'd be better to suppress the "Cannot apply" error. That is what the origina ticket Description was asking for, and I think I can see how to do so. (Suppress the error in TcExpr.tcArgs if the fun is a HsUnboundVar.)
  • But a harder problem is that if you try with -fdefer-type-errors then we get
    bash$ ghc -c T13834.hs -fdefer-type-errors
    
    T13834.hs:5:7: error:
        • Cannot apply expression of type ‘t1’
          to a visible type argument ‘Bool’
        • In the expression: notInScope @Bool
          In an equation for ‘foo’: foo = notInScope @Bool
      |
    5 | foo = notInScope @Bool
      |       ^^^^^^^^^^^^^^^^
    
    The out-of-scope thing has turned into a warning, with deferred evidence. And rightly so in a way: you can run a program with an out-of-scope variable, provided you don't evaluate it. But the "cannot apply" error is still an error: it can't be deferred.

I have not thought deeply about this, but I can't see an easy fix.

comment:8 Changed 8 months ago by RyanGlScott

Sure, I didn't want to suggest that this ticket was fixed completely, only that the particular buglet that the Variable not in scope message disappearing (without -fdefer-type-errors) had been fixed.

Note: See TracTickets for help on using tickets.