FWIW, I just ran into this issue too. Together with @monoidal we reduced our code to the following:
{# LANGUAGE ScopedTypeVariables #}
{# LANGUAGE RankNTypes #}
{# LANGUAGE ApplicativeDo #}
module M where
data T = T (forall a . a > a)
g :: forall m . Monad m => m T
g = do
a < return ()
b < return ()
let
f :: forall a . a > a
f = id
return (T f)
FWIW, here's the same issue reported against tasty: https://github.com/feuerbach/tasty/issues/266
I find it suspicious that both reports involve tasty, although as Mario's latest repro shows, this is not specific to tasty. I also verified that it's not specific to being run as a Cabal test suite.
Ah, I see. The way I read it was
[ e  p1 < e11, p2 < e12, ... { other statements of the form pn < ... }
 q1 < e21, q2 < e22, ... { other statements of the form qn < ... }
... { everything not of the form x < ... goes here }
]
I personally think that the documented semantics is much more useful than the implemented one. The idiom of zipping several lists (typically of the same length), then filtering is a fairly common one. OTOH filtering a list before zipping would generally produce lists of different lengths and is usually not what one wants/expects.
The desugaring of parallel list comprehensions described in the manual appears to state that parallel bars (
) have higher precedence than what comes after them, but this is not how they work in practice.
{# LANGUAGE ParallelListComp #}
main = print
[ (a, b)
 a < [1 .. 5]
 b < [1 .. 5]
, b >= 4
]
The desugaring implied by the docs is
main = print
[ (a, b)
 (a, b) < zip [1 .. 5] [1 .. 5]
, b >= 4
]
so I'd expect the result to be [(4,4),(5,5)]. Yet the actual result is [(1,4),(2,5)], showing that the comma has higher precedence here.
{# LANGUAGE ParallelListComp #}
main = print
[ (a, b)
 a < [1 .. 5]
 b < [1 .. 5]
, a >= 4
]
Result:
parlistcomp.hs:7:5: error:
• Variable not in scope: a :: Integer
• Perhaps you meant ‘a’ (line 5)

7  , a >= 4
 ^
Again, this is consistent with the comma binding more tightly than the bar. But also notice that ghc itself is confused about the scoping rules: it says a
is not in scope, yet suggests a
as a valid replacement.
Prelude Data.Fixed> (3e19) `mod'` 1.4
4096.0
Prelude Data.Fixed> 4.9098418106168856e20 `mod'` (43.4678352235136)
65536.0
Prelude Data.Fixed> (10) `mod'` exp (43)
1.7763568394002505e15
My understanding is that mod'
should yield a result whose absolute value is smaller than the absolute value of the divisor and which is positive when the divisor is positive.
The fact that some of the above results happen to be powers of 2 is also curious.
8.6.5
Haddock drops { }
comments inside a haddock comment itself delimited with {  ... }
.
My understanding is that the GHC API is responsible for parsing this, but please let me know if this is wrong and I should file a haddock issue instead.
Process the following module with haddock:
{ 
A Haskell comment looks like this: { comment }
}
module Test where
I expect the full doc string to show up in html, but the { comment }
part is dropped.
Tested with 8.6 and 8.8.
As a side note, I tried to reproduce this bug using raw ghc api like this:
import GHC
import GHC.Paths
import Outputable
import GhcMonad
main =
runGhc (Just libdir) $ do
dynflags < getSessionDynFlags
setSessionDynFlags dynflags { packageFlags = [] }
setTargets [Target (TargetFile "Test.hs" Nothing) False Nothing]
load LoadAllTargets
ms < getModSummary (mkModuleName "Test")
pm < parseModule ms
let pp = showPpr dynflags (hsmodHaddockModHeader . unLoc $ pm_parsed_source pm)
liftIO $ putStrLn pp
But I got Nothing
— i.e. the parsed module does not have hsmodHaddockModHeader
. I'd be interested in learning what I did wrong there.