September 2013 - ghc-tickets

[GHC] #8282: Windows error building HEAD missing '_atomic_inc'
by GHC 13 Sep '13

13 Sep '13

#8282: Windows error building HEAD missing '_atomic_inc' ----------------------------------+---------------------------------------- Reporter: schyler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Pulled ad15c2b4bd37082ce989268b3d2f86a2cd34386a like so: {{{ make clean ./sync-all pull make }}} Error while building on Windows: {{{ Loading package ghc-7.7.20130912 ... linking ... ghc-stage2.exe: unable to load package `ghc-7.7.20130912' ghc-stage2.exe: C:\MinGW\msys\1.0\home\kvanberendonck\ghc\compiler\stage2\build\libHSghc-7.7.20130912.a: unknown symbol `_atomic_inc' make[1]: *** [libraries/dph/dph-lifted-copy/dist- install/build/Data/Array/Parallel/PArray/PData.o] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8282> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8051: GHCi: confusing `:set +m`/`:{` interaction & wrong line-numbers in multi-line input
by GHC 12 Sep '13

12 Sep '13

#8051: GHCi: confusing `:set +m`/`:{` interaction & wrong line-numbers in multi- line input ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- As mentioned in ticket:8047#comment:1 GHCi exhibits a line-numbering offset bug when multi-line input is evaluated. Morever, when `:set +m` is active, `:{`-entered multi-input may trigger multi-line input continuation, e.g.: {{{ Prelude> :set +m Prelude> :{ Prelude| let x = () Prelude| y = () Prelude| :} Prelude| z = () Prelude| Prelude> }}} The attached patch fixes both issues, but does so in an admittedly hacky way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4426: Simplify the rules for implicit quantification
by GHC 12 Sep '13

12 Sep '13

#4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #7880 -------------------------------------+------------------------------------ Changes (by monoidal): * difficulty: => Unknown * related: => #7880 Comment: See also comments at #7880. This change is not hard (I had a very rough sketch that detected ~4 missing quantifier errors in GHC tree) but it's too late for 7.8. Maybe I'll do it such that 7.10 will give a warning and 7.12 an error. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4426#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7880: Require "forall" in definitions of polymorphic types
by GHC 12 Sep '13

12 Sep '13

#7880: Require "forall" in definitions of polymorphic types ------------------------------------------------+-------------------------- Reporter: monoidal | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts invalid program | Unknown/Multiple Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: I see this exact proposal was created earlier: #4426. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7880#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by milan): * cc: fox@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7633: Checkable "minimal complete definitions"
by GHC 12 Sep '13

12 Sep '13

#7633: Checkable "minimal complete definitions" -------------------------------------+------------------------------------ Reporter: shachaf | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #6028 -------------------------------------+------------------------------------ Changes (by twanvl): * status: new => patch Comment: I found some time to polish the patch. I tried to address the points mentioned on this ticket. * The pragma is now parsed as a Sig instead of a separate declaration. * The minimal complete definitions are now specified with a boolean formula. For example {{{ {-# MINIMAL return, ((>>=) | (join,fmap)) #-} }}} * A warning is generated if the MINIMAL pragma does not cover all methods without defaults. * I have added documentation to the user_guide. * I have added some tests to the testsuite. The things I did not do: * dmwit sugested that the check should also extend to parent classes. I did not implement this, because it would complicate the patch significantly. Right now names are resolved locally to a class, and the information about whether a method is implemented is also kept per instance. * simonpj sugested that the check be moved from the typechecker to the renamer. However, to check that an instance satisfies the minimal complete definition, you need the `Class`. But that is only known after (or during) typechecking. The typechecker also does things like collecting default implementations. All of that is needed before the minimal complete check can be performed. In the end the in `TcInstDcl` check is only a couple of lines, I doubt it can be done much simpler. Some other remarks: * I put the function `defaultClassMinimalDef`, which constructs a default minimal complete definition, in `BuildTyCl`. It would be more at home in `TcClassDcl`. But there is also a function in vectorize that constructs Classes and so it also needs defaultClassMinimalDef. * I had to change the interface format. So a full rebuild is needed. * It would be nice to include the minimal complete definitions in Haddock documentation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7633#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5289: Can't use ghci with a library linked against libstdc++
by GHC 12 Sep '13

12 Sep '13

#5289: Can't use ghci with a library linked against libstdc++ -------------------------------------+------------------------------------ Reporter: bos | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by MichalGajda): On Windows, this bug seems also to prevent linking libraries that depend on double-conversion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5289#comment:48> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): Let me clarify what my concern here is: there are two ways to future proof your code against the upcoming export of `join` et al in 7.10: * Rename your local `join` function. * Hide the import from the `Prelude` (this is what the example above does). Both will work when 7.10 comes around. The problem is that the warning is overly trigger-happy; it warns if you go for option 2. Since people like to have warning free code, this means that in practice you have to go with the first option. There might be a good reason to have a function called `join` in your module, just like there might be a good reason to have a function called `map` (or any other `Prelude` name). I think the warning should be fixed such that it only happens if the code would actually break in 7.10. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 12 Sep '13

12 Sep '13

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------ Reporter: quchen | Owner: quchen Type: feature request | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * cc: johan.tibell@… (added) Comment: We're now seeing this warning in containers, but the obvious fix (hide `join` from the Prelude) does silence it! I expect this module to not generate a warning: {{{ module Foo (join) where import Prelude () join :: () join = () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8271: missing semicolon in rts/Linker.c
by GHC 12 Sep '13

12 Sep '13

#8271: missing semicolon in rts/Linker.c ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- {{{ --- /home/rwbarton/dist/ghc4/rts/Linker.c 2013-09-12 00:02:00.000000000 -0400 +++ /tmp/Linker.c 2013-09-12 00:14:57.000000000 -0400 @@ -1706,7 +1706,7 @@ return v; } } - v = dlsym(hdl, symbol) + v = dlsym(hdl, symbol); RELEASE_LOCK(&dl_mutex); return v; } }}} The missing ; is harmless when LOCK_DEBUG is not defined, because then the expansion of RELEASE_LOCK starts with a ; token. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4