Opened 7 years ago

Closed 4 years ago

#5395 closed bug (fixed)

Context reduction stack overflow without undecidable instances

Reported by: guest Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.0.4
Keywords: type family, termination Cc: oleg@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

When using type families whose reduction surely terminates (and which are accepted without undecidable instances) GHC still seems to set the context stack reduction limit. See the included code.

The fixed limit on context stack size prevents us from doing type-level arithmetic on arbitrarily-sized type-level numerals.

If the context-size limit is applied whether undecidable instance extension is used or not, one may wonder of the purpose of the undecidable instance extension.

Attachments (1)

CMP.hs (767 bytes) - added by guest 7 years ago.
Haskell Source code with the tests

Download all attachments as: .zip

Change History (12)

Changed 7 years ago by guest

Attachment: CMP.hs added

Haskell Source code with the tests

comment:1 Changed 7 years ago by simonpj

The trouble is that some module you import may have used -XUndecidableInstances, and that could cause your compilation to diverge, even if you are very well behaved.

It'd be fine to set the threshold to a much larger value though. How big does it have to be to avoid problems in your application? Then multiply by 10?

Simon

comment:2 Changed 7 years ago by guest

I'm fine with the increased threshold. The largest context-stack--limit I used is 180.

It would be nice to include the phrase

The trouble is that some module you import may have used -XUndecidableInstances, and that could cause your compilation to diverge, even if you are ery well behaved.

in the documentation (in the section about UndecidableInstances).

comment:3 Changed 7 years ago by simonpj@…

commit d3a31e480ace72a82a301ffb11fd5f73d9ede5bd

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Fri Sep 2 09:07:46 2011 +0100

    Increase the "context stack depth" to 200 (from 20)
    
    This parameter controls the allowed depth of reasoning in the
    type constraint solver.  Perfectly well-behaved programs can
    use deep stacks, and 20 is obviously too small.  (Indeed, if
    you don't have UndecidableInstances, the constraint solver
    is supposed to terminate, so no limit should be needed.)
    
    Responding to Trac #5395 this patch increases the default
    to 200.

 includes/HaskellConstants.hs |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

comment:4 Changed 7 years ago by simonpj

Resolution: fixed
Status: newclosed

OK, done.

comment:5 Changed 5 years ago by nomeata

difficulty: Unknown
Resolution: fixed
Status: closednew

I am just implementing separate counters for type family applications and constraints solving. Should I change the constraint limit back to 20 then, and leave the type family application limit at 200? Or even higher?

(Reopening as some discussion is required.)

comment:6 Changed 5 years ago by nomeata

comment:7 Changed 4 years ago by jystic

I just ran in to this problem using the protobuf library with GHC 7.8.3, it seems that the constant limit has been changed back to 20?

Compiling with -fcontext-stack=37 solves the problem in my case.

comment:8 Changed 4 years ago by simonpj

We now have -fcontext-stack=N (for type classes) and -ftype-function-depth=N (for type functions). I suspect that when splitting the two we put the type-class one back to 20.

I'll increase it to 100.

Simon

comment:9 Changed 4 years ago by nomeata

I suspect that when splitting the two we put the type-class one back to 20.

Correct.

comment:10 Changed 4 years ago by Simon Peyton Jones <simonpj@…>

In c96c64fae0152bc53f48634d0ddd310ef4bc0105/ghc:

Increase -fcontext-stack=N default to 100

This addresses Trac #5395

comment:11 Changed 4 years ago by simonpj

Resolution: fixed
Status: newclosed

Done!

Note: See TracTickets for help on using tickets.