July 2016 - ghc-tickets

[GHC] #12249: Template Haskell top level scoping error
by GHC 05 Jul '16

05 Jul '16

#12249: Template Haskell top level scoping error -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.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: -------------------------------------+------------------------------------- Consider this {{{ module TH where $( [d| x = True; f1 = x |]) $( [d| x = 'c'; f2 = x |] ) }}} I think this should compile fine. There are two bindings of `x`, so I would not expect to be able to name `x` in the export list, or indeed anywhere else. But `x` may just be a local helper-function to the other bindings (`f1` and `f2` resp) so that's fine. Alas I get {{{ ~/5builds/HEAD-4/inplace/bin/ghc-stage2 -c TH.hs -ddump-splices -ddump-tc TH.hs:5:4-26: Splicing declarations [d| x_apA = True f1_apB = x_apA |] ======> x_a3tN = True f1_a3tO = x_a3tN TH.hs:7:4-25: Splicing declarations [d| x_a3u4 = 'c' f2_a3u5 = x_a3u4 |] ======> x_a3uW = 'c' f2_a3uX = x_a3uW TH.hs:7:4: error: Multiple declarations of ‘x’ Declared at: TH.hs:5:4 TH.hs:7:4 TH.hs:7:4: error: The exact Name ‘x_a3uW’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful }}} So: * Perhaps we should not complain about multiple top-level bindings for `x` if they are all `Exact` RdrNames. * And the "not in scope" message is clearly bogus. Mind you, would you expect this to work? {{{ x = True $( [d| x = 'c'; f2 = x |] ) foo = x -- Which 'x' do we get? }}} Maybe the occurrence of `x` in `foo` is ambiguous. If you want to splice a hidden helper binding, which can't clash with some earlier or later user-supplied thing, then use an occurrence like `$x`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 05 Jul '16

05 Jul '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"55e43a6f9ef64cf31faca350f8bf86f5f5acb36a/ghc" 55e43a6f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55e43a6f9ef64cf31faca350f8bf86f5f5acb36a" Use DVarEnv for vectInfoVar This makes sure that we don't introduce unnecessary nondeterminism from vectorization. Also updates dph submodule to reflect the change in types. GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:222> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7437: peculiar behaviour with default instances and type variables
by GHC 05 Jul '16

05 Jul '16

#7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T7437 Blocked By: | Blocking: Related Tickets: #12151 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T7437 * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7437#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7437: peculiar behaviour with default instances and type variables
by GHC 05 Jul '16

05 Jul '16

#7437: peculiar behaviour with default instances and type variables -------------------------------------+------------------------------------- Reporter: bos | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #12151 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In [changeset:"85aa6ef09346e841abf4e089b24c7f783286cd74/ghc" 85aa6ef0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85aa6ef09346e841abf4e089b24c7f783286cd74" Check generic-default method for ambiguity Fixes Trac #7497 and #12151. In some earlier upheaval I introduced a bug in the ambiguity check for genreric-default method. This patch fixes it. But in fixing it I realised that the sourc-location of any such error message was bogus, so I fixed that too, which involved a slightly wider change; see the comments with TcMethInfo. }}} The commit message has a typo about the ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7437#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7497: qsem001 and qsemn001 fail in HEAD
by GHC 05 Jul '16

05 Jul '16

#7497: qsem001 and qsemn001 fail in HEAD -------------------------------------+--------------------------------- Reporter: igloo | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"85aa6ef09346e841abf4e089b24c7f783286cd74/ghc" 85aa6ef0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85aa6ef09346e841abf4e089b24c7f783286cd74" Check generic-default method for ambiguity Fixes Trac #7497 and #12151. In some earlier upheaval I introduced a bug in the ambiguity check for genreric-default method. This patch fixes it. But in fixing it I realised that the sourc-location of any such error message was bogus, so I fixed that too, which involved a slightly wider change; see the comments with TcMethInfo. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7497#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4012: Compilation results are not deterministic
by GHC 05 Jul '16

05 Jul '16

