August 2016 - ghc-tickets

[GHC] #10267: Add support for typed holes in Template Haskell
by GHC 02 Apr '18

02 Apr '18

#10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I want to be able to work with typed holes using Template Haskell. These are currently rejected: {{{#!hs [d| i :: a -> a i x = _ |] }}} {{{ Expression form not (yet) handled by Template Haskell _ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10267> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10822: GHC inconsistently handles \\?\ for long paths on Windows
by GHC 31 Mar '18

31 Mar '18

#10822: GHC inconsistently handles \\?\ for long paths on Windows -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- To demonstrate what I mean first: {{{ >ghc-pkg init \\?\c:\Users\michael\Desktop\some-pkg-db >dir \\?\c:\Users\Michael\Desktop\some-pkg-db Volume in drive \\?\c: is Windows8_OS Volume Serial Number is CEF7-874D Directory of \\?\c:\Users\Michael\Desktop\some-pkg-db 09/01/2015 09:38 AM <DIR> . 09/01/2015 09:38 AM <DIR> .. 09/01/2015 09:38 AM 40 package.cache 1 File(s) 40 bytes 2 Dir(s) 5,907,509,248 bytes free >ghc -package-db \\?\c:\Users\Michael\Desktop\some-pkg-db ghc: can't find a package database at \\?\c:\Users\Michael\Desktop\some- pkg-db }}} The problem: on Windows by default, paths are limited to 260 characters, which can become a real problem in practice when dealing with the standard library path hierarchy the Cabal library uses and any package with a decent name length. This was a real problem in practice, see: https://github.com/haskell/cabal/issues/2502 Windows has a workaround for this: you can prefix an absolute path with \\?\, see: https://msdn.microsoft.com/en- us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath It would be very useful if such paths worked with GHC, but currently they do not. I don't yet know how deep the problem is. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12442: Pure unifier usually doesn't need to unify kinds
by GHC 30 Mar '18

30 Mar '18

#12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | 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 pure unifier (in `types/Unify.hs`) is used to match up instances with actual types. Since GHC 8, it matches up the kinds with the types in a separate pass. But this is often wasteful, and sometimes downright wrong. It's wasteful because most invocations of the unifier on a list of types pass in well-kinded arguments to some type constructor. Because the kinds of type constructors are closed, if we process the list left-to-right, we will always unify the kinds of later arguments before we get to them. So we shouldn't take another pass on the kinds. It's wrong because it's conceivable for the kind to include a type family application, and using a type family application as a template in the pure unifier is very silly, indeed. I cam across this while trying to translate Idris's algebraic effects library to Haskell. My reduced test case is attached. Patch on the way. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #12176: Failure of bidirectional type inference at the kind level
by GHC 30 Mar '18

30 Mar '18

#12176: Failure of bidirectional type inference at the kind level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm feeling particularly sadistic towards GHC at the moment, and so I fed it this: {{{ import Data.Kind data Proxy :: forall k. k -> Type where MkProxy :: forall k (a :: k). Proxy a data X where MkX :: forall (k :: Type) (a :: k). Proxy a -> X type Expr = (MkX :: forall (a :: Bool). Proxy a -> X) type family Foo (x :: forall (a :: k). Proxy a -> X) where Foo (MkX :: forall (a :: k). Proxy a -> X) = (MkProxy :: Proxy k) }}} Incredibly, GHC accepts it! And it even means what I wish it to, with GHCi telling me the following (with `-fprint-explicit-kinds`): {{{ λ> :i Foo type family Foo k (x :: forall (a :: k). Proxy k a -> X) :: Proxy * k where [k] Foo k ('MkX k) = 'MkProxy * k }}} That is, I wished to extract the kind parameter to `MkK`, matching against a partially-applied `MkX`, and GHC understood that intention. However, sadly, writing `Foo Expr` produces {{{ • Expected kind ‘forall (a :: k0). Proxy k0 a -> X’, but ‘Expr a0’ has kind ‘Proxy Bool a0 -> X’ • In the first argument of ‘Foo’, namely ‘Expr’ In the type ‘Foo Expr’ In the type family declaration for ‘XXX’ }}} For some reason, `Expr` is getting instantiated when it shouldn't be. Perhaps there's a simpler test case demonstrating the bug, but I feel so gleeful that this chicanery is accepted at all that I wanted to post. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9406: unexpected failure for T7837(profasm)
by GHC 29 Mar '18

29 Mar '18

#9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: T7837 | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: T7837 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This may be a test suite configuration error as the normal case works. When run with an llvm-perf build of the HEAD, I get: {{{ =====> T7837(normal) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7837.hs -O -ddump-rule-firings >T7837.comp.stderr 2>&1 =====> T7837(profasm) 1395 of 4068 [0, 0, 0] cd ./indexed-types/should_compile && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7837.hs -O -prof -static -auto-all -O -ddump-rule- firings >T7837.comp.stderr 2>&1 Actual stderr output differs from expected: --- ./indexed-types/should_compile/T7837.stderr 2014-08-03 11:36:53.000000000 +0100 +++ ./indexed-types/should_compile/T7837.comp.stderr 2014-08-04 23:16:34.000000000 +0100 @@ -1,3 +1,4 @@ Rule fired: Class op abs Rule fired: Class op signum Rule fired: normalize/Double +Rule fired: Class op / *** unexpected failure for T7837(profasm) Unexpected results from: TEST="T7837" OVERALL SUMMARY for test run started at Mon Aug 4 23:16:32 2014 BST 0:00:02 spent to go through 4068 total tests, which gave rise to 19536 test cases, of which 19534 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures Unexpected failures: indexed-types/should_compile T7837 [stderr mismatch] (profasm) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9406> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10536: Clear up how to turn off dynamic linking in build.mk
by GHC 26 Mar '18

26 Mar '18

#10536: Clear up how to turn off dynamic linking in build.mk -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/ghc-devs/2014-December/007725.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11188: Confusing "parse error in pattern" for missing indentation.
by GHC 25 Mar '18

25 Mar '18

#11188: Confusing "parse error in pattern" for missing indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following problem exists at least in ghc 7.4.2 through 7.10.1: {{{#!hs main = do putStrLn "Hello, lots of crap" $ do a <- return 3 -- The following line is mis-indented, the error is incomprehensible c <- do return 5 }}} Error: {{{ <file>:2:3: Parse error in pattern: putStrLn Possibly caused by a missing 'do'? }}} The hint about "missing do" exists from ghc 7.8, but is wrong in this case. Problematic about this bug is that the wrong indentation can be arbitrary many lines from where ghc reports the (totally incomprehensible) error. My original problem is to find the syntax error here: {{{#!hs -- | Type check a function clause. checkClause :: Type -> A.SpineClause -> TCM Clause checkClause t c(a)(A.Clause (A.SpineLHS i x aps withPats) rhs0 wh) = do unless (null withPats) $ do typeError $ UnexpectedWithPatterns withPats traceCall (CheckClause t c) $ do aps <- expandPatternSynonyms aps checkLeftHandSide (CheckPatternShadowing c) (Just x) aps t $ \ (LHSResult delta ps trhs perm) -> do -- Note that we might now be in irrelevant context, -- in case checkLeftHandSide walked over an irrelevant projection pattern. -- As we will be type-checking the @rhs@ in @delta@, but the final -- body should have bindings in the order of the pattern variables, -- we need to apply the permutation to the checked rhs @v@. let mkBody v = foldr (\ x t -> Bind $ Abs x t) b xs where b = Body $ applySubst (renamingR perm) v xs = [ stringToArgName $ "h" ++ show n | n <- [0..permRange perm - 1] ] -- introduce trailing implicits for checking the where decls TelV htel t0 <- telViewUpTo' (-1) (not . visible) $ unArg trhs (body, with) <- do let n = size htel addCtxTel htel $ checkWhere (size delta + n) wh $ -- for the body, we remove the implicits again escapeContext n $ handleRHS aps (unArgs trhs) rhs0 escapeContext (size delta) $ checkWithFunction with reportSDoc "tc.lhs.top" 10 $ escapeContext (size delta) $ vcat [ text "Clause before translation:" , nest 2 $ vcat [ text "delta =" <+> prettyTCM delta , text "perm =" <+> text (show perm) , text "ps =" <+> text (show ps) , text "body =" <+> text (show body) , text "body =" <+> prettyTCM body ] ] return $ Clause { clauseRange = getRange i , clauseTel = killRange delta , clausePerm = perm , namedClausePats = ps , clauseBody = body , clauseType = Just trhs } }}} {{{ src/full/Agda/TypeChecking/Rules/Def.hs:328:5: Parse error in pattern: checkLeftHandSide Possibly caused by a missing 'do'? }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11188> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11472: Remove CallStack CPP guards in GHC 8.2
by GHC 19 Mar '18

19 Mar '18

#11472: Remove CallStack CPP guards in GHC 8.2 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 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: -------------------------------------+------------------------------------- GHC 7.10.1 didn't support `CallStack`, while its successors did. Yet in post-8.0 `master` (which needs to be buildable with the 7.10 series, including 7.10.1) references to CallStack have begun to sneak in to GHC. The first instance of this was 9d33adb6f352ad4e488067a8756928b3778920e0 but there will likely be more. I've fixed in this instance in Phab:D1812 by adding `#if` guards. These should be removed in GHC 8.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12517: Simplify runghc command line options
by GHC 19 Mar '18

19 Mar '18

#12517: Simplify runghc command line options -------------------------------------+------------------------------------- Reporter: harendra | Owner: harendra Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 8.0.1 Keywords: runghc | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there are three ways runghc can pass options to GHC: 1. unrecognized options are automatically passed to GHC 2. options after a `--` are passed to GHC 3. `--ghc-args=<arg>` passes arg to GHC The command line is difficult to comprehend and non-intuitive with all these different ways to pass options to GHC. Other than having multiple ways to do the same thing there are other problems too. For example: 1. The meaning of `--` is overloaded, the usual meaning is that everything after it is non option or opaque args. This is difficult to explain and creates confusion. 2. To pass a filename starting with a dash we need something like `runghc -- -- -prog.hs`. Which is not a usual use case but it needs to be explained in the manual anyway. 3. It first appears that options after `--` will be passed to GHC including those not starting with a `-` but that is not the case. For args not starting with a `-` we need to use `--ghc-arg=` so there is not much use of the `--` anyway other than increased confusion. I propose to do away with all other mechanisms other than the explicit `--ghc-arg=<arg>` method. This will make the documentation and understanding of the command straightforward and intuitive. Though the change will not be backward compatible. If backward compatibility is really needed we will have to use deprecation warnings for the unsupported methods and remove them from the official documentation and wait for some time before we actually remove them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #12498: Support unconventionally named import libraries
by GHC 19 Mar '18

19 Mar '18

#12498: Support unconventionally named import libraries -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11072 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use. Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc. This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. This should add more compatibility with packages on hackage. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9