[ANNOUNCE] GHC 8.0.1 release candidate 2

Hello everyone, The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at http://downloads.haskell.org/~ghc/8.0.1-rc2/ This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include, * A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1. * Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471). * Matthew Pickering has restored support for multi-clause pattern synonyms (#11367) * A latent bug in the constraint solver which popped up as a build failure in xmonad-contrib in -rc1 has been fixed (#11379) * Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a variety of older type-checker bugs at a furious rate (#11458, #11248, #11330, #11408) * Simon Peyton Jones has taught demand analysis to more precisely handle exceptions (#11222) * Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223) * Loading of compiled modules needing shared library symbols now works in GHCi thanks to Peter Trommler (#10458) * A variety of limitations in our implementation of Typeable implementation have been fixed (#11120) although there is still more to be done (#11334). * A terrible failure of type inference due to visible type application has been fixed (#11458) * InjectiveTypeFamilies has been renamed to TypeFamilyDependencies * Custom type errors are now more robust (#11391) although there is still more work to be done (#11541) * We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370) * Compatibility with earlier Cabal versions should be a bit more robust. * The user-facing interface of the (formerly "implicit") CallStack functionality has been reworked, hiding the implicit callstack parameter behind a constraint synonym. * Online haddock documentation has been restored (#11419) * We now offer xz archives exclusively * A variety of miscellaneous bug-fixes have also been merged. All of these changes add up to nearly 200 commits in total. Given the large amount of churn between this candidate and -rc1, as well as the fact that there is at least one more significant patch pending (D1891, to fix #11471 and others), we will be releasing a third release candidate in a few weeks which should address more of the issues listed on the release status page [1]. Assuming things go well, we should be able to cut a final release by early March at the latest. All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the Windows builds*. Unfortunately, it was realized only too late that the tagged commit is broken on Windows. Consequently, the Windows builds were produced from the ghc-8.0.1-rc2 tag with two additional patches (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of course be completely unacceptable for a proper release, time constraints have meant that this was unfortunately the only viable option for this release candidate. We apologize for any confusion this may cause. At this point we are working very hard to nail the remaining bugs labelled as "highest" priority on the 8.0.1 status page [1]. If you have an issue which you'd like to see addressed in the release that does not appear in this list, please bring it to our attention. As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1

