These responses are helpful, thanks. Is there a primer for how to read the output? Or a small function that produces the output that I could quickly reverse engineer? There is a suggestion to look at the core before and after my patch. Is there a certain phase I should look at? What should I look for? And where in the GHC code base should I start looking to understand this better? Sorry if these questions seem too easy -- I'm just out of my element here. My hunch is that I need to update something in the strictness analyzer to look through/around/beyond coercions somewhere. Any ideas as to what that might be would be helpful! :) Thanks, Richard On Nov 29, 2015, at 2:49 PM, Ben Gamari <ben@smart-cactus.org> wrote:
Richard Eisenberg <eir@cis.upenn.edu> writes:
Hi devs,
On my kind=type branch (D808), I have this test failure for stranal/sigs/UnsatFun:
Hmmm. I was curious and so took the opportunity to do a bit of digging. This likely isn't helpful but you never know...
-UnsatFun.g: <B,1*U(U)>b +UnsatFun.g: <L,U(U)>
It looks like the strictness analyzer can no longer see that `g` is bottoming (hence the missing `b`), which unfortunately seems to be exactly what this test is testing for. :(
Moreover, the `B` changing to an `L` means that the demand analysis can't see that any demand is made of the first argument.
-UnsatFun.h: <C(S),1*C1(U(U))> +UnsatFun.h: <S,1*U>
This is the helper used by `g`. Again, it looks like something is going awry here with strictness analysis as the argument which was previously deemed "call-demand" is now just "strict".
-UnsatFun.g': <L,1*U(U)> +UnsatFun.g': <L,U(U)>
-UnsatFun.h2: <S,1*U><L,1*C1(U(U))> +UnsatFun.h2: <S,1*U><L,1*U>
This appears to be a very similar test which is likely failing for a similar reason.
Could you perhaps collect the Core for this test before and after your patch?