Opened 11 months ago

Closed 11 months ago

Last modified 11 months ago

#9153 closed bug (fixed)

TcCoercible test is failing with context reduction stack overflow

Reported by: ezyang Owned by:
Priority: low Milestone:
Component: Test Suite Version: 7.9
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Here is the error:

TcCoercible.hs:62:12:
    Context reduction stack overflow; size = 21
    Use -fcontext-stack=N to increase stack size to N
      Coercible Int Int
    In the expression: coerce
    In the first argument of ‘print’, namely
      ‘(coerce $ (FixEither (Left age) :: FixEither Age) ::
          Either Int (FixEither Int))’
    In a stmt of a 'do' block:
      print
        (coerce $ (FixEither (Left age) :: FixEither Age) ::
           Either Int (FixEither Int))

I do not know enough to know if bumping the stack size is correct.

Additionally, when run as GHCi I get:

=====> TcCoercible(ghci) 2784 of 3970 [0, 7, 0] 
cd ./typecheck/should_run && '/home/hs01/ezyang/ghc-validate/inplace/bin/ghc-stage2' -fforce-re
comp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history Tc
Coercible.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS   <TcCoercible.genscript 1>TcCo
ercible.interp.stdout 2>TcCoercible.interp.stderr
Actual stderr output differs from expected:
--- /dev/null   2014-02-15 17:35:19.578872448 -0800
+++ ./typecheck/should_run/TcCoercible.run.stderr       2014-05-29 16:27:30.476701835 -0700
@@ -0,0 +1,2 @@
+
+TcCoercible:7:30: Not in scope: ‘Main.main’

Change History (4)

comment:1 Changed 11 months ago by nomeata

This must be collateral damage from #9117 (7e78faf033405bd5f3b6b787343c98e33d767bda/ghc, I just wonder it validated for me back then... I’m rebuilding my tree to find out.

The discussion which behaviour is better (around 9117#comment:21) concluded that recursive newtypes are going to be treated novercally, and otherwise the new behaviour is better.

comment:2 Changed 11 months ago by Joachim Breitner <mail@…>

In 5a392ca14b3698d1be5166dd7a6a40b268e948e5/ghc:

Disable FixEither tests in TcCoercible

This fixes #9153. It has not been noticed before because this
TcCoercible does not run with "make fast=YES"

comment:3 Changed 11 months ago by nomeata

  • Resolution set to fixed
  • Status changed from new to closed

Too bad that travis’s timelimit prevents us from running the tests without fast=Yes, otherwise I would have noticed this much earlier.

comment:4 Changed 11 months ago by simonpj

Just to be clear, the relevant test is this:

newtype FixEither a = FixEither (Either a (FixEither a)) deriving Show 

-- And then try
--   Coercible (FixEither Age) (Either Int  (FixEither Int))
--   Coercible (Either Int (FixEither Age)) (FixEither Age) 

It is entirely moot whether these two "should" work or not. But #9117 suggests not.

Note: See TracTickets for help on using tickets.