December 2015 - ghc-tickets

[GHC] #9176: GHC not generating dyn_hi files
by GHC 25 Dec '15

25 Dec '15

#9176: GHC not generating dyn_hi files ----------------------------------+---------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: dynamic | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------- In some situations, GHC terminates successfully and generates a `dyn_o` file, but no `dyn_hi` file. As a result, a package that contains a library seems to build successfully, but fails to install. I narrowed the problem down to the following test case. I compile it with `ghc --make -shared -dynamic-too Foo`. It seems to be Parsec-related, but I don't know how to trace it further. {{{ module Foo where import Text.ParserCombinators.Parsec }}} Parsec was installed with `cabal install --reinstall --user --enable- shared --disable-library-profiling parsec-3.1.5`. Some Parsec modules do not cause the missing `dyn_hi` file. For instance, all output files are created if Foo imports `Text.Parsec.Pos` instead of `Text.ParserCombinators.Parsec`. GHC was built from source, commit 9e10963e394680dbb1b964c66cb428a2aa03df09, compiled by GHC 7.6.3 with XCode 5.1.1 on OS X 10.9.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11258: Add Location to RdrName in FieldOcc
by GHC 25 Dec '15

25 Dec '15

#11258: Add Location to RdrName in FieldOcc -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11019 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Post #11019, there have been some new instances of RdrName that are not located, in particular {{{#!lhs data FieldOcc name = FieldOcc { rdrNameFieldOcc :: RdrName , selectorFieldOcc :: PostRn name name } data AmbiguousFieldOcc name = Unambiguous RdrName (PostRn name name) | Ambiguous RdrName (PostTc name name) deriving (Typeable) }}} Add locations to them -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11258> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11279: Parsing of complex QuasiQuote expression fails
by GHC 25 Dec '15

25 Dec '15

#11279: Parsing of complex QuasiQuote expression fails -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Parser) | 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 file {{{#!hs {-# LANGUAGE QuasiQuotes #-} testComplex = assertBool "" ([$istr| ok #{Foo 4 "Great!" : [Foo 3 "Scott!"]} then |] == ("\n" ++ " ok\n" ++ "[Foo 4 \"Great!\",Foo 3 \"Scott!\"]\n" ++ " then\n")) }}} parses (with renamer errors) under 7.10.3, but fails with {{{#!hs /home/alanz/tmp/Foo.hs:5:1: error: parse error (possibly incorrect indentation or mismatched brackets) }}} using current master (721d56d596848f9c772d08ef8693dff8ab9417b6) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11279> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11249: Type Synonyms cause Ambiguous Types
by GHC 25 Dec '15

25 Dec '15

#11249: Type Synonyms cause Ambiguous Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile: {{{ {-# LANGUAGE DataKinds, TypeOperators, TypeFamilies, KindSignatures, ConstraintKinds #-} import GHC.TypeLits type a / b = FDiv a b type a ** b = FMul a b type family FDiv a b where FDiv 11648 128 = 91 type family FMul a b where FMul 64 91 = 5824 type family FGCD a b where FGCD 128 448 = 64 FGCD 128 5824 = 64 type family FLCM a b where FLCM 128 5824 = 11648 data CT (m :: Nat) (m' :: Nat) type H0 = 128 type H1 = 448 type H0' = 11648 type H1' = 5824 main' = let x = undefined :: CT H0 H0' in foo x :: CT H1 H1' foo x = bug x type Ctx2 e r s e' r' = (e ~ FGCD r e', r' ~ FLCM r e', e ~ FGCD r s) bug :: (Ctx2 e r s e' r', e' ~ (e ** (FDiv r' r))) => CT r r' -> CT s s' bug = undefined }}} with the error {{{ Could not deduce ((~) Nat (FGCD r e'0) (FGCD r s)) ... The type variable ‘e'0’ is ambiguous When checking that ‘foo’ has the inferred type foo :: forall (r :: Nat) (s :: Nat) (s' :: Nat) (e' :: Nat). ((~) Nat (FGCD r s) (FGCD r e'), (~) Nat (FMul (FGCD r s) (FDiv (FLCM r e') r)) e') => CT r (FLCM r e') -> CT s s' Probable cause: the inferred type is ambiguous }}} However, if I change the definition of `bug` to: {{{ bug :: (Ctx2 e r s e' r', e' ~ (e ** (r' / r))) => CT r r' -> CT s s' bug = undefined }}} that is, I use the type synonym `/` for `FDiv`, then the code suddenly compiles. This seems like a different bug than #11248 because that ticket is about transitivity of constraint synonyms, while this example is broken simply by using a type synonym. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11286: ghc-pkg library
by GHC 25 Dec '15

