Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,246
    • Issues 5,246
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 574
    • Merge requests 574
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #16876
Closed
Open
Issue created Jun 26, 2019 by Ryan Scott@RyanGlScottMaintainer

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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking