May 2018 - ghc-tickets

Re: [GHC] #5910: Holes with other constraints
by GHC 05 May '18

05 May '18

#5910: Holes with other constraints -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.5 checker) | Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5910#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10572: Template Haskell does not implicitly quantify types
by GHC 04 May '18

04 May '18

#10572: Template Haskell does not implicitly quantify types -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider the simple quasiquoter producing a type variable: {{{ tv :: QuasiQuoter tv = QuasiQuoter { quoteType = varT . mkName } }}} If a type variable is introduced elsewhere in a type signature, it is implicitly quantified as normal and the TH name resolves properly: {{{ id' :: a -> [tv|a|] id' x = x }}} But if the type variable is not mentioned elsewhere in the type, an error results: {{{ const' :: a -> [tv|b|] -> a const' x _ = x }}} {{{ Not in scope: type variable ‘b’ }}} One would expect the type variable introduced by the TH splice to be included in the implicit quantification of the type signature. In fact, there is no way to introduce a new type variable in this context, apart from using {{{Rank(2/N)Types}}} with an explicit {{{forall}}}. But this prevents the type variable from being referred to elsewhere in the type, eg: {{{ const'' :: [tv|a|] -> b -> [tv|a|] const'' x _ = x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15121: make install fails in 8.5
by GHC 04 May '18

04 May '18

#15121: make install fails in 8.5 -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | 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: -------------------------------------+------------------------------------- On a fresh clone of GHC's master [ 79c4f10e4928c37bf4bbad974be0bd693df2d2b9 ]. The following steps {{{ ./boot ./configure make -j6 make install }}} Fail at the install phase with {{{ "inplace/bin/ghc-cabal" copy libraries/ghc-prim dist-install "strip" '' '/usr/local' '/usr/local/lib/ghc-8.5.20180503' '/usr/local/share/doc/ghc-8.5.20180503/html/libraries' 'v p dyn' Installing library in /usr/local/lib/ghc-8.5.20180503/ghc-prim-0.5.2.0 dist-install/build/HSghc-prim-0.5.2.0.o: copyFile: does not exist (No such file or directory) ghc.mk:996: recipe for target 'install_packages' failed make[1]: *** [install_packages] Error 1 }}} No `HSghc-prim-0.5.2.0.o` has been built, indeed, but a `libHSghc- prim-0.5.2.0.a` exists. I don't know if it's relevant. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15119: Program involving existentials and type class constraint gets rejected
by GHC 04 May '18

04 May '18

#15119: Program involving existentials and type class constraint gets rejected -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | 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 example from https://stackoverflow.com/a/50160423/388010 demonstrates some code involving type classes and existentials that I'd love for it to pass the type checker: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Foo where class C a where getInt :: Int instance C Char where getInt = 42 f :: (forall a. C a => Int) -> Bool f x = even (x @ Char) g :: (forall a. C a => Int) -> Bool g = f -- fails -- g h = f h -- fails -- g h = f getInt -- fails -- g _ = f 42 -- OK }}} This complains with the following error: {{{ test.hs:17:5: error: • Could not deduce (C a0) from the context: C a bound by a type expected by the context: forall a. C a => Int at test.hs:17:5 The type variable ‘a0’ is ambiguous These potential instance exist: instance C Char -- Defined at test.hs:10:10 • In the expression: f In an equation for ‘g’: g = f | 17 | g = f -- fails | ^ }}} Is this expected behavior or a bug? I understand why the program leads to that particular error, but isn't there a way for the compiler to accept this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15120: Default methods don't pass implicit kind parameters properly
by GHC 04 May '18

04 May '18

