August 2016 - ghc-tickets

[GHC] #11126: Entered absent arg in a Repa program
by GHC 18 Jan '19

18 Jan '19

#11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- Consider the following program. {{{#!hs module Main where import Data.Array.Repa data Stuff = !(Array U DIM1 Double) `With` !Double deriving Show through :: Maybe Double -> Stuff -> Stuff m `through` (a `With` _) = let b = a +^ (negate `smap` sumS (extend (Z :. All :. (1 :: Int)) a)) c = maybe b (const (negate `smap` a)) m in computeUnboxedS c `With` sumAllS b main :: IO () main = print $ Just 1 `through` (fromListUnboxed (Z :. 1) [1] `With` 1) }}} It should produce the following result once run. {{{#!hs AUnboxed (Z :. 1) (fromList [-1.0]) `With` 0.0 }}} However, when built using `repa-3.4.0.1` and compiled with the options `-O3 -Wall -funfolding-keeness-factor1000 -funfolding-use-threshold1000`, it crashes as follows. {{{#!hs Main: Oops! Entered absent arg arr2 Array D DIM1 Double }}} Adding `-fno-strictness` to the compiler options or removing strictness annotations from the code makes the problem disappear, so this looks like a strictness analyzer problem. The libraries used were * `QuickCheck-2.8.1`, * `array-0.5.1.0`, * `base-4.8.1.0`, * `bytestring-0.10.6.0`, * `containers-0.5.6.2`, * `deepseq-1.4.1.1`, * `ghc-prim-0.4.0.0`, * `integer-gmp-1.0.0.0`, * `pretty-1.1.2.0`, * `primitive-0.6`, * `random-1.1`, * `repa-3.4.0.1`, * `template-haskell-2.10.0.0`, * `tf-random-0.5`, * `time-1.5.0.1`, * `transformers-0.4.2.0` and * `vector-0.10.12.3`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11126> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #10918: Float once-used let binding into a recursive function
by GHC 18 Jan '19

18 Jan '19

#10918: Float once-used let binding into a recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- Consider this code {{{#!hs let x = f x0 in let go 10 = x go i = go (i+1) in go (0::Int) }}} Currently, this is pretty much the core that comes out at the end. But what we want to see instead is {{{#!hs let go 10 = let x = f x 0 in x go i = go (i+1) in go (0::Int) }}} In general, we do not want to float a binding into a recursive function, because we would risk doing the allocation and/or evaluation of it multiple times. But in this case, we can see that it is going to be used at most once, so it is safe to do so. Even more: In the slightly less contrived examples that I was looking at, the call to `x` was happening in the a less likely code path, so this way we’d avoid doing the allocation in most cases, a clear win. It might be enough to simply make `CallArity` (or rather the cardinality analysis done by call arity) tell the rest of the compiler that it found that `x` is called at most once, and hopefully the simplifier knows what to make of that information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10918> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult
by GHC 17 Jan '19

17 Jan '19

#11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 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: -------------------------------------+------------------------------------- After a couple hours, 30-some browser tabs, and attempting to use ghc- simple to paper over some annoyances with GHC's API (dynFlags/session- stuff, particularly), I gave up. I then opened up haskell-src-exts and found the function I wanted in a minute or two. {{{#!hs import qualified Language.Haskell.Exts.Parser as P parsePls' :: String -> IO () parsePls' s = print $ P.parseExp s }}} This is where I got stuck: {{{ Prelude> parsePls "1 + 1" Too late for parseStaticFlags: call it before runGhc or runGhcT }}} This is the code I was working with before I gave up on GHC: {{{#!hs module ParsePls where import DynFlags import FastString import qualified GHC import qualified GhcMonad as GM import HsSyn import Lexer import Outputable import Parser import RdrName import SrcLoc import StaticFlags import StringBuffer import qualified Language.Haskell.GHC.Simple as S import qualified Language.Haskell.GHC.Simple.Types as ST import System.Environment main :: IO () main = do [expr] <- getArgs parsePls expr parsePls :: String -> IO () parsePls s = do initStaticOpts let sbuf = stringToStringBuffer s srcloc = mkRealSrcLoc (mkFastString s) 1 1 (dynflags, _) <- S.getDynFlagsForConfig ST.defaultConfig -- dynflags <- undefined -- GHC.getSessionDynFlags -- unP :: P a -> PState -> ParseResult a -- mkPState :: DynFlags -> StringBuffer -> RealSrcLoc -> PState -- parseExpression :: P (LHsExpr RdrName) -- type LHsExpr id = Located (HsExpr id) -- Defined in ‘HsExpr’ let parseResult = unP parseExpression (mkPState dynflags sbuf srcloc) case parseResult of POk _ (L _ mdl) -> print $ showPpr dynflags mdl PFailed ss _ -> do putStrLn "Error occurred!" print ss }}} Is there a reason it has to be this difficult? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11301> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci
by GHC 17 Jan '19

