December 2015 - ghc-tickets

[GHC] #11275: :kind! doesn't reduce type families with poly-kinded return kinds
by GHC 21 Dec '15

21 Dec '15

#11275: :kind! doesn't reduce type families with poly-kinded return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- Originally discovered [https://mail.haskell.org/pipermail/ghc- devs/2015-December/010831.html here], here is a simplified example: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XTypeFamilies λ> type family Hm :: k where Hm = Int λ> :kind! Hm Hm :: k = Hm }}} Giving `Hm` a monomorphic return kind of `*` makes it work with `:kind!`: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeFamilies λ> type family Hm :: * where Hm = Int λ> :kind! Hm Hm :: * = Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11147: Linker errors related to response files change
by GHC 21 Dec '15

21 Dec '15

#11147: Linker errors related to response files change -------------------------------------+------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, Building GHC HEAD in Nix on Linux currently fails with linker errors. See https://github.com/NixOS/nixpkgs/issues/10752 The problem goes away if one reverts GHC commit 296bc70b5ff6c853f2782e9ec5aa47a52110345e. I don't know what the issue is, and I can't be 100% sure it's really a GHC problem and not a Nix one, but I thought it best to record this here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11256: ghc --make reports bad import errors too eagerly
by GHC 21 Dec '15

21 Dec '15

#11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- Consider this A.hs file, with a valid header (no B.hs file) and a syntax error: {{{ module A where import B = as7df89a235r a23jk @A#$(&#$A }}} We get different behavior when one-shot compiling and make compiling: {{{ ezyang@sabre:~$ ghc -c A.hs A.hs:4:1: parse error on input `=' ezyang@sabre:~$ ghc --make A.hs A.hs:2:8: Could not find module `B' Use -v to see a list of the files searched for. }}} I feel like the `--make` error is wrong, and we shouldn't actually complain that an import is missing until we build it. But it cuts both ways; if you have a big module graph and you try to `--make`, currently `--make` will report instantaneously if any import is wrong; if we changed this behavior, `--make` would chug along until it actually tried to compile the offending file. It's easy to fix and I can easily submit a patch for it, if people think we should defer the error. Doing this will also let me remove a grievous hack from my fix to #11244. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11210: Missing instances for Identity and Const
by GHC 21 Dec '15

21 Dec '15

#11210: Missing instances for Identity and Const -------------------------------------+------------------------------------- Reporter: duairc | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 7.11 libraries/base | Keywords: g | 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 instances are all permissible yet are not defined. They can all be derived with {{{GeneralizedNewtypeDeriving}}}. It would be useful for me if they were defined in {{{base}}}. These should probably also go into {{{base-orphans}}} and {{{transformers}}} (for versions of {{{base}}} before {{{Identity}}} was moved there). {{{#!hs instance Bounded a => Bounded (Const a b) instance Enum a => Bounded (Const a b) instance Ix a => Bounded (Const a b) instance Semigroup a => Semigroup (Const a b) instance Bounded a => Bounded (Identity a) instance Enum a => Bounded (Identity a) instance Ix a => Bounded (Identity a) instance Semigroup a => Semigroup (Identity a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 21 Dec '15

21 Dec '15

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: 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 goldfire): I think this will be quite easy, actually. You're hunting in all the right places. `getInitialKind` does indeed assume a result of kind `*`. (A kind sig ''can'' be provided via `newtype Blah :: * -> * where ...` as if you're defining a GADT. That is, GADT syntax works with newtypes just fine.) But I don't think anyone gets hurt if you assume that the return kind is `TYPE v` for a fresh levity metavariable `v`. You may need to unify that result kind with `*` in the datatype case somewhere. You'd need to check that the result kind of the newtype matches the kind of the representation type. I think this would happen in `kcConDecl`. One annoying bit is that we have no surface syntax (other than `TYPE 'Unlifted`) for `#`. I suppose you could add `type UnliftedType = TYPE 'Unlifted` in `Data.Kind` if you felt it worthwhile. I really don't think it would be much harder than this. Go for it! :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10828: TH can't represent all GADTs in its AST
by GHC 21 Dec '15

21 Dec '15

#10828: TH can't represent all GADTs in its AST -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- For example, it's impossible to add a kind signature on a data type with `DataD`. In {{{Con}}} I believe it's possible to encode GADT constructor signatures using {{{NormalC}}} (haven't tried this yet), but ideally there would be another constructor specific to GADTs to go along with {{{RecC}}}, {{{InfixC}}}, and {{{ForallC}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10828> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #11270: "Unusable UNPACK pragma" warnings should be printed even without -O
by GHC 21 Dec '15

21 Dec '15

#11270: "Unusable UNPACK pragma" warnings should be printed even without -O -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- UNPACK pragmas are ignored when -O is not used, and this is very annoying when developing inside GHCi. Example: {{{ ➜ unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp --make [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} No warning printed even though I used {{{-Wall}}}. If I add {{{-O}}}: {{{ ➜ unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp --make -O [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:5:13: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘Blah’ • In the definition of data constructor ‘Blah’ In the data type declaration for ‘Blah’ Linking Main ... }}} This is very annoying, because {{{-O}}} is ignored in GHCi: {{{ ➜ unpack_warning ghc-stage2 Main.hs -Wall -fforce-recomp -O --interactive when making flags consistent: warning: -O conflicts with --interactive; -O ignored. GHCi, version 7.11.20151220: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Main.hs, interpreted ) Ok, modules loaded: Main. }}} So basically there's no way to get these warning in GHCi. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11270> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11264: Previously compiling example does not compile
by GHC 21 Dec '15

21 Dec '15

#11264: Previously compiling example does not compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 21 Dec '15

21 Dec '15

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: 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 osa1): I'd like to give this a try, Richard, where should I start? I don't understand typechecking/ parts too well. As far as I can see, {{{kcTyClGroup}}} is kind checking type declarations, and {{{getInitialKind}}} is generating {{{liftedTypeKind}}} unless a kind signature is given (I don't understand how can kind signatures be used with newtypes, maybe that case is impossible?). Is it possible to do this by just generalizing the current code, instead of adding special cases for newtypes in {{{getInitialKind}}} or {{{kcTyClGroup}}} (or both) ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 21 Dec '15

21 Dec '15

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: => osa1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0