April 2017 - ghc-tickets

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13609: regression: `ANN` pragmas for TH-less GHCs no longer ignored in GHC 8.2.1
by GHC 01 May '17

01 May '17

#13609: regression: `ANN` pragmas for TH-less GHCs no longer ignored in GHC 8.2.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.2.1-rc1 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: -------------------------------------+------------------------------------- Consider {{{#!hs module M where {-# ANN myId "HLint: ignore" #-} myId :: a -> a myId x = x }}} GHC 8.0.2 would simply ignore them: {{{ $ ghc-8.0.2 -c M.hs M.hs:3:1: warning: Ignoring ANN annotation, because this is a stage-1 compiler or doesn't support GHCi }}} however, with a recent GHC 8.2 snapshot this just fails with {{{ $ ghc-8.2 -c M.hs ghc: this operation requires -fexternal-interpreter }}} This is a serious problem because `hlint` annotations are quite popular, and this would require us to retrofit `other-extensions: TemplateHaskell` into the meta-data of quite a few packages on Hackage to declare that a package no longer works with a TH-less GHC (which would basically mean that ports of GHC such as the one for AIX that don't support TH will become very inconvenient to use and require to pester package authors to explicitly guard `ANN` pragmas with CPP... which I'm not looking forward to ;-) ). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13577: Compiler performance on open-symbology parser module regressed in GHC 8.2
by GHC 30 Apr '17

30 Apr '17

#13577: Compiler performance on open-symbology parser module regressed in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Thanks to hvr from mentioning this. https://hackage.haskell.org/package/open-symbology-0.1/docs/src/Finance- OpenSymbology-PricingSourceParsers.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13577> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12974: Solution to regular expression is no longer valid
by GHC 30 Apr '17

30 Apr '17

#12974: Solution to regular expression is no longer valid -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: 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: -------------------------------------+------------------------------------- The following HUnit test code {{{#!hs module Main where import Test.HUnit import Text.Regex.Posix testRegexSimple :: Test testRegexSimple = TestCase $ do assertBool "pattern matches regex ^(a)|(p)$" ( "p" =~ "^(a)|(p)$" ) testRegex :: Test testRegex = TestCase $ do assertBool "pattern matches regex ^(ab+c*d?)|(ef{2}g{3,6}h{3,})|(p)$" ( "p" =~ "^(ab+c*d?)|(ef{2}g{3,6}h{3,})|(p)$" ) tests = TestList [ TestLabel "Regex Simple" testRegexSimple, TestLabel "Regex" testRegex ] main :: IO Counts main = do runTestTT tests }}} runs perfectly using Haskell platform 2013.2.0.0 with ghc 7.6.3. However, on stack LTS 7.13 with ghc 8.0.1 the second test fails! I assume this behaviour is the result of a bug. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12974> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13618: Reified data family instances type variables not related to value constructor fields
by GHC 30 Apr '17

30 Apr '17

#13618: Reified data family instances type variables not related to value constructor fields -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the reify template-haskell operation on a data family, the returned data instances lose the relationship between the type variables in the parameters and those in the value constructors. In this paste I show that reify forgets the relationship, but that declaration splices preserve it. Note the two occurrences of a_6989586621679027007 . I would specifically expect the occurences of a_6989586621679015819 and a_6989586621679015790 to be the same. The code that implements this reification is in compiler/typecheck/TcSplice.hs , the template-haskell package merely exposes the functionality, so this is why I've specified "compiler (type checker)" I've confirmed that this bug exists in GHC 8.0.2 and 8.2.1-rc1. I suspect it exists in older versions, too. {{{#!haskell $ /Users/emertens/Tools/ghc-8.2.1-rc1/bin/ghci GHCi, version 8.2.0.20170404: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies Prelude> :set -XTemplateHaskell Prelude> import Language.Haskell.TH Prelude Language.Haskell.TH> import Text.Show.Pretty (ppShow) Prelude Language.Haskell.TH Text.Show.Pretty> data family DF a; data instance DF [a] = DFList a Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< reify ''DF) FamilyI (DataFamilyD Ghci1.DF [ KindedTV a_6989586621679015789 StarT ] (Just StarT)) [ DataInstD [] Ghci1.DF [ AppT ListT (VarT a_6989586621679015819) ] Nothing [ NormalC Ghci1.DFList [ ( Bang NoSourceUnpackedness NoSourceStrictness , VarT a_6989586621679015790 ) ] ] [] ] Prelude Language.Haskell.TH Text.Show.Pretty> putStrLn $(stringE . ppShow =<< [d| data family DF a; data instance DF [a] = DFList a |]) [ DataFamilyD DF_6989586621679027004 [ PlainTV a_6989586621679027006 ] Nothing , DataInstD [] DF_6989586621679027004 [ AppT ListT (VarT a_6989586621679027007) ] Nothing [ NormalC DFList_6989586621679027005 [ ( Bang NoSourceUnpackedness NoSourceStrictness , VarT a_6989586621679027007 ) ] ] [] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13487: GHC panic with deferred custom type errors
by GHC 30 Apr '17

30 Apr '17