Good news! I assume there will be a Mac OS binary distribution soon?
On Sun, Feb 7, 2016 at 2:13 PM, Ben Gamari
Hello everyone,
The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release. Source and binary distributions as well as the newly revised users guide and Haddock documentation can be found at
http://downloads.haskell.org/~ghc/8.0.1-rc2/
This is the second in a series of release candidates leading up to the 8.0.1 release and fixes many of the issues reported in -rc1. These fixes include,
* A re-rewrite of the pattern checker by George Karachalias. The new checker should have far more predictable performance characteristics while sacrificing minimal reasoning power. This should resolve a large number of the issues felt in -rc1.
* Richard Eisenberg has been hammering out all manner of type-application- and TypeInType-related issues (#11335, #11416, #11405). There is still more work to do here, however (e.g. #11471).
* Matthew Pickering has restored support for multi-clause pattern synonyms (#11367)
* A latent bug in the constraint solver which popped up as a build failure in xmonad-contrib in -rc1 has been fixed (#11379)
* Dimitrios Vytiniotis and Simon Peyton Jones has been squashing a variety of older type-checker bugs at a furious rate (#11458, #11248, #11330, #11408)
* Simon Peyton Jones has taught demand analysis to more precisely handle exceptions (#11222)
* Tamar Christina has added support for remote GHCi on Windows and resolved a long-standing linking issue (#11223)
* Loading of compiled modules needing shared library symbols now works in GHCi thanks to Peter Trommler (#10458)
* A variety of limitations in our implementation of Typeable implementation have been fixed (#11120) although there is still more to be done (#11334).
* A terrible failure of type inference due to visible type application has been fixed (#11458)
* InjectiveTypeFamilies has been renamed to TypeFamilyDependencies
* Custom type errors are now more robust (#11391) although there is still more work to be done (#11541)
* We now have a more conservative default warning set, as well as better mechanisms for managing warning changes in the future. (#11429, #11370)
* Compatibility with earlier Cabal versions should be a bit more robust.
* The user-facing interface of the (formerly "implicit") CallStack functionality has been reworked, hiding the implicit callstack parameter behind a constraint synonym.
* Online haddock documentation has been restored (#11419)
* We now offer xz archives exclusively
* A variety of miscellaneous bug-fixes have also been merged.
All of these changes add up to nearly 200 commits in total. Given the large amount of churn between this candidate and -rc1, as well as the fact that there is at least one more significant patch pending (D1891, to fix #11471 and others), we will be releasing a third release candidate in a few weeks which should address more of the issues listed on the release status page [1]. Assuming things go well, we should be able to cut a final release by early March at the latest.
All of the builds above were produced from the ghc-8.0.1-rc2 tag (commit e2230228906a1c0fa1f86a0c1aa18d87de3cc49d) *with the exception of the Windows builds*. Unfortunately, it was realized only too late that the tagged commit is broken on Windows. Consequently, the Windows builds were produced from the ghc-8.0.1-rc2 tag with two additional patches (commit 5b35c5509adb1311856faa0bc9767aec9ad5e9b7). While this would of course be completely unacceptable for a proper release, time constraints have meant that this was unfortunately the only viable option for this release candidate. We apologize for any confusion this may cause.
At this point we are working very hard to nail the remaining bugs labelled as "highest" priority on the 8.0.1 status page [1]. If you have an issue which you'd like to see addressed in the release that does not appear in this list, please bring it to our attention.
As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far!
Cheers,
- Ben
[1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.0.1
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Ben Gamari
George Colpitts
writes: Good news! I assume there will be a Mac OS binary distribution soon?
There is one currently; "Darwin" is the name of the Mac OS X kernel.
Hmm, I should have fact-checked that first: XNU is apparently the name of the kernel whereas Darwin is the name of the operating system itself [1]. Regardless, the point is that OS X binaries are available for your testing pleasure. Let us know how it goes! Cheers, - Ben [1] https://en.wikipedia.org/wiki/Darwin_%28operating_system%29

Hello there,
2016-02-07 19:13 GMT+01:00 Ben Gamari
The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release.
For the FreeBSD users, the vanilla binary distributions are available here, along with a brief installation guide: http://haskell.inf.elte.hu/ghc/8.0.0.20160204/ Cheers, Gábor

Páli Gábor János
Hello there,
2016-02-07 19:13 GMT+01:00 Ben Gamari
: The GHC Team is very pleased to announce the second release candidate of the Glasgow Haskell Compiler 8.0.1 release.
For the FreeBSD users, the vanilla binary distributions are available here, along with a brief installation guide:
Thanks Páli! Cheers, - Ben

Ben Gamari
Hello everyone,
snip
* Compatibility with earlier Cabal versions should be a bit more robust.
Unfortunately this characterization was perhaps a bit optimistic. Sadly the errors provided by GHC when used with an older Cabal aren't any better in -rc2 than they were in -rc1. I've opened #11558 to track this issue. Users seeing unexpected missing interface file errors need to update Cabal and cabal-install from git. This must be done using GHC 7.10 at the moment as some of Cabal's build dependencies lack a build plan with 8.0. $ git clone git://github.com/haskell/cabal $ cd cabal $ cabal update $ cabal install Cabal/ cabal-install/ Cheers, - Ben

Dear Devs, I've tried to ask this in the ($) thread, but it was totally offtopic there and I was ignored just as I deserved :-) Consider the following example. wojtek@Desktop2016:~/src/he$ cat kinds.hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} data K = A | B f :: (A :: K) -> (B :: K) f _ = undefined wojtek@Desktop2016:~/src/he$ /opt/ghc/head/bin/ghc kinds.hs [1 of 1] Compiling Main ( kinds.hs, kinds.o ) kinds.hs:6:6: error: • Expected a type, but ‘'A’ has kind ‘K’ • In the type signature: f :: (A :: K) -> (B :: K) kinds.hs:6:18: error: • Expected a type, but ‘'B’ has kind ‘K’ • In the type signature: f :: (A :: K) -> (B :: K) As Roman kindly (!) explained to me some time ago, GHC really means "Expected a type of kind '*' (or '#')..." Now that GHC is apparently undergoing a major overhaul of its internals, would it be possible to allow types of various kinds in functions? Would it make sense? May I file a ticket? -- Kind regards, Wojtek Narczynski

On Mon, Feb 8, 2016 at 2:36 PM, Wojtek Narczyński
Dear Devs,
I've tried to ask this in the ($) thread, but it was totally offtopic there and I was ignored just as I deserved :-)
Consider the following example.
wojtek@Desktop2016:~/src/he$ cat kinds.hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-}
data K = A | B
f :: (A :: K) -> (B :: K) f _ = undefined
wojtek@Desktop2016:~/src/he$ /opt/ghc/head/bin/ghc kinds.hs [1 of 1] Compiling Main ( kinds.hs, kinds.o )
kinds.hs:6:6: error: • Expected a type, but ‘'A’ has kind ‘K’ • In the type signature: f :: (A :: K) -> (B :: K)
kinds.hs:6:18: error: • Expected a type, but ‘'B’ has kind ‘K’ • In the type signature: f :: (A :: K) -> (B :: K)
As Roman kindly (!) explained to me some time ago, GHC really means "Expected a type of kind '*' (or '#')..."
Now that GHC is apparently undergoing a major overhaul of its internals, would it be possible to allow types of various kinds in functions? Would it make sense? May I file a ticket?
Normally the reason to define a function is so that you can apply it to something. But there are no values of the promoted type A to apply f to, aside from perhaps undefined. What would be the purpose of allowing this? Regards, Reid Barton

On 08.02.2016 20:53, Reid Barton wrote:
Normally the reason to define a function is so that you can apply it to something. But there are no values of the promoted type A to apply f to, aside from perhaps undefined. What would be the purpose of allowing this?
Okay, this would be of no use. It didn't occur to me that there is currently no way to have values of types A and B. -- Wojtek

Hi, Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari:
As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far!
I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1 Bootstrapping using : /usr/bin/ghc which is version : 8.0.0.20160111 [..] "rm" -f compiler/stage1/build/.depend-v.haskell.tmp "/usr/bin/ghc" -M -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.0.0.20160204 -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage1/build -icompiler/stage1/build/autogen -Icompiler/stage1/build -Icompiler/stage1/build/autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -optP-include -optPcompiler/stage1/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id binary-0.8.2.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id directory-1.2.5.0 -package-id filepath-1.4.1.0 -package-id ghc-boot-8.0.0.20160204 -package-id hoopl-3.10.2.1 -package-id hpc-0.6.0.3 -package-id process-1.4.1.0 -package-id template-haskell-2.11.0.0 -package-id time-1.6 -package-id transformers-0.5.1.0 -package-id unix-2.7.1.1 -Wall -fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010 -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -dep-makefile compiler/stage1/build/.depend-v.haskell.tmp -dep-suffix "" -include-pkg-deps compiler/basicTypes/Avail.hs compiler/basicTypes/BasicTypes.hs compiler/basicTypes/ConLike.hs compiler/basicTypes/DataCon.hs compiler/basicTypes/PatSyn.hs compiler/basicTypes/Demand.hs compiler/cmm/Debug.hs compiler/utils/Exception.hs compiler/basicTypes/FieldLabel.hs compiler/main/GhcMonad.hs compiler/main/Hooks.hs compiler/basicTypes/Id.hs compiler/basicTypes/IdInfo.hs compiler/basicTypes/Lexeme.hs compiler/basicTypes/Literal.hs compiler/llvmGen/Llvm.hs compiler/llvmGen/Llvm/AbsSyn.hs compiler/llvmGen/Llvm/MetaData.hs compiler/llvmGen/Llvm/PpLlvm.hs compiler/llvmGen/Llvm/Types.hs compiler/llvmGen/LlvmCodeGen.hs compiler/llvmGen/LlvmCodeGen/Base.hs compiler/llvmGen/LlvmCodeGen/CodeGen.hs compiler/llvmGen/LlvmCodeGen/Data.hs compiler/llvmGen/LlvmCodeGen/Ppr.hs compiler/llvmGen/LlvmCodeGen/Regs.hs compiler/llvmGen/LlvmMangler.hs compiler/basicTypes/MkId.hs compiler/basicTypes/Module.hs compiler/basicTypes/Name.hs compiler/basicTypes/NameEnv.hs compiler/basicTypes/NameSet.hs compiler/basicTypes/OccName.hs compiler/basicTypes/RdrName.hs compiler/basicTypes/SrcLoc.hs compiler/basicTypes/UniqSupply.hs compiler/basicTypes/Unique.hs compiler/basicTypes/Var.hs compiler/basicTypes/VarEnv.hs compiler/basicTypes/VarSet.hs compiler/utils/UnVarGraph.hs compiler/cmm/BlockId.hs compiler/cmm/CLabel.hs compiler/cmm/Cmm.hs compiler/cmm/CmmBuildInfoTables.hs compiler/cmm/CmmPipeline.hs compiler/cmm/CmmCallConv.hs compiler/cmm/CmmCommonBlockElim.hs compiler/cmm/CmmImplementSwitchPlans.hs compiler/cmm/CmmContFlowOpt.hs compiler/cmm/CmmExpr.hs compiler/cmm/CmmInfo.hs compiler/cmm/CmmLex.hs compiler/cmm/CmmLint.hs compiler/cmm/CmmLive.hs compiler/cmm/CmmMachOp.hs compiler/cmm/CmmSwitch.hs compiler/cmm/CmmNode.hs compiler/cmm/CmmOpt.hs compiler/cmm/CmmParse.hs compiler/cmm/CmmProcPoint.hs compiler/cmm/CmmSink.hs compiler/cmm/CmmType.hs compiler/cmm/CmmUtils.hs compiler/cmm/CmmLayoutStack.hs compiler/cmm/MkGraph.hs compiler/nativeGen/PprBase.hs compiler/cmm/PprC.hs compiler/cmm/PprCmm.hs compiler/cmm/PprCmmDecl.hs compiler/cmm/PprCmmExpr.hs compiler/cmm/Bitmap.hs compiler/codeGen/CodeGen/Platform.hs compiler/codeGen/CodeGen/Platform/ARM.hs compiler/codeGen/CodeGen/Platform/ARM64.hs compiler/codeGen/CodeGen/Platform/NoRegs.hs compiler/codeGen/CodeGen/Platform/PPC.hs compiler/codeGen/CodeGen/Platform/PPC_Darwin.hs compiler/codeGen/CodeGen/Platform/SPARC.hs compiler/codeGen/CodeGen/Platform/X86.hs compiler/codeGen/CodeGen/Platform/X86_64.hs compiler/codeGen/CgUtils.hs compiler/codeGen/StgCmm.hs compiler/codeGen/StgCmmBind.hs compiler/codeGen/StgCmmClosure.hs compiler/codeGen/StgCmmCon.hs compiler/codeGen/StgCmmEnv.hs compiler/codeGen/StgCmmExpr.hs compiler/codeGen/StgCmmForeign.hs compiler/codeGen/StgCmmHeap.hs compiler/codeGen/StgCmmHpc.hs compiler/codeGen/StgCmmArgRep.hs compiler/codeGen/StgCmmLayout.hs compiler/codeGen/StgCmmMonad.hs compiler/codeGen/StgCmmPrim.hs compiler/codeGen/StgCmmProf.hs compiler/codeGen/StgCmmTicky.hs compiler/codeGen/StgCmmUtils.hs compiler/codeGen/StgCmmExtCode.hs compiler/cmm/SMRep.hs compiler/coreSyn/CoreArity.hs compiler/coreSyn/CoreFVs.hs compiler/coreSyn/CoreLint.hs compiler/coreSyn/CorePrep.hs compiler/coreSyn/CoreSubst.hs compiler/coreSyn/CoreSyn.hs compiler/coreSyn/TrieMap.hs compiler/coreSyn/CoreTidy.hs compiler/coreSyn/CoreUnfold.hs compiler/coreSyn/CoreUtils.hs compiler/coreSyn/CoreSeq.hs compiler/coreSyn/CoreStats.hs compiler/coreSyn/MkCore.hs compiler/coreSyn/PprCore.hs compiler/deSugar/PmExpr.hs compiler/deSugar/TmOracle.hs compiler/deSugar/Check.hs compiler/deSugar/Coverage.hs compiler/deSugar/Desugar.hs compiler/deSugar/DsArrows.hs compiler/deSugar/DsBinds.hs compiler/deSugar/DsCCall.hs compiler/deSugar/DsExpr.hs compiler/deSugar/DsForeign.hs compiler/deSugar/DsGRHSs.hs compiler/deSugar/DsListComp.hs compiler/deSugar/DsMonad.hs compiler/deSugar/DsUtils.hs compiler/deSugar/Match.hs compiler/deSugar/MatchCon.hs compiler/deSugar/MatchLit.hs compiler/hsSyn/HsBinds.hs compiler/hsSyn/HsDecls.hs compiler/hsSyn/HsDoc.hs compiler/hsSyn/HsExpr.hs compiler/hsSyn/HsImpExp.hs compiler/hsSyn/HsLit.hs compiler/hsSyn/PlaceHolder.hs compiler/hsSyn/HsPat.hs compiler/hsSyn/HsSyn.hs compiler/hsSyn/HsTypes.hs compiler/hsSyn/HsUtils.hs compiler/iface/BinIface.hs compiler/iface/BuildTyCl.hs compiler/iface/IfaceEnv.hs compiler/iface/IfaceSyn.hs compiler/iface/IfaceType.hs compiler/iface/LoadIface.hs compiler/iface/MkIface.hs compiler/iface/TcIface.hs compiler/iface/FlagChecker.hs compiler/main/Annotations.hs compiler/main/CmdLineParser.hs compiler/main/CodeOutput.hs compiler/stage1/build/Config.hs compiler/main/Constants.hs compiler/main/DriverMkDepend.hs compiler/main/DriverPhases.hs compiler/main/PipelineMonad.hs compiler/main/DriverPipeline.hs compiler/main/DynFlags.hs compiler/main/ErrUtils.hs compiler/main/Finder.hs compiler/main/GHC.hs compiler/main/GhcMake.hs compiler/main/GhcPlugins.hs compiler/main/DynamicLoading.hs compiler/main/HeaderInfo.hs compiler/main/HscMain.hs compiler/main/HscStats.hs compiler/main/HscTypes.hs compiler/main/InteractiveEval.hs compiler/main/InteractiveEvalTypes.hs compiler/main/PackageConfig.hs compiler/main/Packages.hs compiler/main/PlatformConstants.hs compiler/main/Plugins.hs compiler/typecheck/TcPluginM.hs compiler/main/PprTyThing.hs compiler/main/StaticFlags.hs compiler/deSugar/StaticPtrTable.hs compiler/main/SysTools.hs compiler/main/Elf.hs compiler/main/TidyPgm.hs compiler/parser/Ctype.hs compiler/parser/HaddockUtils.hs compiler/parser/Lexer.hs compiler/types/OptCoercion.hs compiler/parser/Parser.hs compiler/parser/RdrHsSyn.hs compiler/parser/ApiAnnotation.hs compiler/prelude/ForeignCall.hs compiler/prelude/PrelInfo.hs compiler/prelude/PrelNames.hs compiler/prelude/PrelRules.hs compiler/prelude/PrimOp.hs compiler/prelude/TysPrim.hs compiler/prelude/TysWiredIn.hs compiler/profiling/CostCentre.hs compiler/profiling/ProfInit.hs compiler/profiling/SCCfinal.hs compiler/rename/RnBinds.hs compiler/rename/RnEnv.hs compiler/rename/RnExpr.hs compiler/rename/RnHsDoc.hs compiler/rename/RnNames.hs compiler/rename/RnPat.hs compiler/rename/RnSource.hs compiler/rename/RnSplice.hs compiler/rename/RnTypes.hs compiler/simplCore/CoreMonad.hs compiler/simplCore/CSE.hs compiler/simplCore/FloatIn.hs compiler/simplCore/FloatOut.hs compiler/simplCore/LiberateCase.hs compiler/simplCore/OccurAnal.hs compiler/simplCore/SAT.hs compiler/simplCore/SetLevels.hs compiler/simplCore/SimplCore.hs compiler/simplCore/SimplEnv.hs compiler/simplCore/SimplMonad.hs compiler/simplCore/SimplUtils.hs compiler/simplCore/Simplify.hs compiler/simplStg/SimplStg.hs compiler/simplStg/StgStats.hs compiler/simplStg/UnariseStg.hs compiler/specialise/Rules.hs compiler/specialise/SpecConstr.hs compiler/specialise/Specialise.hs compiler/stgSyn/CoreToStg.hs compiler/stgSyn/StgLint.hs compiler/stgSyn/StgSyn.hs compiler/simplCore/CallArity.hs compiler/stranal/DmdAnal.hs compiler/stranal/WorkWrap.hs compiler/stranal/WwLib.hs compiler/typecheck/FamInst.hs compiler/typecheck/Inst.hs compiler/typecheck/TcAnnotations.hs compiler/typecheck/TcArrows.hs compiler/typecheck/TcBinds.hs compiler/typecheck/TcClassDcl.hs compiler/typecheck/TcDefaults.hs compiler/typecheck/TcDeriv.hs compiler/typecheck/TcEnv.hs compiler/typecheck/TcExpr.hs compiler/typecheck/TcForeign.hs compiler/typecheck/TcGenDeriv.hs compiler/typecheck/TcGenGenerics.hs compiler/typecheck/TcHsSyn.hs compiler/typecheck/TcHsType.hs compiler/typecheck/TcInstDcls.hs compiler/typecheck/TcMType.hs compiler/typecheck/TcValidity.hs compiler/typecheck/TcMatches.hs compiler/typecheck/TcPat.hs compiler/typecheck/TcPatSyn.hs compiler/typecheck/TcRnDriver.hs compiler/typecheck/TcRnMonad.hs compiler/typecheck/TcRnTypes.hs compiler/typecheck/TcRules.hs compiler/typecheck/TcSimplify.hs compiler/typecheck/TcErrors.hs compiler/typecheck/TcTyClsDecls.hs compiler/typecheck/TcTyDecls.hs compiler/typecheck/TcTypeable.hs compiler/typecheck/TcType.hs compiler/typecheck/TcEvidence.hs compiler/typecheck/TcUnify.hs compiler/typecheck/TcInteract.hs compiler/typecheck/TcCanonical.hs compiler/typecheck/TcFlatten.hs compiler/typecheck/TcSMonad.hs compiler/typecheck/TcTypeNats.hs compiler/typecheck/TcSplice.hs compiler/types/Class.hs compiler/types/Coercion.hs compiler/deSugar/DsMeta.hs compiler/prelude/THNames.hs compiler/types/FamInstEnv.hs compiler/typecheck/FunDeps.hs compiler/types/InstEnv.hs compiler/types/TyCon.hs compiler/types/CoAxiom.hs compiler/types/Kind.hs compiler/types/Type.hs compiler/types/TyCoRep.hs compiler/types/Unify.hs compiler/utils/Bag.hs compiler/utils/Binary.hs compiler/utils/BooleanFormula.hs compiler/utils/BufWrite.hs compiler/utils/Digraph.hs compiler/utils/Encoding.hs compiler/utils/FastFunctions.hs compiler/utils/FastMutInt.hs compiler/utils/FastString.hs compiler/utils/FastStringEnv.hs compiler/stage1/build/Fingerprint.hs compiler/utils/FiniteMap.hs compiler/utils/FV.hs compiler/utils/GraphBase.hs compiler/utils/GraphColor.hs compiler/utils/GraphOps.hs compiler/utils/GraphPpr.hs compiler/utils/IOEnv.hs compiler/utils/ListSetOps.hs compiler/utils/Maybes.hs compiler/utils/MonadUtils.hs compiler/utils/OrdList.hs compiler/utils/Outputable.hs compiler/utils/Pair.hs compiler/utils/Panic.hs compiler/utils/Pretty.hs compiler/utils/State.hs compiler/utils/Stream.hs compiler/utils/StringBuffer.hs compiler/utils/UniqDFM.hs compiler/utils/UniqDSet.hs compiler/utils/UniqFM.hs compiler/utils/UniqSet.hs compiler/utils/Util.hs compiler/vectorise/Vectorise/Builtins/Base.hs compiler/vectorise/Vectorise/Builtins/Initialise.hs compiler/vectorise/Vectorise/Builtins.hs compiler/vectorise/Vectorise/Monad/Base.hs compiler/vectorise/Vectorise/Monad/Naming.hs compiler/vectorise/Vectorise/Monad/Local.hs compiler/vectorise/Vectorise/Monad/Global.hs compiler/vectorise/Vectorise/Monad/InstEnv.hs compiler/vectorise/Vectorise/Monad.hs compiler/vectorise/Vectorise/Utils/Base.hs compiler/vectorise/Vectorise/Utils/Closure.hs compiler/vectorise/Vectorise/Utils/Hoisting.hs compiler/vectorise/Vectorise/Utils/PADict.hs compiler/vectorise/Vectorise/Utils/Poly.hs compiler/vectorise/Vectorise/Utils.hs compiler/vectorise/Vectorise/Generic/Description.hs compiler/vectorise/Vectorise/Generic/PAMethods.hs compiler/vectorise/Vectorise/Generic/PADict.hs compiler/vectorise/Vectorise/Generic/PData.hs compiler/vectorise/Vectorise/Type/Env.hs compiler/vectorise/Vectorise/Type/Type.hs compiler/vectorise/Vectorise/Type/TyConDecl.hs compiler/vectorise/Vectorise/Type/Classify.hs compiler/vectorise/Vectorise/Convert.hs compiler/vectorise/Vectorise/Vect.hs compiler/vectorise/Vectorise/Var.hs compiler/vectorise/Vectorise/Env.hs compiler/vectorise/Vectorise/Exp.hs compiler/vectorise/Vectorise.hs compiler/cmm/Hoopl/Dataflow.hs compiler/cmm/Hoopl.hs compiler/nativeGen/AsmCodeGen.hs compiler/nativeGen/TargetReg.hs compiler/nativeGen/NCGMonad.hs compiler/nativeGen/Instruction.hs compiler/nativeGen/Format.hs compiler/nativeGen/Reg.hs compiler/nativeGen/RegClass.hs compiler/nativeGen/PIC.hs compiler/utils/Platform.hs compiler/nativeGen/CPrim.hs compiler/nativeGen/X86/Regs.hs compiler/nativeGen/X86/RegInfo.hs compiler/nativeGen/X86/Instr.hs compiler/nativeGen/X86/Cond.hs compiler/nativeGen/X86/Ppr.hs compiler/nativeGen/X86/CodeGen.hs compiler/nativeGen/PPC/Regs.hs compiler/nativeGen/PPC/RegInfo.hs compiler/nativeGen/PPC/Instr.hs compiler/nativeGen/PPC/Cond.hs compiler/nativeGen/PPC/Ppr.hs compiler/nativeGen/PPC/CodeGen.hs compiler/nativeGen/SPARC/Base.hs compiler/nativeGen/SPARC/Regs.hs compiler/nativeGen/SPARC/Imm.hs compiler/nativeGen/SPARC/AddrMode.hs compiler/nativeGen/SPARC/Cond.hs compiler/nativeGen/SPARC/Instr.hs compiler/nativeGen/SPARC/Stack.hs compiler/nativeGen/SPARC/ShortcutJump.hs compiler/nativeGen/SPARC/Ppr.hs compiler/nativeGen/SPARC/CodeGen.hs compiler/nativeGen/SPARC/CodeGen/Amode.hs compiler/nativeGen/SPARC/CodeGen/Base.hs compiler/nativeGen/SPARC/CodeGen/CondCode.hs compiler/nativeGen/SPARC/CodeGen/Gen32.hs compiler/nativeGen/SPARC/CodeGen/Gen64.hs compiler/nativeGen/SPARC/CodeGen/Sanity.hs compiler/nativeGen/SPARC/CodeGen/Expand.hs compiler/nativeGen/RegAlloc/Liveness.hs compiler/nativeGen/RegAlloc/Graph/Main.hs compiler/nativeGen/RegAlloc/Graph/Stats.hs compiler/nativeGen/RegAlloc/Graph/ArchBase.hs compiler/nativeGen/RegAlloc/Graph/ArchX86.hs compiler/nativeGen/RegAlloc/Graph/Coalesce.hs compiler/nativeGen/RegAlloc/Graph/Spill.hs compiler/nativeGen/RegAlloc/Graph/SpillClean.hs compiler/nativeGen/RegAlloc/Graph/SpillCost.hs compiler/nativeGen/RegAlloc/Graph/TrivColorable.hs compiler/nativeGen/RegAlloc/Linear/Main.hs compiler/nativeGen/RegAlloc/Linear/JoinToTargets.hs compiler/nativeGen/RegAlloc/Linear/State.hs compiler/nativeGen/RegAlloc/Linear/Stats.hs compiler/nativeGen/RegAlloc/Linear/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/StackMap.hs compiler/nativeGen/RegAlloc/Linear/Base.hs compiler/nativeGen/RegAlloc/Linear/X86/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/X86_64/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/PPC/FreeRegs.hs compiler/nativeGen/RegAlloc/Linear/SPARC/FreeRegs.hs compiler/nativeGen/Dwarf.hs compiler/nativeGen/Dwarf/Types.hs compiler/nativeGen/Dwarf/Constants.hs ghc: unrecognised flag: -this-unit-id unrecognised flag: -this-unit-id Usage: For basic information, try the `--help' option. https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=arm64&ver=8.0.0.20160204-1&stamp=1454952602 I didn’t quite follow the Cabal issues on the tickets list, so this might be known, but it certainly should not happen. Or is this a problem with 8.0.1-rc1 and I should just avoid that version somehow, and it will bootstrap with 8.0.1-rc2 just fine? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Joachim Breitner
Hi,
Am Sonntag, den 07.02.2016, 19:13 +0100 schrieb Ben Gamari:
As always, we look forward to hearing about any issues that you encounter with this candidate. Thanks to everyone who has contributed so far!
I cannot bootstrap 8.0.1-rc2 with 8.0.1-rc1
unrecognised flag: -this-unit-id
Usage: For basic information, try the `--help' option. https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=arm64&ver=8.0.0.20160204-1&stamp=1454952602
I didn’t quite follow the Cabal issues on the tickets list, so this might be known, but it certainly should not happen.
Or is this a problem with 8.0.1-rc1 and I should just avoid that version somehow, and it will bootstrap with 8.0.1-rc2 just fine?
Yes, this should merely be a problem with -rc1. Edward Yang did some cleanups of the package-system command-line flags in -rc2. The original goal of this was to ensure that users with older Cabals aren't surprised with the terrible errors that they are currently faced with [1]. Sadly this didn't quite get resolved in -rc2, however. See D1892 [2] for one possible future direction for putting this issue to rest. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/ticket/11558 [2] https://phabricator.haskell.org/D1892

I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the current discussion about -Wcompat and friends I decided to take a detailed look at the warnings in my projects and hit a regression(?): Somehow I'm unable to suppress the "Top-level binding with no type signature" warnings from 8.0.1 onwards. The gory details: In my .cabal file I set -Wall ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618), and in my .travis.yml I set -Werror ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76). But the -Wno-missing-signatures pragma ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Toke...) doesn't work, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using -fno-warn-missing-signatures didn't work, either, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738. Am I doing something wrong here or is this really a regression? I'm quite sure that suppressions via pragmas worked in the past... :-( Cheers, S.

Sven Panne
I'm a little bit late to the 8.0.1 show, but nevertheless: Motivated by the current discussion about -Wcompat and friends I decided to take a detailed look at the warnings in my projects and hit a regression(?): Somehow I'm unable to suppress the "Top-level binding with no type signature" warnings from 8.0.1 onwards.
The gory details: In my .cabal file I set -Wall ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L618), and in my .travis.yml I set -Werror ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/.travis.yml#L76). But the -Wno-missing-signatures pragma ( https://github.com/haskell-opengl/OpenGLRaw/blob/master/src/Graphics/GL/Toke...) doesn't work, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109400373. Using -fno-warn-missing-signatures didn't work, either, see https://travis-ci.org/haskell-opengl/OpenGLRaw/jobs/109396738.
Am I doing something wrong here or is this really a regression? I'm quite sure that suppressions via pragmas worked in the past... :-(
The reason for this is that the things missing signatures are pattern synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs [1], which is enabled in -Wall by default. Cheers, - Ben [1] http://downloads.haskell.org/~ghc/master/users-guide//using-warnings.html#gh...

2016-02-15 20:16 GMT+01:00 Ben Gamari
Sven Panne
writes: The reason for this is that the things missing signatures are pattern synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs [1], which is enabled in -Wall by default.
OK, I missed that in the release notes. Two points here: * The naming of the options is horrible, sometimes it's "sigs", sometimes it's "signatures". I would prefer if we named them consistently (probably "signatures", it's easier to search for). * Given the myriad of warning-related options, It is *extremely* hard to figure out which one caused the actual warning in question. The solution to this is very easy and done this way in clang/gcc (don't remember which one, I'm switching quite often): Just suffix all warnings consistently with the option causing it, e.g. Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]: <code causing the warning> Cheers, S.

On 2016-02-15 at 21:05:29 +0100, Sven Panne wrote: [...]
* Given the myriad of warning-related options, It is *extremely* hard to figure out which one caused the actual warning in question. The solution to this is very easy and done this way in clang/gcc (don't remember which one, I'm switching quite often): Just suffix all warnings consistently with the option causing it, e.g.
Top-level binding with no type signature: [ -Wmissing-pat-syn-sigs]: <code causing the warning>
Fyi, https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings and specifically https://ghc.haskell.org/trac/ghc/ticket/10752 :-)

Sven Panne
2016-02-15 20:16 GMT+01:00 Ben Gamari
: Sven Panne
writes: The reason for this is that the things missing signatures are pattern synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs [1], which is enabled in -Wall by default. OK, I missed that in the release notes. Two points here:
* The naming of the options is horrible, sometimes it's "sigs", sometimes it's "signatures". I would prefer if we named them consistently (probably "signatures", it's easier to search for).
Indeed, I noticed that this when looking this up for you. The inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is a bit of a mouthful.
* Given the myriad of warning-related options, It is *extremely* hard to figure out which one caused the actual warning in question. The solution to this is very easy and done this way in clang/gcc (don't remember which one, I'm switching quite often): Just suffix all warnings consistently with the option causing it, e.g.
Indeed, this is #10752, as hvr pointed out. I'm not sure whether David has done anything on this yet; feel free to take a stab at implementing it if you have some free time. - Ben

Hello,
I have renamed it to -Wmissing-pat-syn-signatures.
Matt
On Mon, Feb 15, 2016 at 9:09 PM, Ben Gamari
Sven Panne
writes: 2016-02-15 20:16 GMT+01:00 Ben Gamari
: Sven Panne
writes: The reason for this is that the things missing signatures are pattern synonyms, which have their warnings controlled by -Wmissing-pat-syn-sigs [1], which is enabled in -Wall by default. OK, I missed that in the release notes. Two points here:
* The naming of the options is horrible, sometimes it's "sigs", sometimes it's "signatures". I would prefer if we named them consistently (probably "signatures", it's easier to search for).
Indeed, I noticed that this when looking this up for you. The inconsistency is quite unfortunate. Perhaps -Wmissing-pattern-signatures or -Wmissing-patsyn-signatures? -Wmissing-pattern-synonym-signatures is a bit of a mouthful.
* Given the myriad of warning-related options, It is *extremely* hard to figure out which one caused the actual warning in question. The solution to this is very easy and done this way in clang/gcc (don't remember which one, I'm switching quite often): Just suffix all warnings consistently with the option causing it, e.g.
Indeed, this is #10752, as hvr pointed out. I'm not sure whether David has done anything on this yet; feel free to take a stab at implementing it if you have some free time.
- Ben
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2016-02-16 0:35 GMT+01:00 Matthew Pickering
I have renamed it to -Wmissing-pat-syn-signatures.
Hmmm, things are still wildly inconsistent: * "pat" is spelled "pattern" in other flags. * We still have both "sigs" and "signatures" as parts of the names. * Why is "synonyms" too long, but OTOH we have monsters like "-Wnoncanonical-monadfail-instances"? * We have both "binds" and "bindings" as parts of the names. My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix all those inconsistencies in one big sweep before 8.0.1 is out, it only gets harder later. At the moment you need #ifdef magic in the code and "If impl(foo)" in .cabal, anyway, but doing these changes later will only keep this sorry state for longer than necessary. I don't really care if we use abbreviations like "sigs" or not, but whatever we use, we should use it consistently (personally I would prefer the whole words, not the abbreviations). Cheers, S.

I’m all for it. We could add the new spellings as synonyms of the old ones; and deprecate old ones. Then drop the old ones after a release cycle or three
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Sven Panne
Sent: 16 February 2016 07:01
To: GHC developers

Sven Panne
2016-02-16 0:35 GMT+01:00 Matthew Pickering
: I have renamed it to -Wmissing-pat-syn-signatures.
Hmmm, things are still wildly inconsistent:
* "pat" is spelled "pattern" in other flags.
* We still have both "sigs" and "signatures" as parts of the names.
* Why is "synonyms" too long, but OTOH we have monsters like "-Wnoncanonical-monadfail-instances"?
* We have both "binds" and "bindings" as parts of the names.
My proposal would be: The -Wfoo option syntax is new, anyway, so let's fix all those inconsistencies in one big sweep before 8.0.1 is out, it only gets harder later. At the moment you need #ifdef magic in the code and "If impl(foo)" in .cabal, anyway, but doing these changes later will only keep this sorry state for longer than necessary. I don't really care if we use abbreviations like "sigs" or not, but whatever we use, we should use it consistently (personally I would prefer the whole words, not the abbreviations).
Fair enough; since we are are breaking away from -fwarn- we could consider taking this opportunity to fix these inconsistencies. However, I do want to make sure that we don't make the transition any more painful for users than necessary. For instance, the user should be able to get useful feedback from the compiler on what warning flags have changed with s/-fwarn-/-W/ To this end I recommend the following, * Someone propose a consistent vocabulary for warning flag names * We keep -fwarn- flags as they are currently * We keep the inconsistently named -W flags corresponding to these -fwarn- flags * We add consistently named -W flags alongside these * We set a timeline for deprecating the inconsistent flags Sven, perhaps you would like to pick up this task? Cheers, - Ben

2016-02-16 10:49 GMT+01:00 Ben Gamari
[...] To this end I recommend the following,
* Someone propose a consistent vocabulary for warning flag names
* We keep -fwarn- flags as they are currently
* We keep the inconsistently named -W flags corresponding to these -fwarn- flags
* We add consistently named -W flags alongside these
* We set a timeline for deprecating the inconsistent flags
This plan looks perfect.
Sven, perhaps you would like to pick up this task?
Alas, I don't have many spare development cycles at the moment, especially given the relatively tight timeline for 8.0.1. I have just enough time to grumble about some GHC details on this list. ;-) More seriously, after Herbert's option survey my proposal is quite short: * Use "sigs" or "signatures" consistently (doesn't really matter which one) * Use "pattern-synonyms", not "pat-syn"

Ccing quchen who has been working on warning-related things.
Sven Panne
2016-02-16 10:49 GMT+01:00 Ben Gamari
: [...] To this end I recommend the following,
* Someone propose a consistent vocabulary for warning flag names
* We keep -fwarn- flags as they are currently
* We keep the inconsistently named -W flags corresponding to these -fwarn- flags
* We add consistently named -W flags alongside these
* We set a timeline for deprecating the inconsistent flags
This plan looks perfect.
Great!
Sven, perhaps you would like to pick up this task?
Alas, I don't have many spare development cycles at the moment, especially given the relatively tight timeline for 8.0.1.
I'm afraid I also don't have the bandwidth to pick this up. I have opened #11583 to track this issue. I hope someone is able to pick this up before the release. Cheers, - Ben

On 2016-02-16 at 08:00:49 +0100, Sven Panne wrote:
I have renamed it to -Wmissing-pat-syn-signatures.
Hmmm, things are still wildly inconsistent:
* "pat" is spelled "pattern" in other flags.
* We still have both "sigs" and "signatures" as parts of the names.
I simple head-count in GHC HEAD: -ddump-strsigs -Wmissing-local-sigs -Wmissing-exported-sigs vs -dsuppress-type-signatures -Wmissing-signatures -Wpartial-type-signatures at this point I'd be fine with either -Wmissing-pattern-synonyms-signatures or even -Wmissing-pattern-synonyms-sigs as neither 'pattern' nor 'synonym` have any abbreviation precedent in `ghc --show-options`, but `sig(nature)s` has a precedent, so using `-sigs` wouldn't introduce anything new.
* Why is "synonyms" too long, but OTOH we have monsters like "-Wnoncanonical-monadfail-instances"?
Well... the -Wnoncanonical-*-instances flag family was the best I could come up with which is reasonably self-descriptive... do you have any better suggestions?
* We have both "binds" and "bindings" as parts of the names.
Fwiw, `ghc --show-options | grep binding` come ups empty

2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel
[...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't introduce anything new.
I'm fine with "sigs", my point was only the fact that non-abbreviated words seem to be much more common in the flags names (and are easier to remember). IMHO it doesn't really matter if the flag names are long: One probably doesn't type them on the command line often, they typically live in .cabal files, .travis.yml and pragmas where you type them once. Well... the -Wnoncanonical-*-instances flag family was the best I could
come up with which is reasonably self-descriptive... do you have any better suggestions?
No, and I actually like the long names, see above. :-)
Fwiw, `ghc --show-options | grep binding` come ups empty
Then the docs are out-of-sync: http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc...

Sven Panne
2016-02-16 10:56 GMT+01:00 Herbert Valerio Riedel
: [...] but `sig(nature)s` has a precedent, so using `-sigs` wouldn't introduce anything new.
I'm fine with "sigs", my point was only the fact that non-abbreviated words seem to be much more common in the flags names (and are easier to remember). IMHO it doesn't really matter if the flag names are long: One probably doesn't type them on the command line often, they typically live in .cabal files, .travis.yml and pragmas where you type them once.
Well... the -Wnoncanonical-*-instances flag family was the best I could
come up with which is reasonably self-descriptive... do you have any better suggestions?
No, and I actually like the long names, see above. :-)
I don't have an opinion here. Especially with tab completion these names are rarely typed anyways.
Fwiw, `ghc --show-options | grep binding` come ups empty
Then the docs are out-of-sync: http://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html#ghc... Indeed it appears that this warning was supposed to be removed in 7.10.
I've gone ahead and finished this in https://phabricator.haskell.org/D1922 Cheers, - Ben

On 8 February 2016 at 03:13, Ben Gamari
Thank you for RC2. I finally built ghc-8.0.0 for Fedora Rawhide (quick build): https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 (perf build is still ongoing). One minor thing I noticed is that docdir seems have changed RC2 to be versioned. ie the LICENSE files for the included libraries now get installed under "/usr/share/doc/ghc-<version>/html/libraries/*/" rather than "/usr/share/doc/ghc/html/libraries/*/" before. I managed to work around that by configuring with --docdir=/usr/share/doc but it took me by surprise. I should open a ticket I guess... Jens

Jens Petersen
On 8 February 2016 at 03:13, Ben Gamari
wrote: Thank you for RC2.
I'm happy to help. Sorry about the delayed response Jens; I'm still catching up after some downtime due to sickness earlier this week.
I finally built ghc-8.0.0 for Fedora Rawhide (quick build): https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 (perf build is still ongoing).
One minor thing I noticed is that docdir seems have changed RC2 to be versioned. ie the LICENSE files for the included libraries now get installed under "/usr/share/doc/ghc-<version>/html/libraries/*/" rather than "/usr/share/doc/ghc/html/libraries/*/" before. I managed to work around that by configuring with --docdir=/usr/share/doc but it took me by surprise.
This was an intentional change; see #11354. I'll make sure it is mentioned in the next release candidate announcement. Thanks for mentioning this. Cheers, - Ben

On 26 February 2016 at 02:09, Ben Gamari
Thank you for RC2. I'm happy to help.
I think you're doing a great job.
I finally built ghc-8.0.0 for Fedora Rawhide (quick build): https://copr.fedorainfracloud.org/coprs/petersen/ghc-8.0.1 (perf build is still ongoing).
Fedora perf builds are done now btw.
One minor thing I noticed is that docdir seems have changed RC2 to be versioned. ie the LICENSE files for the included libraries now get installed under "/usr/share/doc/ghc-<version>/html/libraries/*/" rather than "/usr/share/doc/ghc/html/libraries/*/" before. I managed to work around that by configuring with --docdir=/usr/share/doc but it took me by surprise.
This was an intentional change; see #11354. I'll make sure it is mentioned in the next release candidate announcement. Thanks for mentioning this. https://ghc.haskell.org/trac/ghc/ticket/11354
I see, thanks. I added a comment, since 'configure --help' still says the default is unversioned, and I opened a new ticket https://ghc.haskell.org/trac/ghc/ticket/11659 for this. Thanks, Jens
participants (12)
-
Ben Gamari
-
Ben Gamari
-
George Colpitts
-
Herbert Valerio Riedel
-
Jens Petersen
-
Joachim Breitner
-
Matthew Pickering
-
Páli Gábor János
-
Reid Barton
-
Simon Peyton Jones
-
Sven Panne
-
Wojtek Narczyński