- ghc-tickets - Haskell.org

[GHC] #15033: ScopedTypeVariable and RankNTypes don't scope throughout function body
by GHC 14 Apr '18

14 Apr '18

#15033: ScopedTypeVariable and RankNTypes don't scope throughout function body -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- I'm writing a DSL that uses `TypeApplications`, and I noticed the following weird behavior with `ScopedTypeVariables` and `AllowAmbiguousTypes`. You can define a function that takes the `TypeApplication` after a parameter: {{{#!hs lol :: String -> forall a. IO () lol str = putStrLn str main = lol "hello" @Int }}} This works! Unfortunately, it is impossible to *refer* to that `a` type variable in the body of the function. It is as though `ScopedTypeVariables` were not turned on. A reproduction (tested on 8.2.2 and 8.4.1): {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Typeable import Data.Proxy no :: String -> forall x. Typeable x => IO () no _ = print (typeRep (Proxy :: Proxy x)) yes :: forall x. Typeable x => String -> IO () yes _ = print (typeRep (Proxy :: Proxy x)) }}} `no` fails to compile, saying that `x` type variable is not in scope. `yes` works just fine. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15033> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #2207: Load the interface details for GHC.* even without -O
by GHC 14 Apr '18

14 Apr '18

#2207: Load the interface details for GHC.* even without -O -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Azel): I'm willing to have a go at this issue, is anyone already working on it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2207#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10920: ghci can't load local Prelude module
by GHC 14 Apr '18

14 Apr '18

#10920: ghci can't load local Prelude module -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- I have a `Prelude.hs` file which contains {{{#!hs module Prelude where }}} If I invoke `ghci` from the same directory, I get {{{ Top level: attempting to use module ‘Prelude’ (./Prelude.hs) which is not loaded }}} Note: `ghc --make` correctly compiles modules that use the local `Prelude.hs`, so I expect `ghci` to handle that case too. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10920> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10631: Report of GHC Panic
by GHC 14 Apr '18

14 Apr '18

#10631: Report of GHC Panic -------------------------------------+------------------------------------- Reporter: seewalker | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'll just copy here the error message; I wouldn't say I have the judgement to interpret it: ''ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib, 5): Symbol not found: _AlexSzuELoZZpfyhWUk8IXGTl3Kiel_ModulesziDBTypes_zdfPersistFieldLinkTag_closure Referenced from: /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Expected in: flat namespace in /var/folders/84/5rj51n8x70g4km60lfh_ds1m0000gt/T/ghc22694_0/libghc22694_107.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug'' This occurred while interactively developing a website with "yesod devel". After the compiler crashed, I killed the program, invoked "yesod devel" again without changing anything in my source code. This next time, no error occurred. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10631> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X
by GHC 14 Apr '18

14 Apr '18

#2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: fixed => Comment: Didn't mean to close it, asking if we can close it? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2805#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2805: Test ffi009(ghci) fails on PPC Mac OS X
by GHC 14 Apr '18

14 Apr '18

#2805: Test ffi009(ghci) fails on PPC Mac OS X -------------------------------------+------------------------------------- Reporter: thorkilnaur | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: Runtime System | Version: 6.11 (Linker) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: ffi009(ghci) Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => closed * resolution: => fixed Comment: It's been 9 years since the bug was reported . Apple released Mac OS X v10.6 "Snow Leopard" on August 28, 2009 as Intel-only, removing support for the PowerPC architecture. It is also the last Mac OS X version that support PowerPC based applications. Can we close this as wontfix? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2805#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9307: wave4main in nofib fails
by GHC 14 Apr '18

14 Apr '18

#9307: wave4main in nofib fails -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: NoFib benchmark | Version: 7.8.3 suite | Operating System: MacOS X Keywords: wave4main | Type of failure: Incorrect result Architecture: x86_64 (amd64) | at runtime Difficulty: Unknown | Test Case: wave4main Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Compiling HEAD with perf-llvm, (3.4.2) and running the nofib suite fails at the wave4main case. It is not clear to me whether wave4main should always produce the same output (and so the test fails because it does not do so) or whether the numbers generated depend on some feature of the build settings, or OS. {{{ HC = /Users/xxx/Projects/ghc/inplace/bin/ghc-stage2 HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -cpp -fglasgow-exts -rtsopts RUNTEST_OPTS = -ghc-timing ==nofib== wave4main: size of wave4main follows... __TEXT __DATA __OBJC others dec hex 4091904 450560 0 4295947176 4300489640 1005443a8 ==nofib== wave4main: time to run wave4main follows... ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; ../../../runstdtest/runstdtest ./wave4main -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -o1 wave4main.stdout -o1 wave4main.stdout2 -o1 wave4main.stdout3 -ghc-timing 4000; real 0m0.217s user 0m0.191s sys 0m0.011s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16932.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.197s user 0m0.186s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest16961.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17011.1 2014-07-13 13:43:22.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.201s user 0m0.190s sys 0m0.008s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17051.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 real 0m0.200s user 0m0.189s sys 0m0.009s ././wave4main 4000 < /dev/null expected stdout not matched by reality --- wave4main.stdout 2014-07-08 20:57:14.000000000 +0100 +++ /var/folders/d9/94xh7l810mz3_skcsfh68khh0000gn/T//runtest17080.1 2014-07-13 13:43:23.000000000 +0100 @@ -1 +1 @@ -69923/1465 +69096/1465 make: *** [runtests] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9307> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4245: ghci panic: thread blocked indefinitely in an MVar operation
by GHC 14 Apr '18

14 Apr '18

#4245: ghci panic: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: pturnbull | Owner: tibbe Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.12.3 Resolution: | Keywords: MVar Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Comment (by George): I can't reproduce this on 8.4.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4245#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10367: "ghc: panic! (the 'impossible' happened)"
by GHC 14 Apr '18

14 Apr '18

#10367: "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: bgwines | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic | Operating System: MacOS X Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When running tasty-hunit tests through `cabal repl`, I get the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib, 9): Symbol not found: __hpc_tickboxes_horsezmcontrolzm0zi1zi0zi0_HorseziCommands_hpc Referenced from: /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Expected in: flat namespace in /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have a hunch that it's because I enabled the following flags in my .cabal file, since I didn't get the exception before adding them: {{{ Test-Suite test-horse ... GHC-Options: -fhpc -hpcdir dist/hpc/horse-control-1.0 }}} When I run the tests via `cabal test`, I don't get the exception. I've created a branch that showcases the crash: https://github.com/bgwines /horse-control/tree/ghc-panic Repro steps: * clone repo * cd to repo * run `cabal repl` * run `:l Tests/test-horse.hs` * run `main` Reproducability: 100% Please feel free to contact me if there's information lacking, here! :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10367> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12870: Allow completely disabling +RTS options parsing
by GHC 13 Apr '18

13 Apr '18

#12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- I'd like to have a way to completely disable the +RTS flag so that a ghc- compiled binary does not eat it, but keeps it in `argv`/`getArgs` instead. This is needed whenever you try to make a program that's supposed to pass on all arguments, for example something like `ccache` or [https://github.com/fpco/pid1 pid1]. As you can imagine, swallowing +RTS argument's isn't great when you want to pass them on to a Haskell program. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12870> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16