October 2015 - ghc-tickets

[GHC] #10016: UNPACK support for existentials
by GHC 03 Apr '18

03 Apr '18

#10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ data Foo = forall a. Show a => Foo !a !a data Bar = Bar {-# UNPACK #-} !Foo }}} The UNPACK pragma should really be able to unpack the `Foo` field, so that (implementation-wise) it would be as if you'd declared `Bar` thus: {{{ data Bar = forall a. Show a => Bar !a !a }}} But currently we get {{{ Ignoring unusable UNPACK pragma on the first argument of ‘Bar’ }}} Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- haskell-users/2015-January/025590.html here]. Vaguely related tickets: #7647, #9214. But unlike those ones, this one looks quite feasible to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10954: Add class/context information to typed hole relevant bindings
by GHC 02 Apr '18

02 Apr '18

#10954: Add class/context information to typed hole relevant bindings -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9479 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC's typed hole messages don't currently include any known context information for relevant bindings. For example: {{{#!hs bar :: a ~ b => a -> b -> Int bar x y = _ }}} gets me {{{ Found hole ‘_’ with type: Int Relevant bindings include y :: b (bound at <interactive>:8:42) x :: a (bound at <interactive>:8:40) bar :: a -> b -> Int (bound at <interactive>:8:36) In the expression: _ In an equation for ‘bar’: bar x y = _ }}} The types `a` and `b` are not unified, and the `a ~ b` constraint is not shown. {{{#!hs foo :: Show a => a -> Int foo x = _ }}} gets me {{{ Found hole ‘_’ with type: Int Relevant bindings include x :: a (bound at <interactive>:4:36) foo :: a -> Int (bound at <interactive>:4:32) In the expression: _ In an equation for ‘foo’: foo x = _ }}} The `Show` constraint is lost. === What I want === I'd like context information for all type variables in known bindings, so I can see all the pieces available to help me fill in the hole. === Related ticket === In #9479, Dominique Devriese wants to see any constraints ''on'' an ambiguously-typed hole. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10954> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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] #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] #10933: REMOVED pragma
by GHC 19 Mar '18

19 Mar '18

#10933: REMOVED pragma -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | 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): | -------------------------------------+------------------------------------- Say I have a function that's been deprecated for some time. Then I remove it. Some clients will still use the now-missing function. It would be nice to give a helpful error message, instead of a "symbol not found" error. I thus propose a `REMOVED` pragma. The syntax is identical to `DEPRECATED`, except for the name of the pragma. Whenever a `REMOVED` function is mentioned, the error message includes the string from the pragma. (This includes trying to define a `REMOVED` class method in an instance.) See Design/DeprecationMechanisms for more info and related efforts. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10640: Document prim-ops
by GHC 19 Mar '18

19 Mar '18

#10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: | -------------------------------------+------------------------------------- Currently documentation is quite scarce for many primops (particularly the BCO operations). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally
by GHC 19 Mar '18

19 Mar '18

#10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) <interactive>:1:3: parse error on input ‘:*’ }}} (By the way I assume that Template Haskell quotes (`'function` and `''Type`) are parsed by the same mechanism as the one for the explicit promotion syntax. I hope both styles of quotes for prefix operators will be admitted because currently only the `'(` `''(` style is admitted.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #10506: SourceNotes are not applied to all identifiers
by GHC 19 Mar '18

19 Mar '18

#10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | 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: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling {{{ module Foo where foo x = x + 1 bar y = foo y }}} with `-g` produces {{{ $ ghc -g -ddump-ticked test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) AbsBinds [a_avC] [$dNum_avD] {Exports: [foo <= foo_amB <>] Exported types: foo :: forall a_avC. Num a_avC => a_avC -> a_avC [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:3:1-13>] foo_amB x_alA = src<test.hs:3:9-13> (+) src<test.hs:3:9> x_alA src<test.hs:3:13> 1} AbsBinds [a_avV] [$dNum_avW] {Exports: [bar <= bar_avN <>] Exported types: bar :: forall a_avV. Num a_avV => a_avV -> a_avV [LclId, Str=DmdType] Binds: -- ticks = [src<test.hs:5:1-13>] bar_avN y_amz = src<test.hs:5:9-13> foo (src<test.hs:5:13> y_amz)} }}} Note that neither the occurrence of `(+)` in `foo`, nor the occurrence of `foo` in `bar` have their own Ticks. Instead they are only covered by the Tick for the entire application `x + 1` (resp. `foo y`). I'm trying to use the new SourceNote infrastructure to map CoreExprs back to their original source location, but unfortunately I need these locations for each identifier in the source. Would it be reasonable to add a SourceNote to each occurrence of an identifier? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10506> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23