April 2015 - ghc-tickets

[GHC] #10302: 7.10.1 documenation is incorrect wrt llvm
by GHC 11 May '15

11 May '15

#10302: 7.10.1 documenation is incorrect wrt llvm -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As documented in [#9929] ghc 7.10.1 only supports llvm 3.5. This should be documented in the release notes section of the GHC Users's Guide, Version 7.10.1. In addition, the following in the Known bugs section needs to be changed to mention this also: GHC’s LLVM backend is currently incompatible with LLVM 3.4 (issue #9929). The following in section 4.11.2 should also be changed from: Currently LLVM 2.8 and later are supported. to Only LLVM 3.5 is supported. from Secondly, if you are running Mac OS X with LLVM 3.0 or greater to Secondly, if you are running Mac OS X with LLVM 3.5 from In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X. to In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X and then install LLVM 3.5 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10302> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10210: Documentation link to 7.10.1 migration guide broken
by GHC 11 May '15

11 May '15

#10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When publishing the users guide to https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1…, several users reported the 'Migration Guide' hyperlinks were broken. Turns out they were; the HTML looked something like this: {{{ </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> GHC has implemented "The Applicative Monad Proposal", meaning the <code class="literal">Applicative</code> typeclass is now a superclass of <code class="literal">Monad</code>. This is a breaking change and your programs will need to be updated. Please see the <a class="ulink" href="" target="_top">GHC 7.10 Migration Guide</a> on the GHC wiki. }}} with an empty `href`. This ticket is so we don't lose track of this bug for 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10263: Role annotation should never be ambiguous
by GHC 11 May '15

11 May '15

#10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ [ezyang@hs01 ghc-backpack]$ cat A.hs {-# LANGUAGE RoleAnnotations #-} module A where data Maybe a = AF type role Maybe representational [ezyang@hs01 ghc-backpack]$ ghc -c A.hs A.hs:4:11: Ambiguous occurrence ‘Maybe’ It could refer to either ‘A.Maybe’, defined at A.hs:3:1 or ‘Prelude.Maybe’, imported from ‘Prelude’ at A.hs:2:8 (and originally defined in ‘GHC.Base’) }}} This is silly because roles can only ever be defined with the declaration, so only one reference makes sense. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10263> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9895: No -mtriple param being passed to opt/llc when cross compiling
by GHC 11 May '15

11 May '15

#9895: No -mtriple param being passed to opt/llc when cross compiling -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: than a day) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently trying to build an x86_64-linu to arm64-linux cross-compiler. After fixing some code in `rts/StgCRun.c` i ran into an issue where ghc was calling `llc` and generating `x86_64` assembly instead of `aarch64` assembly. For now, I've hacked `compiler/main/SysTools.hs` to add `-mtriple=aarch64 -linux-gnu` to the `opt` and `llc` command lines and that allows me to get a bit further in the compile process. For cross-compiling, passing something like this `-mtriple=...` is pretty much mandatory. I suggest adding it by doing the following: * Add a `crossCompiling :: Bool` field to `DynFlags`. * Add the `-mtriple=...` string to the `sOpt_lo` and `sOpt_lc` fields of `Settings` when we are cross-compiling. * Possibly also store the triple string in the `Platform` struct. Comments? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9895> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10285: Bug in Coerciible
by GHC 11 May '15

11 May '15

#10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Richard and I uncovered this {{{ {-# LANGUAGE RoleAnnotations #-} module Bar( N ) where -- Data constructor not exported type role N representational newtype N a = MkN Int }}} and {{{ {-# LANGUAGE FlexibleContexts #-} module Foo where import Data.Coerce import Data.Type.Coercion import Bar f :: Coercible (N a) (N b) => Coercion a b f = Coercion }}} This compiles but it should not! It wrongly compiles by using `nth (N a ~R N b)`; but (as Fig 4 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ the Corcible paper] says), we can't decompose a newtype at representational role. Easy to fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified.
by GHC 11 May '15

11 May '15

#10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: TypeLits | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits data Vec :: Nat -> * -> * where Nil :: Vec 0 a (:>) :: a -> Vec n a -> Vec (n + 1) a infixr 5 :> }}} when loaded in GHCi 7.8.3, and asking for the type of `(1 :> 2 :> 3 :> Nil)`, gives: {{{ $ ghci example/vec.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec 3 a }}} while in GHCi 7.10.1 it gives: {{{ $ ghci example/vec.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec (2 + 1) a }}} That is, the type-level computation, `((0 + 1) + 1) + 1` is only simplified to `2 + 1` in GHC 7.10.1, whereas in 7.8.3 `2+1` was further simplified to `3`. The same still happens in HEAD (20150417) {{{ $ ghci example/vec.hs GHCi, version 7.11.20150417: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec (2 + 1) a }}} I strongly feel that the behaviour in ghc 7.8.3 is the desired behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10321> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan
by GHC 11 May '15

11 May '15

#10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for opt_kind_sig is {{{#!hs opt_kind_sig :: { Located (Maybe (LHsKind RdrName)) } : { noLoc Nothing } | '::' kind {% ajl (sLL $1 $> (Just $2)) AnnDcolon (gl $1) } }}} The outer Location is used only to get the full span for the enclosing declration, and is then stripped. The inner LHsKind then has a SrcSpan that does not include the '::' Extend the SrcSpan on $2 to include $1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production
by GHC 11 May '15

11 May '15

#10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The parser production for `squals` has {{{ : squals ',' transformqual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> ams (sLL $1 $> ()) (fst $ unLoc $3) >> return (sLL $1 $> [sLL $1 $> ((snd $ unLoc $3) (reverse (unLoc $1)))]) } }}} This attaches the comma to the wrong part of the `squals`, as it is generated in reverse order. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10312> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection
by GHC 11 May '15

11 May '15

#10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For the following code {{{#!hs {-# LANGUAGE TupleSections #-} foo = do liftIO $ atomicModifyIORef ciTokens ((,()) . f) }}} the annotation is missing for the comma. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10280> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses
by GHC 11 May '15

11 May '15

#10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The RdrHsSyn.isFunLhs function has the following {{{#!hs isFunLhs e = go e [] where go (L loc (HsVar f)) es | not (isRdrDataCon f) = return (Just (L loc f, False, es)) go (L _ (HsApp f e)) es = go f (e:es) go (L _ (HsPar e)) es@(_:_) = go e es }}} The treatment of `HsPar` means that any parentheses around an infix function will be discarded. e.g. {{{#!hs (f =*= g) sa i = f (toF sa i) =^= g (toG sa i) }}} will lose the `(` before `f` and the closing one after `g` -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10269> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5