#15120: Default methods don't pass implicit kind parameters properly -------------------------------------+------------------------------------- Reporter: mbieleck | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: PolyKinds, | Operating System: Unknown/Multiple DefaultSignatures | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling the following module: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DefaultSignatures #-} module TestCase where import Data.Proxy class Describe a where describe :: Proxy a -> String default describe :: Proxy a -> String describe _ = "" data Foo = Foo instance Describe Foo }}} I get the following error (on GHC 8.0.2 and 8.2.2, with `-fprint-explicit- kinds`): {{{ TestCase.hs:15:10: error: • Couldn't match type ‘*’ with ‘Foo’ Expected type: Proxy * Foo -> String Actual type: Proxy Foo Foo -> String • In the expression: TestCase.$dmdescribe @Foo In an equation for ‘describe’: describe = TestCase.$dmdescribe @Foo In the instance declaration for ‘Describe * Foo’ | 15 | instance Describe Foo | ^^^^^^^^^^^^ }}} The Core generated for `$dmdescribe` has the following type signature: {{{ TestCase.$dmdescribe :: forall k (a :: k). Describe k a => Proxy k a -> String }}} I believe the failure results from the fact that the type application `TestCase.$dmdescribe @Foo` passes `Foo` as the `k` parameter instead of `a`. Seems related to https://ghc.haskell.org/trac/ghc/ticket/13998 . -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15120> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15118: Printing non-ASCII characters to console on Windows
by GHC 04 May '18

04 May '18

#15118: Printing non-ASCII characters to console on Windows -------------------------------------+------------------------------------- Reporter: lehins | Owner: (none) Type: bug | Status: new Priority: normal | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As part of an initiative of getting stack to work properly on Windows for users with international names (https://github.com/commercialhaskell/stack/issues/3988) and working on trying to find a fix for {{{ghc-pkg}}} - #15021 I discovered a weird behavior that have been known for a while and does affect other languages, not only Haskell. First of all here is the default behavior on Windows with Locale that isn't Cyrillic for this program: {{{ main :: IO () main = putStrLn "Алексей Кулешевич" }}} {{{ PS C:\phab\windows-console> stack exec -- console console.EXE: <stdout>: commitBuffer: invalid argument (invalid character) }}} Now consider this program: {{{ main :: IO () main = do hSetEncoding stdout utf8 putStrLn "Алексей Кулешевич" }}} Compiling and running it on Windows 7 with English locale results in: {{{ PS C:\phab\windows-console> stack exec -- console ╨É╨╗╨╡╨║╤ü╨╡╨╣ ╨Ü╤â╨╗╨╡╤ê╨╡╨▓╨╕╤ç PS C:\phab\windows-console> chcp 65001 Active code page: 65001 PS C:\phab\windows-console> stack exec -- console Алексей Кулешевич лешевич �ич }}} No knowledge of Russian is necessary in order to see that after the code page is set to {{{65001}}} there are characters printed to the console that don't belong there. That seems to be bug in Windows handling of unicode characters, since it's the exactly same result is `cmd` as well as Powershell and has been reported with other languages like Perl and Java. Worth noting that this also directly affects `ghc`, whenever {{{GHC_CHARENC}}} environment variable is set to {{{"UTF-8"}}}. Besides the bug being described above it is sad that we need to rely on both the code page and the handle encoding to be set correctly in order to even see the semi-correct output without a total program crash. The fix being proposed here is to use {{{WriteConsoleW}}} API call instead of writing to a handle, but only when the handle is actually a console and not pipe. This allows us to print unicode characters correctly without changing or relying on the setting of the current code page. Here is a sample output with my recent experiments: {{{ PS C:\phab\windows-console> chcp Active code page: 437 PS C:\phab\windows-console> stack exec -- console Алексей Кулешевич }}} I'll add some code examples of proposed solution in the upcoming days. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15109: T12425 is failing on CI since 3d38e8284b73
by GHC 03 May '18

03 May '18

