July 2018 - ghc-tickets

[GHC] #14995: QuantifiedConstraints: Incorrect pretty printing
by GHC 02 Jul '18

02 Jul '18

#14995: QuantifiedConstraints: Incorrect pretty printing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code from [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/jfp-outsidein.pdf OutsideIn(X)] compiles {{{#!hs {-# Language FlexibleInstances, MultiParamTypeClasses, GADTs, QuantifiedConstraints #-} class C a class B a b where op :: a -> b instance C a => B a [a] where op = undefined data R a where MkR :: C a => a -> R a k :: (C a => B a b) => R a -> b k (MkR x) = op x }}} but pretty-printing `k` prints `B a b => ..` instead of `(C a => B a b) => ..` {{{ $ ghci -ignore-dot-ghci Test.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/228-bug.hs, interpreted ) Ok, one module loaded. *Main> :t k k :: B a b => R a -> b *Main> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8489: clean up dependency and usages handling in interface files
by GHC 01 Jul '18

01 Jul '18

#8489: clean up dependency and usages handling in interface files ----------------------------------------------+---------------------------- Reporter: errge | Owner: errge Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: 1480 | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- While reviewing #1480, it was found that there are corner cases that are not easy to handle. This task is about fixing TH module reification to reify direct import list, not usages. For this we may need to extend the current `ModIface`. This task also includes cleaning up the comments and code in related areas, to quote simonpj: "we need more precise commentary on the fields of `HscTypes.Dependencies`, `TcRnTypes.ImportAvails`, and `mi_usages` of `ModIface`. For example, I wonder whether the `mi_usages` field could be part of the `Dependencies`". -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8489> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

Re: [GHC] #4222: Template Haskell lets you reify supposedly-abstract data types
by GHC 01 Jul '18

01 Jul '18

#4222: Template Haskell lets you reify supposedly-abstract data types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 6.12.3 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 mgsloan): IMHO being able to reify stuff like this is a feature not a bug. See, for example, the http://hackage.haskell.org/package/true-name package. One thing that comes to mind here is just making it a special variety of warning when TH references things that are not imported. This way things like the "true-name" package will still be possible, but will cause warnings that can be ignored if the user chooses to. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4222#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11812: Template Haskell can induce non-unique Uniques
by GHC 01 Jul '18

01 Jul '18

#11812: Template Haskell can induce non-unique Uniques -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- When quoting a Template Haskell expression (or type), you can get your hands on renamed variables. These variables have assigned Uniques. If you then use the same variable locally in ''different'' top-level expressions, chaos can ensue. It's certainly expected that something bizarre would happen if you used the same Unique twice within the same scope, but it surprised me that using the same Unique twice in different scopes would cause a problem. Below is the rather hard-won reduced test case: {{{ {-# LANGUAGE TemplateHaskell, PolyKinds, RankNTypes, TypeFamilies #-} module Bug where import Language.Haskell.TH import Data.Type.Equality type Const a b = a $( do ForallT [PlainTV n] _ _ <- [t| forall n. n |] let noBang = Bang NoSourceUnpackedness NoSourceStrictness return [ClosedTypeFamilyD (TypeFamilyHead (mkName "F1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") ] (KindSig (VarT n)) Nothing) [TySynEqn [VarT (mkName "a"), VarT (mkName "b")] (ConT ''Const `AppT` VarT (mkName "a") `AppT` (ConT (mkName "T1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))] ,DataD [] (mkName "T1") [ KindedTV (mkName "a") (VarT n) , PlainTV (mkName "b") , PlainTV (mkName "c")] Nothing [NormalC (mkName "K1") [(noBang, ConT ''(:~:) `AppT` VarT (mkName "c") `AppT` (ConT (mkName "F1") `AppT` VarT (mkName "a") `AppT` VarT (mkName "b")))]] []]) }}} This blob produces {{{ type family F1 (a :: n_auRf) b :: n_auRf where F1 a b = Const a (T1 a b) data T1 (a :: n_auRf) b c = K1 ((:~:) c (F1 a b)) }}} which compiles fine when typed in directly. Note that this hinges on the `SigTv` behavior of kind variables in non-CUSK declarations, but I don't think that's the nub of the problem. What happens is this: during renaming, the `n`s are renamed to have the same `Unique`, because `n` is `Exact`. Type-checking invents `SigTv`s for each `n`. Naturally, both `n`s have ''different'' `IORef`s stored in their `TcTyVarDetails`. When the two `n`s are compared during checking, though, their `Unique`s are the same, and so nothing happens -- even though they should be unified. The upshot is that we get one logical variable `n` with different `IORef`s in different occurrences, causing chaos. It might be reasonable to punt on this, but we should document in the manual what the problem is. It puzzled me for quite a while when the problem came up in real code! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11812> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14318: TH shadowing bind statement triggers -Wunused-matches
by GHC 01 Jul '18

01 Jul '18

#14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $(newName "x" >>= \x -> newName "f" >>= \f -> lamE [varP f, varP x] (doE [ bindS (varP x) (listE [varE f `appE` varE x]) , noBindS (varE x)]) ) }}} generates the following expression: {{{ \f x -> do x <- f x x }}} and `-Wunused-matches` complains that `x` is not used, while both bound occurrences are in fact used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14318> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14994: ghc api: `load LoadAllTargets` is not idempotent
by GHC 01 Jul '18

