- ghc-tickets - Haskell.org

Re: [GHC] #7730: :info and polykinds
by GHC 11 Jun '14

11 Jun '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by archblob): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9062: Role: ~# should be ~R#
by GHC 11 Jun '14

11 Jun '14

#9062: Role: ~# should be ~R# ------------------------------------+--------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The following coercion showed up in Core. Richard Eisenberg pointed out that the `~#` should be `~R#`. {{{ <Tree N0 Int>_R -> NTCo:Sum[0] <Int>_R :: (Tree N0 Int -> Sum Int) ~# (Tree N0 Int -> Int) }}} I can dig up more information if needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9167: Associated type is accepted even without mentioning class parameters
by GHC 11 Jun '14

11 Jun '14

#9167: Associated type is accepted even without mentioning class parameters ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The following module is accepted: {{{ {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type F b }}} Note that the associate type family `F` does not mention the class variable `a`. Because associated type families are somewhat thin sugar over non-associated type families, I doubt this causes any great disaster anywhere, but it should probably be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo
by GHC 11 Jun '14

11 Jun '14

#7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by thomie): * status: closed => new * cc: hvr (added) * component: Compiler => Trac & Git * version: 7.6.2 => * owner: => hvr * resolution: fixed => Comment: Running {{{./sync-all get}}} will now execute {{{'git reset --hard'}}} if core.autocrlf=true, which could result in data loss when uncommitted changes are present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7673#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9193: GHC panic usinig HList and Lens
by GHC 11 Jun '14

11 Jun '14

#9193: GHC panic usinig HList and Lens -------------------------------------------+------------------------------- Reporter: maxigit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: x86 | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: GHCi crash Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- This bug might have been fixed in GHC 7.8.2 but I haven't been able to test it. Some packages required to reproduce the bug are broken under 7.8.*. GHC 'panic' whilst trying to compile the following. Strangely, removing doing the last line of code 'manually' in ghci works. {{{ {-# LANGUAGE TypeFamilies, DataKinds, PolyKinds, TypeOperators #-} {-# LANGUAGE NoMonomorphismRestriction #-} module Database.Harehouse.SQLFragment where import Data.HList import Control.Lens hiding(from) x = hLens' (Label :: Label "x") }}} Note. I'm using HList-0.3.4.1 and lens-4.1.2.1. I think it wasn't working with lens 4.2 either, but since I tried to install ghc 7.8.2 I haven't be able to reinstall lens 4.2. (cabal hell). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9193> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni
by GHC 11 Jun '14

11 Jun '14

#9187: Reduce number of missing wiki links by setting ignore_missing_pages in TracIni -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The GHC wiki currently has lots of missing links, which makes for harder reading. A partial solution, from http://trac.edgewall.org/wiki/CamelCase: "There's an option (ignore_missing_pages in the [wiki] section of TracIni) to simply ignore links to missing pages when the link is written using the CamelCase style, instead of that word being replaced by a gray link followed by a question mark." Could this option be set for the GHC wiki? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9187> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9164: Hunt down uses of `castPtr`
by GHC 11 Jun '14

11 Jun '14

#9164: Hunt down uses of `castPtr` ------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This bug is a fork from #9163: nomeata: Slightly off topic, but maybe `GHC.IO.Handle.Text` can be written so that `castPtr` is not needed. It seems it always works with `Ptr Word8`, but exposes an API that uses `Ptr a` as a generic pointer. The type `a` is never needed inside `GHC.IO.Handle.Text`... I tried it, and `hPutBuf` & Co are called with `Ptr Word8` (sometimes called LitString) in all cases but `BufWrite.bPutCStringLen`, where we have a `Ptr CChar`, where `CChar` is a newtype. So by using coerce there (and `unsafeCoerce` during bootstrapping), we get the best of boths worlds: The more restrictive role and the free behaviour. SPJ: Well regardless of the decision about the role of `Ptr`, what you describe sounds like an improvement anyway, getting rid of (always suspicious) `castPtr` calls. If you grep in the base library you'll find quite a few others. Can you eliminate them in the same way? I think this would be a nice improvement, if you cared to push it through. simonmar: So I've been assuming that `castPtr` was free all this time, and it turns out it isn't! Please make it free. We can't change the type of `hPutBuf` and friends without potentially breaking code. There's no better choice than `Ptr a` here, because we don't know the type of the underlying data. Making it `Ptr Word8` would just force the caller to use `castPtr` sometimes without any benefit. e.g. `Ptr CChar` is also a sensible choice, but it could in reality be anything. It does look like the two `castPtrs` in `bufWrite` are unnecessary, though. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9164> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #4442: Add unaligned version of indexWordArray#
by GHC 10 Jun '14

10 Jun '14

#4442: Add unaligned version of indexWordArray# --------------------------------------+------------------------------------ Reporter: tibbe | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: libraries (other) | Version: 7.1 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: duncan (added) * difficulty: => Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4442#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3372: Allow for multiple linker instances
by GHC 10 Jun '14

10 Jun '14

#3372: Allow for multiple linker instances -------------------------------------+------------------------------------ Reporter: jcpetruzza | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by thomie): Corresponding wiki page: [wiki:MultipleLinkerInstances] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3372#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 10 Jun '14

10 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by ross): Replying to [comment:22 jstolarek]: > > They are subsets of xs: xs1 is the variables used by c, while xs2 is the > > variables used by ss but not bound in p. So the command 'c' gets local > > environment xs1 and stack (). The translations of statements are arrows that > > take an environment (here xs2) as input. > > That starts to make sense :-) As I understand `x1` and `x2` need not be > disjoint - is that correct? That's right. If a variable is used by both `c` and `ss`, it will be in both sets. > I am yet to understand the rules for encoding the input parameters to the arrows. > Is there a general rule that says when and in what order things are put on the stack? > Is it the case that elements on the stack are never accessed and need to be popped > if they are to be used? Things are added to the stack by `HsCmdApp` and removed with `HsCmdLam`, but stacks can also be modified by `HsCmdArrForm` - there are some examples in the "Primitive constructs" section in teh arrow notation part of the GHC User's Guide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0