GHC 8.8.1-alpha2's automatic enabling of -fobject-code breaks some doctest workflows (#16876) · Issues · Glasgow Haskell Compiler / GHC

GHC 8.8.1-alpha2's automatic enabling of -fobject-code breaks some doctest workflows

GHC 8.8.1-alpha2 features commit f8d24178, which automatically enables -fobject-code on any module that uses UnboxedTuples. An unfortunate side-effect of this change is that there are various doctest suites in the wild that break as a result of this change, such as the test suite in lens (https://github.com/ekmett/lens/issues/874).

To illustrate the issue, we'll need two files:

module A where

f :: Int
f = 1

{-# LANGUAGE UnboxedTuples #-}
module B where

import A

g :: Int
g = 1

-- |
--
-- >>> h == (f + g)
-- True
h :: Int
h = 2

(Note that B doesn't actually have to use unboxed tuples, it just has to enable the UnboxedTuples language extension.)

Next, I'll present a stripped-down version of the GHCi commands that doctest runs internally. Here is what happens when you run these commands on GHC 8.6.5:

$ /opt/ghc/8.6.5/bin/ghci A.hs B.hs
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 2] Compiling A                ( A.hs, interpreted )
[2 of 2] Compiling B                ( B.hs, interpreted )
Ok, two modules loaded.
λ> :m *B
λ> h == (f + g)
True

And here is what happens when you try these commands on GHC 8.8.1-alpha2:

$ /opt/ghc/8.8.1/bin/ghci A.hs B.hs
GHCi, version 8.8.0.20190613: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 2] Compiling A                ( A.hs, /tmp/ghc13236_0/ghc_2.o )
[2 of 2] Compiling B                ( B.hs, /tmp/ghc13236_0/ghc_4.o )
Ok, two modules loaded.
λ> :m *B
module 'B' is not interpreted; try ':add *B' first
λ> h == (f + g)

<interactive>:2:1: error: Variable not in scope: h :: Int

<interactive>:2:11: error: Variable not in scope: g :: Int

Since GHC enables -fobject-code internally, that causes the module 'B' is not interpreted; try ':add *B' first message to appear whenever one attempts to load a module in interpreted mode with :m * (the same thing also happens in GHC 8.6.5 if you pass -fobject-code explicitly, whereas it happens implicitly with 8.8.1-alpha2). Moreover, the :add *B suggestion doesn't fix the issue.

GHC 8.8.1-alpha2 features commit f8d24178f30b7837b35a9ea328bc6f520092ff08, which automatically enables `-fobject-code` on any module that uses `UnboxedTuples`. An unfortunate side-effect of this change is that there are various `doctest` suites in the wild that break as a result of this change, such as the test suite in `lens` (https://github.com/ekmett/lens/issues/874).

To illustrate the issue, we'll need two files:

```hs
module A where

f :: Int
f = 1
```
```hs
{-# LANGUAGE UnboxedTuples #-}
module B where

import A

g :: Int
g = 1

-- |
--
-- >>> h == (f + g)
-- True
h :: Int
h = 2
```

(Note that `B` doesn't actually have to _use_ unboxed tuples, it just has to enable the `UnboxedTuples` language extension.)

Next, I'll present a stripped-down version of the GHCi commands that `doctest` runs internally. Here is what happens when you run these commands on GHC 8.6.5:

```
$ /opt/ghc/8.6.5/bin/ghci A.hs B.hs
GHCi, version 8.6.5: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 2] Compiling A                ( A.hs, interpreted )
[2 of 2] Compiling B                ( B.hs, interpreted )
Ok, two modules loaded.
λ> :m *B
λ> h == (f + g)
True
```

And here is what happens when you try these commands on GHC 8.8.1-alpha2:

```
$ /opt/ghc/8.8.1/bin/ghci A.hs B.hs
GHCi, version 8.8.0.20190613: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 2] Compiling A                ( A.hs, /tmp/ghc13236_0/ghc_2.o )
[2 of 2] Compiling B                ( B.hs, /tmp/ghc13236_0/ghc_4.o )
Ok, two modules loaded.
λ> :m *B
module 'B' is not interpreted; try ':add *B' first
λ> h == (f + g)

<interactive>:2:1: error: Variable not in scope: h :: Int

<interactive>:2:11: error: Variable not in scope: g :: Int
```

Since GHC enables `-fobject-code` internally, that causes the `module 'B' is not interpreted; try ':add *B' first` message to appear whenever one attempts to load a module in interpreted mode with `:m *` (the same thing also happens in GHC 8.6.5 if you pass `-fobject-code` explicitly, whereas it happens implicitly with 8.8.1-alpha2). Moreover, the `:add *B` suggestion doesn't fix the issue.