#13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm working on a music composition library that enforces composition rules at the type level. It makes heavy use of TypeInType and custom compiler errors. For example, it disallows dissonant major seventh intervals (e.g., a C and a B) in harmonic composition. While testing the library, I encountered a GHC panic which I haven't seen anywhere – unfortunately I don't know enough about GHC to understand what is causing the panic and couldn't reproduce it in simpler examples. I was hoping that you could point me in the right direction so that I can find a smaller program that reproduces the error. In GHCi, with the -fdefer-type-errors flag set, the following code (which should throw a custom type error as it describes composing a B quarter note with a C quarter note) produces a panic: {{{ λ: let t = c qn :-: b qn <interactive>:21:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: C and B • In the expression: c qn :-: b qn In an equation for ‘t’: t = c qn :-: b qn ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCeG Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This does not appear when loading a source file, or when -fdefer-type- errors is disabled, and only happens when the expression is assigned to a new value. A lot of the literals in the library are generated by TemplateHaskell, but the error happens without them as well: {{{ λ: let s = Note (Root :: Root (PitchRoot (Pitch B Natural Oct4))) (Dur :: Dur Quarter ) λ: let t = Note (Root :: Root (PitchRoot (Pitch C Natural Oct4))) (Dur :: Dur Quarter ) λ: let v = s :-: t <interactive>:27:9: warning: [-Wdeferred-type-errors] • Can't have major sevenths in chords: B and C • In the expression: s :-: t In an equation for ‘v’: v = s :-: t ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): nameModule system irred_aCnF Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The library is available on Hackage (https://hackage.haskell.org/package/mezzo) and the error is reproducible as soon as the main module is loaded. I'd happily try to find a smaller example which gives the same error, so I was hoping that you might have some ideas about what could be going wrong. Thank you! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13487> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #13500: GHCi preprocesses every source file on :reload
by GHC 30 Apr '17

30 Apr '17

#13500: GHCi preprocesses every source file on :reload -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 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): Phab:D3398 | Wiki Page: -------------------------------------+------------------------------------- This is a regression in 8.0 caused by 5d48e67fac952f7188fc9ebcfbf6e3ccb9b75705 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13500> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13557: error found hole: _ is not appropriate in the following case
by GHC 30 Apr '17

30 Apr '17

#13557: error found hole: _ is not appropriate in the following case -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ f :: [Char] f = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True,False,True,False,True]] f' :: [Char] f' = [x | x <- ['a', 'b'], y <- (undefined:undefined:undefined:[]), z <- [1,2,3,4], r <- [True, False, True, False, True], s <- [_, _, _, _, _, _]] main :: IO () main = do print f print f' }}} When the code is compiled with the function {{{f}}} the result is the following:\\ {{{ "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb" }}} If we add in {{{f}}} the code {{{s <- [_, _, _, _, _, _]}}} to become the function {{{f'}}} and then compile the program, the following error is displayed.\\ {{{ test11.hs:5:131: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:134: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:137: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:140: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:143: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) test11.hs:5:146: error: * Found hole: _ :: t0 Where: `t0' is an ambiguous type variable * In the expression: _ In the expression: [_, _, _, _, ....] In a stmt of a list comprehension: s <- [_, _, _, _, ....] * Relevant bindings include r :: Bool (bound at test11.hs:5:86) z :: Integer (bound at test11.hs:5:70) y :: t1 (bound at test11.hs:5:29) x :: Char (bound at test11.hs:5:12) f' :: [Char] (bound at test11.hs:5:1) }}} I think that here the wildcard pattern _ is justified and does not have to give this error and must be used as undefined.\\ So this error makes no sense here.\\ I propose to make a correction in this case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13602: Pattern syntax in expression context must be clarified
by GHC 30 Apr '17

30 Apr '17

#13602: Pattern syntax in expression context must be clarified -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To simonpj\\ see tickets {{{#13557}}} and {{{#13579}}}\\ Typed Holes does not exist if we compile with GHC version 7.6.3. Instead of "error found holes" it indicates "pattern syntax in expression context: _".\\ I then understood that to improve Typed Holes it was first necessary to remove the ambiguity of the error in GHC 7.6.3 about pattern syntax in expression.\\ {{{let f = [True | x <- [_, _]]}}} raise the error {{{pattern syntax in expression context: _}}}\\ But as Typed Holes, this error has no sense here.\\ {{{let f' = [_ | x <- [1,2]]}}}will give a result like {{{"__"}}} And this calculation also makes sense if one refers to the rule of inference, as the function {{{f}}} .\\ \\ The compiler should not impose its way.\\ The programmer must be the master of his code. Here the rule of inference seems flouted.\\ Good sense or reason is argued to be the same in all people, yet differences in opinion are not due to differences in intelligence but to the fact that we use different approaches and consider different things.\\ Here you will find some ideas:\\ Instead of "underscore _" as "pattern syntax" we could use a new type called "indefinite" in expression.\\ Any calculation with "indefinite" will result in "indefinite".\\ In another calculation, the "indefinite" type could have a type defined according to a directive applied to the compiler.\\ example:\\ indefinite :: Int\\ f = [1,2,3,indefinite,5,6]\\ I took a look at ticket {{{#9497}}} and find it very interesting.\\ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles
by GHC 30 Apr '17

30 Apr '17

#13579: -fdefer-type-errors and -fdefer-typed-holes flag do not perform their roles -------------------------------------+------------------------------------- Reporter: vanto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- with {{{-fdefer-type-errors}}} flag\\ Prelude > {{{let f = [True | x <- [_,_]]}}} raise two warning. Good!.\\ Prelude > {{{f}}}\\ {{{[True, True]}}}\\ With this function \\ Prelude> {{{let f' = [True | x <- [_, _]] in f'}}}\\ GHCi raise two errors. It is not clear! idem with {{{-fdefer-typed-holes}}} flag\\ If you compile, there is a warning and of course no result and after linking an error is raise. This situation is not clear for me.\\ Logically it should have a result.\\ logically the function {{{f}}} and the function {{{f'}}} send a result.\\ Typed Holes worsens in this case -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1