From 39c7a90c464192797000b109ad6c90154f2ff3ea Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Wed, 10 Mar 2010 16:23:34 +0100 Subject: [PATCH] Don't inline == and /=. This is a hack to prevent problems caused by the derived Eq instances. This is not a real solution, though. --- "c\316\273ash/CLasH/Normalize.hs" | 7 +++++++ 1 file changed, 7 insertions(+) diff --git "a/c\316\273ash/CLasH/Normalize.hs" "b/c\316\273ash/CLasH/Normalize.hs" index 4a5ceec..2fc34c6 100644 --- "a/c\316\273ash/CLasH/Normalize.hs" +++ "b/c\316\273ash/CLasH/Normalize.hs" @@ -338,6 +338,13 @@ inlinenonreptop = everywhere ("inlinenonrep", inlinebind ((Monad.liftM not) . is -- doesn't seem to set all those names as "system names", we apply some -- guessing here. inlinetoplevel, inlinetopleveltop :: Transform +-- HACK: Don't inline == and /=. The default (derived) implementation +-- for /= uses the polymorphic version of ==, which gets a dictionary +-- for Eq passed in, which contains a reference to itself, resulting in +-- an infinite loop in transformation. Not inlining == is really a hack, +-- but for now it keeps things working with the most common symptom of +-- this problem. +inlinetoplevel expr@(Var f) | Name.getOccString f `elem` ["==", "/="] = return expr -- Any system name is candidate for inlining. Never inline user-defined -- functions, to preserve structure. inlinetoplevel expr@(Var f) | not $ isUserDefined f = do -- 2.30.2