May 2015 - ghc-tickets

[GHC] #10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master
by GHC 11 May '15

11 May '15

#10395: ghc-7.10 branch : Please cherry-pick 1a4374c1e2 from master -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ commit 1a4374c1e246d81a5c1d00a720919804093a8241 Author: Erik de Castro Lopo <erikd(a)mega-nerd.com> Date: Mon May 4 23:39:31 2015 +0000 arm: Force non-executable stack (part 2) This was supposed to be part of commit 63a10bbc42 but I pushed from the wrong machine. This fixes cross compiling to arm. }}} Commit `63a10bbc42` has already been cherry-picked to this branch. Without this, cross compiling to arm is broken. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10395> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[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

[GHC] #10268: ApiAnnotations : quoted type variables missing leading quote
by GHC 11 May '15

11 May '15

#10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- 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 `HsOpTy` can be constructed for a promoted type operator, in which case it has the following form {{{ | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } }}} The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via the API Annotations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10268> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10299: Inconsistent parsing of lifted list constructor
by GHC 11 May '15

11 May '15

#10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | -------------------------------------+------------------------------------- The notes for `HsType` explain that `'[]` should parse as a `HsExplicitListTy` but it currently parses as a `HsTyVar`. I think this shift-reduce conflict might be to blame? {{{#!hs state 432 contains 1 shift/reduce conflicts. atype -> SIMPLEQUOTE '[' . comma_types0 ']' (rule 318) sysdcon -> '[' . ']' (rule 613) Conflict: ']' (empty comma_types0 reudes) TODO: Why? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10299> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5