#4952: Typechecking regression
----------------------------------------+-----------------------------------
Reporter: igloo | Owner: simonpj
Type: bug | Status: merge
Priority: highest | Milestone: 7.0.2
Component: Compiler (Type checker) | Version: 7.0.1
Keywords: | Testcase:
typecheck/should_compile/T4952
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------------+-----------------------------------
Changes (by simonpj):
* status: new => merge
* testcase: => typecheck/should_compile/T4952
Comment:
Fixed by
{{{
Thu Feb 17 14:09:21 GMT 2011 [email protected]
* Use "on the spot" solving for fundeps
When we spot an equality arising from a functional dependency,
we now use that equality (a "wanted") to rewrite the work-item
constraint right away. This avoids two dangers
Danger 1: If we send the original constraint on down the pipeline
it may react with an instance declaration, and in delicate
situations (when a Given overlaps with an instance) that
may produce new insoluble goals: see Trac #4952
Danger 2: If we don't rewrite the constraint, it may re-react
with the same thing later, and produce the same equality
again --> termination worries.
To achieve this required some refactoring of FunDeps.lhs (nicer
now!).
This patch also contains a couple of unrelated improvements
* A bad bug in TcSMonad.nestImplicTcS whereby the Tcs tyvars
of an outer implication were not untouchable inside
* Improved logging machinery for the type constraint solver;
use -ddump-cs-trace (probably with a wider default line width
-dppr-cols=200 or something)
M ./compiler/main/DynFlags.hs +2
M ./compiler/typecheck/TcCanonical.lhs -2 +76
M ./compiler/typecheck/TcInteract.lhs -134 +199
M ./compiler/typecheck/TcRnTypes.lhs -4 +3
M ./compiler/typecheck/TcSMonad.lhs -70 +44
M ./compiler/types/FunDeps.lhs -116 +173
}}}
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4952#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
