…ue as well.
…by a program from Roman
We do not want the FloatOut pass to transform f = \x. e to f = let lvl = ... in \x.e The arity pinned on f isn't right any more; and see Note [Floating out of RHSs]. Core Lint is now spotting the arity lossage (for a letrec), which is how I spotted this bug. I also re-jigged the code around floatBind; it's a bit tidier now.
…ot be strict)
…ctness information (checked by Lint)
…pression By popular request, in a breakpoint it is possible now to inspect the result of the expression wrapped by the breakpoint. The user interface for this is right now preliminar; there is a new binding called '_result' at every breakpoint. Suggestions are welcome!
…onf 2.59c and later
It seems that when a program exits with open DLLs on Windows, the system attempts to shut down the DLLs, but it also terminates (some of?) the running threads. The RTS isn't prepared for threads to die unexpectedly, so it sits around waiting for its workers to finish. This bites in two places: ShutdownIOManager() in the the unthreaded RTS, and shutdownCapability() in the threaded RTS. So far I've modified the latter to notice when worker threads have died unexpectedly and continue shutting down. It seems a bit trickier to fix the unthreaded RTS, so for now the workaround for #926 is to use the threaded RTS.
I have added a check, and while there removed a few kludges in my code. Kudos to -dcore-lint for uncovering this. I think that this restriction could be lifted, if GHC.Base.breakpoint could have kind ?? -> ??. But is this a legal type? Does not look so to me.
We must traverse dependencies recursively if we encounter any [boot] modules in the dependencies.
… top level I added two new Core Lint checks in lintSingleBinding: 1. Check that the id's arity is equal to the number of arguments in its demand type, if it has a demand type at all (i.e., if demand analysis already happened). 2. Check that top-level or recursive binders aren't demanded.