Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#13622 closed bug (fixed)

Regression: can't export constructor when conflicting, qualified constructor is also in scope

Reported by: RyanGlScott Owned by: mpickering
Priority: highest Milestone: 8.2.1
Component: Compiler Version: 8.2.1-rc2
Keywords: Cc: mpickering, Lemming
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D3515
Wiki Page:

Description

I ran into this regression when trying to compile the ersatz library with GHC 8.2.1-rc1. Here is a minimized example:

module Bug (Bits(Bits)) where

import qualified Data.Bits as Bits

newtype Bits = Bits Int

Compiling this with GHC 8.0.2 works fine, but with 8.2.1-rc1, you get this error:

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

Bug.hs:1:13: error:
    • Ambiguous occurrence ‘Bits’
      It could refer to either ‘Bits.Bits’,
                               imported qualified from ‘Data.Bits’ at Bug.hs:3:1-34
                            or ‘Bits’, defined at Bug.hs:5:1
    • In the export: Bits(Bits)
  |
1 | module Bug (Bits(Bits)) where
  |             ^^^^^^^^^^

Despite the fact that Bits isn't actually ambiguous, since the Bits from Data.Bits is qualified.

Change History (12)

comment:1 Changed 3 years ago by Iceland_jack

That example could be featured in a children's book

comment:2 Changed 3 years ago by mpickering

Does it work with HEAD? I think I fixed this in #13528

comment:3 Changed 3 years ago by RyanGlScott

I experience the same bug with GHC HEAD.

comment:4 Changed 3 years ago by Lemming

Cc: Lemming added

comment:5 Changed 3 years ago by mpickering

The problem is that name clash errors are reported too eagerly.

Solution.

  1. Extend ChildLookupResult to have a case for an ambiguous lookup
  2. Prefer other options to ambiguous lookup in the monoid instance.
  3. Use addNameClashErr when handling ChildLookupResult for the ambiguous case.

I need to look carefully at whether all the uses of ambiguous names are recoverable or whether they should all be deferred to later.

comment:6 Changed 3 years ago by mpickering

Owner: set to mpickering

comment:7 Changed 3 years ago by mpickering

Differential Rev(s): Phab:D3515
Priority: highhighest
Status: newpatch

comment:8 Changed 3 years ago by rwbarton

The problem is that name clash errors are reported too eagerly.

I guess you must know what you are talking about, but this sounds weird to me since I can't see what name clash there is in the original program.

comment:9 Changed 3 years ago by Ben Gamari <ben@…>

In 1829d26/ghc:

Implement sequential name lookup properly

Previously we would run all the monadic actions and then
combine their results. This caused problems if later actions
raised errors but earlier lookups suceeded. We only want to run later
lookups if the earlier ones fail.

Fixes #13622

Reviewers: RyanGlScott, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13622

Differential Revision: https://phabricator.haskell.org/D3515

comment:10 Changed 3 years ago by bgamari

Status: patchmerge

comment:11 Changed 3 years ago by bgamari

Resolution: fixed
Status: mergeclosed

comment:12 Changed 3 years ago by Lemming

Using ghc-8.2.0.20170505 my problems are gone.

Note: See TracTickets for help on using tickets.