#4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka <niteria@…>): In [changeset:"e10497b9a3622265b88caa60590ed620ff3d33e2/ghc" e10497b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e10497b9a3622265b88caa60590ed620ff3d33e2" Kill some varEnvElts I was able to hide the nondeterminism in some specialized function, which I believe will be useful in other places. GHC Trac: #4012 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4012#comment:221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5987: Too many symbols in ghc package DLL
by GHC 04 Jul '16

04 Jul '16

#5987: Too many symbols in ghc package DLL ---------------------------------+---------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10352 | Blocking: 5355 Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * blockedby: => 10352 Comment: Quick update, dynamic linking now works again: {{{ $ ghc-stage2 -fforce-recomp test.hs -dynamic && ./test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test.exe ... Hello World }}} And loader logs: {{{ Process Started: 0000000000400000 E:\temp\dynamic\test.exe ... DLL Loaded: 0000000070D00000 R:\GHC\libHSghc- prim-0.5.0.0-ghc8.1.20160628.dll DLL Loaded: 0000000067240000 R:\GHC\libHSrts-ghc8.1.20160628.dll ... DLL Loaded: 0000000069F80000 R:\GHC\libHSbase-4.9.0.0-ghc8.1.20160628.dll ... DLL Loaded: 000000006B740000 R:\GHC\libffi-6.dll ... DLL Loaded: 0000000069780000 R:\GHC\libHSinteger- gmp-1.0.0.1-ghc8.1.20160628.dll }}} Approach is written https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking here and I'll keep updating it as I go. Code is not done but changes can be seen https://github.com/Mistuke/ghc/pull/5 on my Github. The major limitation in this version is that only the normal `rts` can be used. Due to the fact that we can't link with unknown symbols on Windows in the final link. After talking to `rwbarton` I believe this can be solved by a Windows version of #10352 and so temporarily stopping work on this so I can take a look at #10352 instead. Remaining: - Figure out the `ASSERT` failures in `compiler/stgSyn/CoreToStg.hs` - Fix dist building to include split dlls if split occurs - Implement mechanism to select right `rts` version. - Clean up code For reference, the sizes of the produced `dlls` are now also a tad smaller {{{ 695960 /r/GHC/libHSarray-0.5.1.1-ghc8.1.20160628.dll 11997540 /r/GHC/libHSbase-4.9.0.0-ghc8.1.20160628.dll 770941 /r/GHC/libHSbinary-0.8.3.0-ghc8.1.20160628.dll 1222357 /r/GHC/libHSbytestring-0.10.8.1-ghc8.1.20160628.dll 17275289 /r/GHC/libHSCabal-1.25.0.0-ghc8.1.20160628.dll 2327994 /r/GHC/libHScontainers-0.5.7.1-ghc8.1.20160628.dll 183756 /r/GHC/libHSdeepseq-1.4.2.0-ghc8.1.20160628.dll 386058 /r/GHC/libHSdirectory-1.2.6.2-ghc8.1.20160628.dll 224319 /r/GHC/libHSfilepath-1.4.1.0-ghc8.1.20160628.dll 47179898 /r/GHC/libHSghc-8.1-ghc8.1.20160628.dll 583840 /r/GHC/libHSghc-boot-8.1-ghc8.1.20160628.dll 476365 /r/GHC/libHSghc-boot-th-8.1-ghc8.1.20160628.dll 2004675 /r/GHC/libHSghci-8.1-ghc8.1.20160628.dll 3144663 /r/GHC/libHSghc-prim-0.5.0.0-ghc8.1.20160628.dll 1721465 /r/GHC/libHShaskeline-0.7.2.3-ghc8.1.20160628.dll 894721 /r/GHC/libHShoopl-3.10.2.1-ghc8.1.20160628.dll 318805 /r/GHC/libHShpc-0.6.0.3-ghc8.1.20160628.dll 761724 /r/GHC/libHSinteger-gmp-1.0.0.1-ghc8.1.20160628.dll 668894 /r/GHC/libHSpretty-1.1.3.3-ghc8.1.20160628.dll 264811 /r/GHC/libHSprocess-1.4.2.0-ghc8.1.20160628.dll 1680082 /r/GHC/libHSrts_debug-ghc8.1.20160628.dll 2182245 /r/GHC/libHSrts_l-ghc8.1.20160628.dll 1796551 /r/GHC/libHSrts_thr_debug-ghc8.1.20160628.dll 2466036 /r/GHC/libHSrts_thr_l-ghc8.1.20160628.dll 2206968 /r/GHC/libHSrts_thr-ghc8.1.20160628.dll 1949321 /r/GHC/libHSrts-ghc8.1.20160628.dll 4638331 /r/GHC/libHStemplate-haskell-2.11.0.0-ghc8.1.20160628.dll 1448186 /r/GHC/libHStime-1.6.0.1-ghc8.1.20160628.dll 1494791 /r/GHC/libHStransformers-0.5.2.0-ghc8.1.20160628.dll 2644212 /r/GHC/libHSWin32-2.3.1.1-ghc8.1.20160628.dll }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5987#comment:58> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12361: Add -dppr-ribbon-cols
by GHC 04 Jul '16