17 Jan '19

#11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 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: -------------------------------------+------------------------------------- The name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0). {{{ rwbarton@morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help Prelude> a <- return () Prelude> a <- return () <interactive>:2:1: warning: This binding for ‘a’ shadows the existing binding defined at <interactive>:1:1 Prelude> let b = return () Prelude> let b = return () <interactive>:4:5: warning: This binding for ‘b’ shadows the existing binding defined at <interactive>:3:5 Prelude> c = return () Prelude> c = return () Prelude> }}} I'm hoping this can be fixed for 8.0, since I would also very much like to turn on name shadowing warnings in ghci by default (in the interactive flags), to reduce confusion from examples like the below, which is now possible for the first time in 8.0: {{{ Prelude> fact 0 = 1 Prelude> fact n = n * fact (n-1) Prelude> fact 5 ^C^CInterrupted. Prelude> -- why did it run forever? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12091: 'Variable not in scope" when using GHCi with `-fobject-code`
by GHC 17 Jan '19

17 Jan '19

#12091: 'Variable not in scope" when using GHCi with `-fobject-code` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #7253 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since b98ff3ccb14e36145404f075349c8689762a2913 was landed (#7253), you don't need `let` to define stuff in GHCi: {{{ $ ghci Prelude> x = 3 Prelude> x 3 }}} But when using `-fobject-code`, this results in an error: {{{ $ ghci -fobject-code Prelude> x = 3 Prelude> x <interactive>:2:1: error: Variable not in scope: x }}} Very strange. CC @roshats, who implemented this feature, but the bug is probably in some part of the code he didn't touch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #12045: Visible kind application
by GHC 16 Jan '19

16 Jan '19

#12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple TypeApplications TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've wanted this for a while {{{ ghci> :kind (:~:) (:~:) :: k -> k -> Type }}} {{{ ghci> :kind (:~:) @(Type -> Type) (:~:) @(Type -> Type) :: (Type -> Type) -> (Type -> Type) -> Type ghci> :kind (:~:) @(Type -> Type) [] (:~:) @(Type -> Type) [] :: (Type -> Type) -> Type ghci> :kind (:~:) @(Type -> Type) [] Maybe (:~:) @(Type -> Type) [] Maybe :: Type }}} Working like {{{ ghci> type Same k (a::k) (b::k) = a :~: b ghci> :kind Same Same :: forall k -> k -> k -> * }}} {{{ ghci> :kind Same (Type -> Type) Same (Type -> Type) :: (Type -> Type) -> (Type -> Type) -> * ghci> :kind Same (Type -> Type) [] Same (Type -> Type) [] :: (Type -> Type) -> * ghci> :kind Same (Type -> Type) [] Maybe Same (Type -> Type) [] Maybe :: * }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading
by GHC 11 Jan '19

11 Jan '19

#10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ‘printf’ The type variable ‘t0’ is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ‘PrintfLib’ instance Printf [Char] -- Defined in ‘PrintfLib’ In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traveral order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10271> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12488: Explicit namespaces doesn't enforce namespaces
by GHC 11 Jan '19

11 Jan '19

#12488: Explicit namespaces doesn't enforce namespaces -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems to me that the type keyword should permanently enforce that a RdrName lives in a particular namespace. Currently it only acts as a syntactic marker so that type constructors which looks like variables can be included in export lists. The following example is accepted by GHC. As `A` is parsed as a type constructor but later put into the data constructor namespace. {{{#!hs {-# LANGUAGE ExplicitNamespaces #-} {-# LANGUAGE TypeFamilies #-} module M ( T (type A) ) where data T = A class Foo a where type A a foo :: a -> Int }}} The fix is to track uses of ExplicitNamespaces in the AST and then use this information in the renamer. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12488> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11610: Remove IEThingAll constructor from IE datatype
by GHC 11 Jan '19

11 Jan '19

#11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- It seems that now `IEThingWith` can include a wildcard that the `IEThingAll` constructor is a special case. I'm not sure how involved this would be but it seems worth doing. {{{ | IEThingAll (Located name) -- ^ Class/Type plus all methods/constructors -- -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnDotdot','ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation -- See Note [Located RdrNames] in HsExpr | IEThingWith (Located name) IEWildcard [Located name] [Located (FieldLbl name)] -- ^ Class/Type plus some methods/constructors -- and record fields; see Note [IEThingWith] -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11610> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic
by GHC 11 Jan '19

11 Jan '19

#10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Template | Version: 7.10.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+------------------------------------- When I say: {{{#!hs m :: a -> a m x = $$([||_||]) }}} I get: {{{ T10946.hs:47:13:ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): No skolem info: a_apJ[sk] }}} This happens both with GHC 7.10.1 and latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10946> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19