Custom Query (6536 matches)
Results (16 - 18 of 6536)
|#5194||fixed||"Fix build" broke build?||benl||daniel.is.fischer|
changeset 5bfa6a6382a4e4b949d333b1996065e9bcfacb18 removed import Config from compiler/nativeGen/AsmCodeGen.lhs, building failed with
compiler/nativeGen/AsmCodeGen.lhs:457:55: 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 performSideEffect 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.