#15109: T12425 is failing on CI since 3d38e8284b73 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- T12425 (a perf test) is failing on Linux CI box. tdammers realized it started failing with [https://phabricator.haskell.org/rGHC3d38e8284b7382844f9862e8d8afbae9c7248b09 3d38e8284b73]. It seems like Simon is aware of the performance implications so perhaps we should just bump the numbers. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15109> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15093: Testsuite should output JUnit XML for better CircleCI support
by GHC 03 May '18

03 May '18

#15093: Testsuite should output JUnit XML for better CircleCI support -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: CI | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment when builds are run on CircleCI, failures are not reported in any special way. This means you have to download the build log to see the bottom of the testing phase as it is too long to see in the browser. Instead, you can output the test results as JUnit XML which then CircleCI can slurp up and present nicely. https://circleci.com/docs/2.0 /configuration-reference/#store_test_results There is a python library which makes it easy to generate this output. https://github.com/kyrus/python-junit-xml Even better, an actual python testing library could be used which could automatically output this information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15093> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15049: NUMA not detected on Win10 with AMD Ryzen Threadripper
by GHC 03 May '18

03 May '18

#15049: NUMA not detected on Win10 with AMD Ryzen Threadripper --------------------------------------+--------------------------------- Reporter: kanetw | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.4.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- AMD's Threadripper can be configured to be a 1-socket 2-die NUMA system: Coreinfo.exe: {{{ Logical to Physical Processor Map: **------------------------------ Physical Processor 0 (Hyperthreaded) --**---------------------------- Physical Processor 1 (Hyperthreaded) ----**-------------------------- Physical Processor 2 (Hyperthreaded) ------**------------------------ Physical Processor 3 (Hyperthreaded) --------**---------------------- Physical Processor 4 (Hyperthreaded) ----------**-------------------- Physical Processor 5 (Hyperthreaded) ------------**------------------ Physical Processor 6 (Hyperthreaded) --------------**---------------- Physical Processor 7 (Hyperthreaded) ----------------**-------------- Physical Processor 8 (Hyperthreaded) ------------------**------------ Physical Processor 9 (Hyperthreaded) --------------------**---------- Physical Processor 10 (Hyperthreaded) ----------------------**-------- Physical Processor 11 (Hyperthreaded) ------------------------**------ Physical Processor 12 (Hyperthreaded) --------------------------**---- Physical Processor 13 (Hyperthreaded) ----------------------------**-- Physical Processor 14 (Hyperthreaded) ------------------------------** Physical Processor 15 (Hyperthreaded) Logical Processor to Socket Map: ******************************** Socket 0 Logical Processor to NUMA Node Map: ****************---------------- NUMA Node 0 ----------------**************** NUMA Node 1 Approximate Cross-NUMA Node Access Cost (relative to fastest): 00 01 00: 1.0 1.4 01: 1.7 1.2 }}} However, ghc-8.4.1 doesn't detect the NUMA topology when running with `--numa` {{{ ghc.EXE: --numa: OS reports NUMA is not available }}} I haven't attempted dualbooting into Linux, yet, so I can't tell whether it's a Windows-only issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15049> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14956: NUMA not detected on Aarch64 NUMA machine
by GHC 03 May '18

03 May '18

#14956: NUMA not detected on Aarch64 NUMA machine --------------------------------------+--------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.1 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- {{{ # lscpu Architecture: aarch64 Byte Order: Little Endian CPU(s): 96 On-line CPU(s) list: 0-95 Thread(s) per core: 1 Core(s) per socket: 48 Socket(s): 2 NUMA node(s): 2 L1d cache: 32K L1i cache: 78K L2 cache: 16384K NUMA node0 CPU(s): 0-47 NUMA node1 CPU(s): 48-95 # ./cgraytrace_prof_thread +RTS -s -A40m -qn24 --numa cgraytrace_prof_thread: --numa: OS reports NUMA is not available cgraytrace_prof_thread: cgraytrace_prof_thread: Usage: <prog> <args> [+RTS <rtsopts> | -RTS <args>] ... --RTS <args> ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14