November 2018 - ghc-tickets

[GHC] #10918: Float once-used let binding into a recursive function
by GHC 18 Jan '19

18 Jan '19

#10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Consider this code {{{#!hs let x = f x0 in let go 10 = x go i = go (i+1) in go (0::Int) }}} Currently, this is pretty much the core that comes out at the end. But what we want to see instead is {{{#!hs let go 10 = let x = f x 0 in x go i = go (i+1) in go (0::Int) }}} In general, we do not want to float a binding into a recursive function, because we would risk doing the allocation and/or evaluation of it multiple times. But in this case, we can see that it is going to be used at most once, so it is safe to do so. Even more: In the slightly less contrived examples that I was looking at, the call to `x` was happening in the a less likely code path, so this way we’d avoid doing the allocation in most cases, a clear win. It might be enough to simply make `CallArity` (or rather the cardinality analysis done by call arity) tell the rest of the compiler that it found that `x` is called at most once, and hopefully the simplifier knows what to make of that information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult
by GHC 17 Jan '19

17 Jan '19

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ‘HsExpr’ let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Is there a reason it has to be this difficult? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15971: Hadrian fails Shake's linter on Windows
by GHC 17 Jan '19

17 Jan '19

#15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to bring up a Hadrian builder on Windows I found the [[https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw|following]] excerpting: {{{ shakeArgsWith 0.001s 0% Function shake 0.407s 0% Database read 0.001s 0% With database 0.000s 0% Running rules 3065.940s 99% ========================= Pool finished (2932 threads, 4 max) 0.002s 0% Lint checking 1.810s 0% Total 3068.160s 100% Lint checking error - 520 values have changed since being depended upon: Key: _build/stage1/gmp/objs/zero_p.o Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,"") New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6} Key: _build/stage1/gmp/objs/zero.o Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,"") New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC} Key: _build/stage1/gmp/objs/xor_n.o Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,"") New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353} }}} It looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15971> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15736: Testsuite failures from validate --slow
by GHC 17 Jan '19

17 Jan '19

#15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof | recomp007 space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In case it helps, I ran a `./validate --slow` on HEAD on Ubuntu Bionic with 8.6.1. I don't attach much weight to the performance / stat failures as the tests seem to run in parallel. I'll pull out more specific diagnostics, if necessary. `` ==== STAGE 1 TESTS ==== SUMMARY for test run started at Wed Oct 10 20:29:33 2018 BST 0:00:04 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="EtaExpandLevPoly T14936 T15349 T2783 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork plugin-recomp-change plugin-recomp- change-prof recomp007 space_leak_001" SUMMARY for test run started at Wed Oct 10 19:31:20 2018 BST 0:58:10 spent to go through 6596 total tests, which gave rise to 29689 test cases, of which 5881 were skipped 256 had missing libraries 23273 expected passes 257 expected failures 0 caused framework failures 0 caused framework warnings 3 unexpected passes 6 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-kyex1v3_/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: /tmp/ghctest-kyex1v3_/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change- prof.run plugin-recomp-change-prof [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-kyex1v3_/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-kyex1v3_/test spaces/libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) Unexpected stat failures: /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181010 Timestamp 2018-10-10 18:31:15.21573855 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- `` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15736> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci
by GHC 17 Jan '19

17 Jan '19

#11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0). {{{ rwbarton@morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help Prelude> a <- return () Prelude> a <- return () <interactive>:2:1: warning: This binding for ‘a’ shadows the existing binding defined at <interactive>:1:1 Prelude> let b = return () Prelude> let b = return () <interactive>:4:5: warning: This binding for ‘b’ shadows the existing binding defined at <interactive>:3:5 Prelude> c = return () Prelude> c = return () Prelude> }}} I'm hoping this can be fixed for 8.0, since I would also very much like to turn on name shadowing warnings in ghci by default (in the interactive flags), to reduce confusion from examples like the below, which is now possible for the first time in 8.0: {{{ Prelude> fact 0 = 1 Prelude> fact n = n * fact (n-1) Prelude> fact 5 ^C^CInterrupted. Prelude> -- why did it run forever? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code`
by GHC 17 Jan '19

17 Jan '19

#12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7253 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since b98ff3ccb14e36145404f075349c8689762a2913 was landed (#7253), you don't need `let` to define stuff in GHCi: {{{ $ ghci Prelude> x = 3 Prelude> x 3 }}} But when using `-fobject-code`, this results in an error: {{{ $ ghci -fobject-code Prelude> x = 3 Prelude> x <interactive>:2:1: error: Variable not in scope: x }}} Very strange. CC @roshats, who implemented this feature, but the bug is probably in some part of the code he didn't touch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15086: hT profiling option
by GHC 17 Jan '19

17 Jan '19

#15086: hT profiling option -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.h… #rts-options-for-heap-profiling The docs] indicate that you can pass `-hT` as an RTS option for memory profiling "by heap closure type". However, GHC 8.4.2 claims `invalid heap profile options: -hT`, and this option is not listed among the usage options printed with the error. The user guide for GHC 8.2.2 also mentions -hT, and I believe that GHC-8.2.2 also did not permit the option. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15086> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15721: Command `:show bindings` throws exception for bindings without `let`
by GHC 17 Jan '19

17 Jan '19

#15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The command `:show bindings` works for `let a = 1`: {{{#!hs Prelude> let a = 1 Prelude> :show bindings a :: Num p => p = _ }}} But not for `a = 1`: {{{#!hs Prelude> a = 1 Prelude> :show bindings ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above. ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above. $trModule :: GHC.Types.Module = _ $trModule1 :: GHC.Types.TrName = _ $trModule2 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule2_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org $trModule3 :: GHC.Types.TrName = _ $trModule4 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule4_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org a :: Num p => p = _ a1 :: Integer = _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15721> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15905: Data familes should end in Type
by GHC 17 Jan '19

17 Jan '19

#15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we allow {{{ data family Fix (f :: Type -> k) :: k }}} with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`. That seems attractive because we can then have {{{ data instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x) }}} But what about this? {{{ type family F a type instance F Int = Type -> Type data instance Fix (f :: Type -> F Int) (x :: Type) = … }}} The type inference engine (tcInferApps) will type the LHS as something like {{{ ((Fix (f :: Type -> F Int)) |> co1) (x |> co2) where co1 :: F Int ~ Type co2 :: Type ~ F Int }}} But the LHS of a family axiom has to look like {{{ F t1 t2 … tn }}} not {{{ ((F t1 |> co) t2 t3) |> co4) …tn }}} with casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh! And indeed GHC HEAD does accept the first, but rejects the second with the error message {{{ • Expected kind ‘* -> * -> *’, but ‘f :: Type -> F Int’ has kind ‘* -> F Int’ • In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’ In the data instance declaration for ‘Fix’ }}} That's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely how it happens, but it must be fragile: a change in solve order, or more aggressive solving might change the behaviour. I don't see how to solve this. I propose instead to require data family kinds to end in `Type`, not in a type ''variable'' (as we currently allow). I don't know how many people that would affect, but the current state of affairs looks untenable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15905> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #15873: move to llvm 7 for 8.8.1
by GHC 16 Jan '19

16 Jan '19

#15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4