01 Jul '18

#14994: ghc api: `load LoadAllTargets` is not idempotent -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.4.1 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: -------------------------------------+------------------------------------- While trying to adapt `hint` for ghc 8.4.1, I've encountered the following phenomenon where an extra `load LoadAllTargets` line causes errors. {{{#!hs -- warning: the code below creates files A.hs and B.hs in the current working directory import System.Directory import Control.Monad.IO.Class import GHCi.RemoteTypes import GHC.Paths -- cf. the ghc-paths package import Unsafe.Coerce main = do writeFile "A.hs" "module Ahidden(a) where { a :: Int; a = 42 }" let mod_nameA = mkModuleName "Ahidden" mod_targetA = Target (TargetFile "A.hs" Nothing) False Nothing runGhc (Just libdir) $ do -- setup df0 <- getSessionDynFlags (df1, _, _) <- parseDynamicFlags df0 [] setSessionDynFlags df1{ ghcMode = CompManager, hscTarget = HscInterpreted, ghcLink = LinkInMemory, verbosity = 0 } -- context : *X setTargets [mod_targetA] load LoadAllTargets load LoadAllTargets -- this line causes the next line to fail setContext [IIModule mod_nameA] -- error: -- ...: Could not find module ‘Ahidden’ -- Use -v to see a list of the files searched for. runIOExpr "print a :: IO ()" runIOExpr e = do HValue h <- compileExpr e liftIO (unsafeCoerce h :: IO ()) }}} This code works with ghc 8.2. The new behavior probably originates in 1893ba12fe1fa2ade35a62c336594afcd569736e, which adds flushing of the finder cache (main/Finder.hs) for every dependency analysis; my guess is that this is where the connection between the module name `Ahidden` and the file `A.hs` used be tracked. http://lpaste.net/364298 is a less artificial example of the same behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15058: scc001 unexpected passes in prof way on CircleCI
by GHC 01 Jul '18

01 Jul '18

#15058: scc001 unexpected passes in prof way on CircleCI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10037 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This should supposedly fail due to #10037. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15306: First attempt at starting GHCI failed
by GHC 01 Jul '18

01 Jul '18

#15306: First attempt at starting GHCI failed -------------------------------------+------------------------------------- Reporter: DaleB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- PS C:\WINDOWS\system32> ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help ghc.exe: C:\F\G77\lib\libmingw32.a: Not a x86_64 PE+ file. ghc.exe: getNumberOfSymbols: error whilst reading `CRTglob.o' header in `C:\F\G77\lib\libmingw32.a': Unknown COFF_OBJ_TYPE. ghc.exe: loadArchive: error whilst reading `C:\F\G77\lib\libmingw32.a' ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): loadArchive "C:\\F\\G77\\lib\\libmingw32.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15306> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14858: Typed hole subtitution search fails in the REPL
by GHC 01 Jul '18

01 Jul '18

#14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: typed holes | Operating System: Unknown/Multiple substitutions | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems as though type class defaulting might be happening before the search. This finds only undefined: {{{#!text > _traverse print "abc" <interactive>:20:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at <interactive>:20:1-21 Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" In an equation for ‘it’: it = _traverse print "abc" • Relevant bindings include it :: t (bound at <interactive>:20:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} Annotating the return type helps, but we still don't find traverse_: {{{#!text > _traverse print "abc" :: IO () <interactive>:22:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" :: IO () In an equation for ‘it’: it = _traverse print "abc" :: IO () • Relevant bindings include it :: IO () (bound at <interactive>:22:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} (note how print seems to have been defaulted to ()) Annotating the type of print helps: {{{#!text > _traverse (print :: Char -> IO ()) "abc" :: IO () <interactive>:23:1: error: • Found hole: _traverse :: (Char -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse (print :: Char -> IO ()) "abc" :: IO () In an equation for ‘it’: it = _traverse (print :: Char -> IO ()) "abc" :: IO () • Relevant bindings include it :: IO () (bound at <interactive>:23:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) foldMap :: forall (t :: * -> *). Foldable t => forall m a. Monoid m => (a -> m) -> t a -> m (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) mapM_ :: forall (t :: * -> *) (m :: * -> *) a b. (Foldable t, Monad m) => (a -> m b) -> t a -> m () (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) traverse_ :: forall (t :: * -> *) (f :: * -> *) a b. (Foldable t, Applicative f) => (a -> f b) -> t a -> f () (imported from ‘Data.Foldable’) }}} This was found with 8.4.1-rc.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15329: Cannot parse `type (*)` in fixity declaration
by GHC 30 Jun '18

30 Jun '18

#15329: Cannot parse `type (*)` in fixity declaration -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Vanessa McHale posts: The parser seems to be broken. Attempting to build [http://hackage.haskell.org/package/basement basement] yields: {{{ Basement/Nat.hs:15:46: error: parse error on input ‘*’ | 15 | , type (<=), type (<=?), type (+), type (*), type (^), type (-) | ^ }}} This is actually in 8.6.0, but there is no version option for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15329> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2