- ghc-tickets - Haskell.org

[GHC] #16149: GHC for NetBSD
by GHC 23 Jan '19

23 Jan '19

#16149: GHC for NetBSD ---------------------------------------+--------------------------------- Reporter: gh1 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: NetBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- I tried to build GHC for NetBSD from source but it faild and it took a long time. So, may I ask for: a binaries for NetBSD or published manual how to build GHC from source for NetBSD ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #16155: Pattern Synonym for Ratio
by GHC 23 Jan '19

23 Jan '19

#16155: Pattern Synonym for Ratio -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.6.3 Libraries | Keywords: | Operating System: Unknown/Multiple PatternSynonyms, Ratio | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Data.Ratio` should export a simple pattern synonym that can be used by `Safe` code. {{{#!hs infixl 7 :%: pattern n :%: d <- n :% d where n :%: d = n % d }}} It'd be much simpler to use than `numerator` and `denominator`, and pattern matching on it would turn into a regular pattern match, hopefully for free. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12953: Use computed gotos in the interpreter when the compiler supports it
by GHC 23 Jan '19

23 Jan '19

#12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: interpreter | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We can use computed gotos to speed up the interpreter on systems that support them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12953> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16147: ghc-pkg deadlocks on macOS
by GHC 23 Jan '19

23 Jan '19

#16147: ghc-pkg deadlocks on macOS -------------------------------------+------------------------------------- Reporter: rvl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.3 System | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I run this script on macOS, after about 15 minutes, a `ghc-pkg` process will deadlock. {{{#!sh #!/usr/bin/env bash out=`pwd`/testing-package-db rm -rf $out cabal update cabal install random mkdir -p $out ghc-pkg init $out/package.conf.d while true; do ghc-pkg --package-db $HOME/.ghc/x86_64-darwin-8.6.3/package.conf.d dump | ghc-pkg --force --package-db $out/package.conf.d register - done }}} Output from `sw_vers`: {{{ ProductName: Mac OS X ProductVersion: 10.12.6 BuildVersion: 16G29 }}} This GHC build comes from the latest nixpkgs-18.09. I have also attached a nix file to build test scripts. We noticed that if we edited the ghc-pkg binary to link with the threaded RTS, then we could not reproduce the deadlock (after running the test script for 24 hours). Attached is the output from `/usr/bin/sample` for the stuck process, and the `otool -L ghc-pkg` output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14)
by GHC 23 Jan '19

23 Jan '19

#16153: ghc 8.6.3 fails to build on macOS Sierra, High Sierra and Mojave (10.12 to 10.14) -------------------------------------+------------------------------------- Reporter: fxcoudert | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We at Homebrew are trying to upgrade the ghc version we ship to 8.6.3. However, many test failures are occurring: https://github.com/Homebrew /homebrew-core/pull/35773 {{{ SUMMARY for test run started at Tue Jan 8 18:16:47 2019 GMT 0:55:14 spent to go through 6521 total tests, which gave rise to 25300 test cases, of which 18851 were skipped 28 had missing libraries 5900 expected passes 90 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 422 unexpected failures 8 unexpected stat failures }}} I am attaching the full build output. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16153> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction)
by GHC 22 Jan '19

22 Jan '19

#16191: GHC Panic deriving unbox vector (StrictData/unbox-strict-fields interaction) -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached program fails to compile with the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-unknown-linux): mkNewTyConRhs MV_V [Int#, MVector s_a7WC[sk:1] a_a7WA[sk:1], MVector s_a7WC[sk:1] a_a7WA[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:65:27 in ghc:BuildTyCl }}} Removing either of the -funbox-strict-fields or StrictData pragma allow the code to compile correctly, but you do need to compile with -O to get the incorrect behaviour -ghci is fine loading the module. Although I wouldn't expect them to interact here as I don't get the same behaviour if I explicitly write out what would be implied by the flag and pragma: {{{ data V a = V {-# UNPACK #-} !a {-# UNPACK #-} !a deriving (Show) }}} just warnings about the unused UNPACKs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16191> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16209: GHC behaves differently when binding has separate or inlined type declaration
by GHC 22 Jan '19

22 Jan '19

#16209: GHC behaves differently when binding has separate or inlined type declaration -------------------------------------+------------------------------------- Reporter: fghibellini | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () = a putStrLn "success" }}} fails with: {{{ source_file.hs:6:44: Couldn't match expected type ‘forall (u :: * -> *). Functor u => u ()’ with actual type ‘t0 ()’ When checking that: t0 () is more polymorphic than: forall (u :: * -> *). Functor u => u () In the expression: a }}} but the following compiles successfully {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} main = do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} On GHC 7.10 it works as described above. On newer ones it fails even on the "functioning code". {{{ a.hs:5:44: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: forall (t :: * -> *). Functor t => t () GHC doesn't yet support impredicative polymorphism • In the expression: undefined In a pattern binding: a :: forall (t :: * -> *). Functor t => t () = undefined In the expression: do let a :: forall t. Functor t => t () = undefined let g :: forall u. Functor u => u () g = a putStrLn "success" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16215: Refactor getProgramContext in Hadrian
by GHC 22 Jan '19

22 Jan '19

#16215: Refactor getProgramContext in Hadrian -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- All the calls to `getProgramContext` in Hadrian are immediately passed to `programPath` so to avoid confusion the two functions should probably be combined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14475: Upload documentation dumps
by GHC 22 Jan '19

22 Jan '19

#14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | 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: -------------------------------------+------------------------------------- Having a nightly job that would update https://downloads.haskell.org/~ghc/master/users-guide/ would be lovely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14475> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
by GHC 22 Jan '19

22 Jan '19

#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by atravers): So there's still some interest after all. I had thought about providing some details about my prototype implementation (e.g. how it avoids the "all-in-one" approach) but having read [a draft of] the Melton-Tempero paper (and various others over the break) I now pause to consider a question: ''Are recursive imports taking recursion a step too far?'' To use a automotive analogy - oil works well for certain parts of the typical car (e.g. engine and gearbox) but that doesn't mean oil would work just as well for other parts of the car (e.g. brakes and clutches). With 2020 on the horizon, and drawing some inspiration from a few of those other papers (and, well, Douglas Adams), I now suggest the following: 1. Support for recursive imports be **withdrawn** from the new Haskell 2020 standard; 2. A new proposal for recursive imports be added to the Haskell-proposals page of the Haskell wiki site, where a concise description can be made along with a list of subsequent problems, for the intrepid to find solutions to. 3. If those solutions are viable, then recursive imports would be reinstated in a post-2020 Haskell standard. The intent is that the proposal-page be ''the'' central point of reference for everything related to implementing recursive imports instead of being scattered far and wide as it is now - a veritable clearing-house for old and new ideas and suggestions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1409#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0