Opened 18 months ago

Closed 16 months ago

Last modified 14 months ago

#8278 closed feature request (fixed)

Improve error message when the same type is imported from two different library versions

Reported by: Yuras Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.6.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: typecheck/should_fail/tcfail182
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

When a package indirectly depends on different versions of the same library, ghc reports cryptic error:

Couldn't match expected type `ByteString'
            with actual type `bytestring-0.9.2.1:Data.ByteString.Internal.ByteString'

Error contains fully qualified type with package name and version only when the type is imported from different versions on the library, so looks like ghc knows what is wrong.

Is it possible to add something like the next:

Note: ByteString is imported from different package versions:
bytestring-0.9.2.1 and bytestring-0.10.0.1

It is inspired by a number of StackOverflow questions (e.g. http://stackoverflow.com/questions/12576817/couldnt-match-expected-type-with-actual-type-error-when-using-codec-bmp/12577025#12577025, http://stackoverflow.com/questions/18767086/bytestring-to-lazy-text-and-vice-versa/18769431?noredirect=1#comment27676563_18769431)

Change History (6)

comment:1 Changed 18 months ago by Yuras

  • Type changed from bug to feature request

comment:2 Changed 18 months ago by Yuras

And related request: in the same situation (two versions of the same library) when instance of class A for bytestring-0.9.2.1:Data.ByteString.Internal.ByteString is in scope, but the instance for ByteString is not in scope, is it possible to add a special note?

Realworld case: http://stackoverflow.com/questions/11068272/acid-state-monadstate-instance-for-update

comment:3 Changed 16 months ago by Simon Peyton Jones <simonpj@…>

In 2403fa102559e81d665838a62b2a5de3229a9783/ghc:

Improve printing of errors when the tycons look the same

See Trac #8278.  Example new message:

    Couldn't match expected type ‛T8278a.Maybe’
                with actual type ‛Maybe a0’
    NB: ‛T8278a.Maybe’ is defined in ‛T8278a’
        ‛Maybe’ is defined in ‛Data.Maybe’ in package ‛base’
    In the first argument of ‛f’, namely ‛Nothing’

The "NB" is the new bit
Version 1, edited 16 months ago by simonpj (previous) (next) (diff)

comment:4 Changed 16 months ago by Simon Peyton Jones <simonpj@…>

In 9ca32193a82218c18a633d1ae505248d65ef17a4/testsuite:

Wibbles following fix to Trac #8278

The error message for ghci052 and ghci053 are (still)
terrible, because there is shadowing going on in the
interactive context.  But that's a separate matter.

comment:5 Changed 16 months ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed
  • Test Case set to typecheck/should_fail/tcfail182

Good idea. Much improved now I think:

    Couldn't match expected type ‛T8278a.Maybe’
    with actual type ‛Maybe a0’
    NB: ‛T8278a.Maybe’ is defined in ‛T8278a’
        ‛Maybe’ is defined in ‛Data.Maybe’ in package ‛base’
    In the first argument of ‛f’, namely ‛Nothing’

However implementing the idea in Comment 2 is much harder. If you think it's important and/or you trip over it a lot in practice, please open a new ticket.

Simon

comment:6 Changed 14 months ago by Simon Peyton Jones <simonpj@…>

In 322b48b92b93e1250b360d21873fa9f31c142403/ghc:

Further improve the "same-occurrence" error messages (Trac #8278)

Sometimes we actually have a good SrcSpan for the type constructor
and reporting that is better than just reporting which module it
was defined on
Note: See TracTickets for help on using tickets.