25 Dec '15

#11286: ghc-pkg library -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | 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: -------------------------------------+------------------------------------- On Twitter, Anthony Cowley was wondering why there was no GHC API functions for taking Cabal InstalledPackageInfos and turning them into GHC InstalledPackageInfos. https://twitter.com/a_cowley/status/680158885953564672 No such interface exists: to keep GHC decoupled from Cabal, the GHC package representation is mediated solely by `ghc-pkg`, so the "correct" way to create a package config file, run `ghc-pkg` to load it into the GHC binary representation, and go from there. It seems like it would be convenient if `ghc-pkg` was libified, and so people who linked against GHC and Cabal could just directly do the conversion without going through `ghc-pkg`. It's unclear what the right interface is; ghc-pkg does a number of sanity checks and it's unclear if those should be libified too. Any such library also must be uploaded to Hackage, because if you want to link against a newer version of Cabal you have to rebuild the ghc-pkg library against the newest version of Cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot
by GHC 24 Dec '15

24 Dec '15

#9760: ghc -c 7.8 drops last char of file name if -osuf contains a dot -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Build System | Version: 7.8.3 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: -------------------------------------+------------------------------------- I discovered that if I compile with `ghc -c -osuf .something Myfile.hs` where `Myfile.hs` contains TH and thus has to dynamically link in, say, `Other.hs`, I get the error that {{{ Myfile.hs:1:1: cannot find normal object file 'Othe.dyn_o` while linking an interpreted expression }}} So `Other` was wrongly made into `Othe`, dropping the last character. If I don't pass `-osuf .something`, or have it not have a dot, everything's fine. The trouble is that `-osuf .something` worked fine in GHC <= 7.6. So I believe this is a regression, or at least a very bad error message. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9760> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5296: Add explicit type applications
by GHC 24 Dec '15

24 Dec '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/Vta{1,2} typecheck/should_fail/VtaFail * status: new => closed * resolution: => fixed Comment: All set now. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 24 Dec '15

24 Dec '15

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg <eir@…>): In [changeset:"2db18b8135335da2da9918b722699df684097be9/ghc" 2db18b81/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2db18b8135335da2da9918b722699df684097be9" Visible type application This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5554: Strange interaction between "-osuf", profiling and TemplateHaskell
by GHC 24 Dec '15

24 Dec '15

#5554: Strange interaction between "-osuf", profiling and TemplateHaskell -------------------------------------+--------------------------------- Reporter: iustin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Template Haskell | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"48db13d279d592ed3044cbaf3513854bcb0d3dce/ghc" 48db13d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48db13d279d592ed3044cbaf3513854bcb0d3dce" Don't drop last char of file if -osuf contains dot Given: * `file = "foo.a.b"` * `osuf = ".a.b"` -- Note the initial dot. * `new_osuf = "c"` Before (bad, the last character of the filename is dropped): `dropTail (length osuf + 1) file <.> new_osuf == "fo.c"` After (good): `stripExtension osuf file <.> new_osuf` == "foo.c" This regression was introduced in commit c489af73 (#5554). That commit fixed a similar but different bug, and care has been taken to not reintroduce it (using the the newly introduced `System.Filepath.stripExtension`). Given: * `file = "foo.a.b"` * `osuf = "a.b"` * `new_osuf = "c"` Before c489af73 (bad, the full suffix should get replaced): `replaceExtension file new_osuf == "foo.a.c"` After c489af73 (good): `dropTail (length osuf + 1) file <.> new_osuf == "foo.c"` After this commit (still good): `stripExtension osuf file <.> new_osuf == "foo.c"` Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D1692 GHC Trac Issues: #9760 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5554#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9975: RecordWildCards and PatternSynonyms cause impossible bug
by GHC 24 Dec '15

24 Dec '15

#9975: RecordWildCards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X RecordWildCards PatternSynonyms | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using RecordWildCards with PatternSynonyms, I have found a way to cause this bug: $ /usr/local/bin/ghc-7.10.0.20141222 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): find_tycon Test [Test defined at test.hs:6:9, Test parent:Test defined at test.hs:4:13] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here is the full code that causes it: {{{#!hs {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE PatternSynonyms #-} data Test = Test { x :: Int } pattern Test wat = Test { x = wat } }}} If you remove RecordWildCards, the bug does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8