May 2017 - ghc-tickets

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 22 May '17

22 May '17

#1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2: rewrite rules, forall, no -fglasgow-exts
by GHC 22 May '17

22 May '17

#2: rewrite rules, forall, no -fglasgow-exts -------------------------------------+---------------------- Reporter: nobody | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: None Resolution: Fixed | Keywords: Type of failure: None/Unknown | -------------------------------------+---------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3: DiffArray should be instance of Show
by GHC 22 May '17

22 May '17

#3: DiffArray should be instance of Show --------------------------------+-------------------- Reporter: magunter | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: hslibs/lang | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"83ee930fdd125d74939307ed3fa1bf6a2ba7fb36/ghc" 83ee930f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83ee930fdd125d74939307ed3fa1bf6a2ba7fb36" fix a memory leak in osNumaMask got an error when using asan: ``` ==1866689==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 1 object(s) allocated from: #0 0x10640568 in malloc ??:? #1 0x154d867e in numa_bitmask_alloc .../numactl-2.0.8/libnuma_nosymve r.c:204 #2 0x154d867e in numa_allocate_nodemask .../numactl-2.0.8/libnuma_nosymve r.c:724 #3 0x154d867e in numa_get_mems_allowed .../numactl-2.0.8/libnuma_nosymve r.c:1141 #4 0x10b54a45 in osNumaMask ...ghc-8.0.2/rts/posix/OSMem.c:59 8 ``` Test Plan: compile, validate Reviewers: simonmar, niteria, austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3537 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13734: Code requires ScopedTypeVariables, possibly erroneously
by GHC 22 May '17

22 May '17

#13734: Code requires ScopedTypeVariables, possibly erroneously -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- This doesn't work without `ScopedTypeVariables`, but shouldn't it? (on `8.0.1`, 8.2.0.20170507`) {{{#!hs {-# Language ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes, InstanceSigs #-} class Sized f where size :: Int instance Sized Int where size :: Int size = 42 instance (Sized a, Sized b) => Sized (a, b) where size :: Int size = size @a + size @b }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9445: GHC Panic: Tick Exhausted with high factor
by GHC 22 May '17

22 May '17

#9445: GHC Panic: Tick Exhausted with high factor -------------------------------------+------------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: panic | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: 5539 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Hello guys, this is an old bug which has been reported so many times that I'm not sure this will be noise or something useful. In a nutshell I have been hit by this bug installing the library "SFML", which relies heavily on FFI. The only interesting thing of this report is that it was necessary an very high simpl-factor to make the installation go through! Pre-bump: {{{ Resolving dependencies... In order, the following will be installed: SFML-0.2.0.0 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring SFML-0.2.0.0... Building SFML-0.2.0.0... Preprocessing library SFML-0.2.0.0... [...] [34 of 71] Compiling SFML.Graphics.Transform ( dist/build/SFML/Graphics/Transform.hs, dist/build/SFML/Graphics/Transform.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Simplifier ticks exhausted When trying UnfoldingDone $j_sZQW{v} [lid] To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 2655928 }}} And this was the magic line: {{{ cabal install SFML --ghc-option=-fsimpl-tick-factor=1630 }}} HTH, it turns out it's quite an annoying one! And yes, "1630" was the smaller factor which made the installation possible. Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9445> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9700: Support C structures in Haskell FFI
by GHC 22 May '17

22 May '17

#9700: Support C structures in Haskell FFI -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D252 -------------------------------------+------------------------------------- This ticket is for tracking progress on [[CStructures]] language extension proposal. The idea is to support C structures in Haskell FFI. See wiki for details. If it will be accepted, I'm going to implement it in few steps. The first one is to support structures as return value. Platform specific part for that is already implemented, see Phab:D252 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9700> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13741: Newtype unwrapping causes GHC panic
by GHC 22 May '17

22 May '17

#13741: Newtype unwrapping causes GHC panic -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: newtype ghci | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some combination of newtypes and infix operators is causing GHCi to panic. Steps to reproduce: 1. Open a fresh GHCi session. 2. Define `Cont`: `newtype Cont a r = Cont {(>>-) :: (a -> r) -> r}` 3. Define a `Functor` instance for `Cont`: `instance Functor (Cont r) where fmap f c = Cont $ \k -> c >>>- f . k` 4. Observe the following: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): get_op >>>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13740: GHC panic with operator constructor of newtype
by GHC 22 May '17

22 May '17

#13740: GHC panic with operator constructor of newtype -------------------------------------+------------------------------------- Reporter: codebje | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code causes a GHC panic: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- a . b }}} This slight modification, however, is fine: {{{ newtype Cont r a = Cont { (>>-) :: (a -> r) -> r } x = \a b c -> c >>- (a . b) }}} The presence or absence of a type signature for `x` makes no difference. Compiling with "-v" suggests the panic occurs during type checking: {{{ Glasgow Haskell Compiler, Version 8.0.2, stage 2 booted by GHC version 7.10.3 Using binary package database: /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d/package.cache Using binary package database: /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache Using binary package database: /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb/package.cache loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /Users/bje/.stack/programs/x86_64-osx/ghc-8.0.2/lib/ghc-8.0.2/package.conf.d loading package database /Users/bje/.stack/snapshots/x86_64-osx/lts-8.8/8.0.2/pkgdb loading package database /Users/bje/.stack/global/.stack- work/install/x86_64-osx/lts-8.8/8.0.2/pkgdb wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.1.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.1.0 wired-in package ghc mapped to ghc-8.0.2 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *panic.hs !!! Chasing dependencies: finished in 0.57 milliseconds, allocated 0.224 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-05-22 07:07:41 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file panic.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( panic.hs, panic.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.38 milliseconds, allocated 0.209 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): get_op >>- Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13740> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13728: Clarify the difference between NameL and NameU in Template Haskell
by GHC 21 May '17

21 May '17

#13728: Clarify the difference between NameL and NameU in Template Haskell -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- Reading the docs in Language.Haskell.TH.Syntax, I got the impression that when reifying the type {{{#!hs data P a b = P a b }}} defined outside of TH, the type variables a and b will be NameLs; but in my experiments, they come out as NameUs. Are NameLs used anywhere at all? In any case, I think the docs should be updated to explain the difference clearly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing.
by GHC 21 May '17

21 May '17

#11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11593> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2