- ghc-tickets - Haskell.org

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 02 May '17

02 May '17

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => (none) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #12913: Port SplitSections to Windows
by GHC 02 May '17

02 May '17

#12913: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D3382 Wiki Page: | Phab:D3383 Phab:D3523 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * differential: Phab:D3382 Phab:D3383 => Phab:D3382 Phab:D3383 Phab:D3523 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12913#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows
by GHC 02 May '17

02 May '17

#13515: Unexpected failure of T11223_simple_duplicate_lib on 32-bit Windows --------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- The `T11223_simple_duplicate_lib` test seems to fail on 32-bit Windows with, {{{#!patch diff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib .stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib .stderr-mingw32 index 4d4656f..5fdd70f 100644 --- a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr- mingw32 +++ b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr- mingw32 @@ -1,15 +1,15 @@ GHC runtime linker: fatal error: I found a duplicate definition for symbol - a + _a whilst processing object file - E:\ghc- dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a + C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\libfoo_dup_lib.a The symbol was previously defined in - E:\ghc- dev\msys64\home\Tamar\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o + C:\msys64\home\ben\ghc\testsuite\tests\rts\T11223\T11223_simple_duplicate_lib.run\bar_dup_lib.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. -ghc-stage2.exe: ^^ Could not load 'c', dependency unresolved. See top entry above. +ghc-stage2.exe: ^^ Could not load '_c', dependency unresolved. See top entry above. ByteCodeLink: can't find label }}} While this difference looks innocuous enough, I can't recall anything in recent history that would cause such a change so I want to make sure we have a record of it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13515> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #2893: Implement "Quantified contexts" proposal
by GHC 01 May '17

01 May '17

#2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal 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 dfeuer): Replying to [comment:12 heisenbug]: > Copying a use-case from #9196: > > My point is that I'd like to have polymorphic (multiparameter) constraints, where the param universally abstracted over is a non-`*` kind, that is an ADT. > > See: > {{{ > class Foo a where ... > data Bar (b :: Bool) x = ... > instance Foo (Bar True x) where ... > instance Foo (Bar False x) where ... > > test :: (forall b. Foo (Bar b x)) =>... > }}} > Here the `forall` condition is satisfiable, as all `Bool` alternatives are covered with `instance` declarations. Actually, the `forall` condition is ''not'' satisfiable. The smaller problem is that stuck type families like `Any` can inhabit `Bool` without being `'True` or `'False`. The bigger problem is that Haskell's "logic" is inherently constructive. The claim that for any type `b :: Bool` there exists some instance `Foo b x` does not translate to a way to actually get the dictionary representing that instance. So I think your beautiful dream is, sadly, almost certainly unrealizable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2893#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[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 01 May '17

01 May '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