04 Jul '16

#12361: Add -dppr-ribbon-cols -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: easy | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Right now, users can control the width of GHC error messages (`-dppr- ribbons-per-line`) but not the ratio of line length to ribbon length. The latter would be useful, because in some contexts a user might prefer error messages to be as densely packed as possible (ratio of 1.0). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12361> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #393: functions without implementations
by GHC 03 Jul '16

03 Jul '16

#393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | Resolution: wontfix | Keywords: newcomer 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 Iceland_jack): Here is a use case: Rank-N types {{{#!hs f :: (forall a. a -> a) -> (Int, Char) -> (Int, Char) f = undefined }}} does not compile. You'd have to write {{{#!hs f :: (forall a. a -> a) -> (Int, Char) -> (Int, Char) f _ = undefined }}} It would be cool if omitting the function body worked {{{#!hs f :: (forall a. a -> a) -> (Int, Char) -> (Int, Char) }}} ---- It would also be nice if this worked in local definitions {{{#!hs g = h 'a' where h :: Char -> Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/393#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12362: don't complain about type variable ambiguity when the expression is parametrically polymorphic
by GHC 03 Jul '16

03 Jul '16

#12362: don't complain about type variable ambiguity when the expression is parametrically polymorphic -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- I'm not sure this is really a good idea, but it did come up in practice. Consider the following rather contrived program: {{{#!hs {-# LANGUAGE TypeFamilies, RankNTypes, ScopedTypeVariables, AllowAmbiguousTypes, TypeApplications #-} module E where type family T a type instance T Int = Char type instance T String = Char type instance T Bool = () newtype FT a = FT [T a] m :: forall a. (forall x. T x -> Int) -> FT a -> [Int] m f (FT xs) = map f xs }}} GHC rejects it with the error: {{{ E.hs:14:21: error: • Couldn't match type ‘T a’ with ‘T x0’ Expected type: [T x0] Actual type: [T a] NB: ‘T’ is a type function, and may not be injective The type variable ‘x0’ is ambiguous • In the second argument of ‘map’, namely ‘xs’ In the expression: map f xs In an equation for ‘m’: m f (FT xs) = map f xs • Relevant bindings include xs :: [T a] (bound at E.hs:14:9) m :: (forall x. T x -> Int) -> FT a -> [Int] (bound at E.hs:14:1) }}} The problem seems to be that GHC doesn't know at what type to instantiate `f`, because it can't conclude from the argument of `f` being `T a` that the type parameter of `f` needs to be `x`. In fact, `T` here really is not injective, so if `a` is `Int`, `x` could just as well be `String`. However, in this case the ambiguity doesn't actually matter. If `f @Int` and `f @String` have the same type because `T Int ~ T String`, then they are actually the same value too by parametricity, because there is no class constraint on `x`. Since GHC prints a message saying that `T` is not known to be injective, it sounds like it knows about the possible solution `x0 = a`. So it could just pick it, and accept the original program. With TypeApplications I can just specify the intended value of `x` by writing {{{ m f (FT xs) = map (f @a) xs }}} which is a reasonable workaround in my real use case also. Interestingly I can't seem to achieve the same thing without TypeApplications without adding a proxy argument to `f`, which I don't much want to do. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12362> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0