October 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] #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] #15447: Mark the core libraries' internal modules "not-home" instead of "hide"
by GHC 16 Jan '19

16 Jan '19

#15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: haddock | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm often a bit annoyed that I cannot browse the haddocks for internal libraries. It would be nice if `base`, `ghc-prim`, `integer-gmp` and `integer-simple` could follow the example of `containers` and other libraries and offer docs for internal libraries too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15447> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13191: Make liftA2 a method of Applicative
by GHC 16 Jan '19

16 Jan '19

#13191: Make liftA2 a method of Applicative -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D3031 | Wiki Page: -------------------------------------+------------------------------------- Some functors support implementations of `liftA2` that are considerably faster than the usual definition. Furthermore, some people see `liftA2` as more intuitive and fundamental to the idea of `Applicative` than `<*>` is. This has been discussed on the libraries list in https://mail.haskell.org/pipermail/libraries/2017-January/027579.html and (as an official proposal) in https://mail.haskell.org/pipermail/libraries/2017-January/027612.html. All who expressed an opinion favored the proposal. One (David Menendez) specified that his support was weak. The others (Conal Elliot, Kris Nuttycombe, Wren Romano, Bardur Arantsson, and Mario Blažević) either supported the proposal strongly or merely indicated they were "+1". Conal Elliot wrote: [[BR]] [[BR]] > +1. > > I also sometimes define a specialized `liftA2` and then use it to define > `(<*>)`, which then gets used to define the real `liftA2`. > > I think of `liftA2` as playing a role similar to `foldMap` and `traverse`, while > `(<*>)` corresponds to `fold` and `sequenceA`. The first three self- compose > nicely: `liftA2.liftA2.liftA2`, `foldMap.foldMap.foldMap`, and > `traverse.traverse.traverse`. With functor composition, it's so much nicer to > write `liftA2.liftA2` (in the style of `Functor`, `Foldable`, and `Traversable`) > rather than `liftA2 (<*>)`. [[BR]] Wren Romano wrote [[BR]] [[BR]] > I'm also all for adding liftA2 to the class and have noticed this > inefficiency/asymmetry when working on the class hierarchies for other > languages [[BR]] Kris NuttyCombe wrote [[BR]] [[BR]] > I'm in favor of this change. From my perspecive, liftA2 is actually the > fundamental Applicative operation, an <*> is merely a convenient > isomorphism. When I'm teaching, showing the symmetry between the following > always seems to help students: > > fmap :: (a -> b) -> f a -> f b > liftA2 :: (a -> b -> c) -> f a -> f b -> f c > flip (>>=) :: (a -> f b) -> f a -> f b > > <*> is obviously exceptionally useful in practice. But liftA2 seems like the > more essential shape of that operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15602: PAP invariant of pointer tagging does not hold
by GHC 16 Jan '19

16 Jan '19

#15602: PAP invariant of pointer tagging does not hold -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508, #13767 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The PAP invariant of pointer tagging says > the PAP entry code jumps to the function's entry code, so it must have a tagged pointer to the function closure in R1. We therefore assume that a PAP always contains a tagged pointer to the function closure. (from https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/Point…) As discovered while debugging #15508, this currently does not hold. I tried to fix this in one PAP allocation site in Phab:D5051 but it somehow broke another test. We should review all PAP allocation sites and make sure the invariant holds, and then fix any bugs that this fix reveals. Relevant commits: - 6015a94f9108a502150565577b66c23650796639: Implements pointer tagging - f9c6d53fe997f1c560cda6f346f4b201711df37c: Fixes a PAP allocation site (#13767) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1