Custom Query (6600 matches)


Show under each result:

Results (16 - 18 of 6600)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#5194 fixed "Fix build" broke build? benl

changeset 5bfa6a6382a4e4b949d333b1996065e9bcfacb18 removed import Config from compiler/nativeGen/AsmCodeGen.lhs, building failed with

    Not in scope: `cProjectVersion'

Reinserting the import made AsmCodeGen.lhs compile again, I'd be surprised if it breaks the build later on (build currently underway).

#8470 fixed "Fix" spurious Unused do-bind warnings 2piix

I've been writing a lot of monadic code with side effects, and I'm getting a lot of unused do-bind warnings.

In particular, consider the contrived example:

performSideEffect :: IO ()
preformSideEffect = return ()

someComplicatedIOAction :: a -> IO ()
someComplicatedIOAction a = do
   a <- getA
   putStrLn . show $ a

The call to performSideEffect triggers the unused do-bind warning.

I can appreciate that we're not binding result of performSideEffect, but we know, by virtue of the type () being a singleton, that there is nothing we can do with the the result. So it "really" doesn't make sense to pull anything out of the action. Fixing the warning with _ <- performSideEffect just adds noise.

Would it be possible to turn off the warning in the case that the monad action returns (), or maybe even other singleton types? I'm guessing the latter is harder, and I'd be happy to settle for just (). I don't know enough about GHC's internals to evaluate how hard either would be, though.

I know about -fno-warn-unused-do-bind, but it is inconvenient to use in a project that uses -Wall in the Cabal file, which a fairly popular web application framework uses. Even still, catching the legitimate unused do-binds while eliminating these spurious ones would be a nice, noise-lowering addition.

#709 fixed "Fixup too large" error with -fasm on PowerPC simonmar

The native code generator on PowerPC can sometimes generate code that doesn't pass the assembler. The error is "Fixup too large" from the assembler.

Workaround is to use -fvia-C.

Wolfgang Thaller says this: Conditional branches on the PowerPC only have 16 bits for the displacement. I have been reluctant to fix this so far because it means either slowing down all conditional branches or actually checking the size of the generated code before deciding what branch instructions to use, which I'm afraid would add an additional pass to the NCG.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.