April 2018 - ghc-tickets

[GHC] #14915: T2783 fails with the threaded1 way
by GHC 06 Sep '18

06 Sep '18

#14915: T2783 fails with the threaded1 way --------------------------------------+---------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: T2783 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- When running `./validate --slow` the other day, I saw the XXX test failing with the `threaded1` way. Instead of detecting the loop and aborting with an informative message, we get an assertion failure in the `rts/ThreadPaused.c:threadPaused` function. The program: {{{#!hs main = print $ do x <- [ 0 .. 5 ] ; let { y = 5 - y } ; return y }}} The output: {{{ =====> T2783(threaded1) 1 of 1 [0, 0, 0] cd "./rts/T2783.run" && "/home/alp/ghc/inplace/test spaces/ghc-stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./rts/T2783.run" && ./T2783 Wrong exit code for T2783(threaded1)(expected 1 , actual 134 ) Stderr ( T2783 ): T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 (GHC version 8.5.20180306 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T2783(threaded1) }}} The code for the corresponding assertion: {{{#!c // We should never have made it here in the event of blackholes that // we already own; they should have been marked when we blackholed // them and consequently we should have stopped our stack walk // above. ASSERT(!((bh_info == &stg_BLACKHOLE_info) && (((StgInd*)bh)->indirectee == (StgClosure*)tso))); }}} This seems to be an actual problem, hence this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14915> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10249: Suboptimal error message with deferred type errors
by GHC 05 Sep '18

05 Sep '18

#10249: Suboptimal error message with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> _ <interactive>:2:1: Warning: Found hole ‘_’ with type: IO t0 Where: ‘t0’ is an ambiguous type variable In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly’, namely ‘_’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ *** Exception: <interactive>:2:1: Found hole ‘_’ with type: IO t0 Where: ‘t0’ is an ambiguous type variable In the first argument of ‘GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly’, namely ‘_’ In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ (deferred type error) Prelude> }}} It should ideally not expose `ghciStepIO` to the user. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10249> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10756: Allow users to indicate inaccessible patterns
by GHC 04 Sep '18

04 Sep '18

#10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | 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 Revisions: | -------------------------------------+------------------------------------- Consider {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE GADTs #-} data Elem :: * -> * -> * where EZ :: Elem (f , fs) f ES :: Elem fs f -> Elem (f', fs) f elemAbsurd :: Elem () f -> a elemAbsurd _ = error "inaccessible" }}} This catch-all in `elemAbsurd` is very unfortunate, because if I change my datatype and not all cases are inaccessible anymore the type checker will not be warning me. Although of course there is recent work by SPJ et al on inferring more inaccessible cases, I think it would be tremendously useful for users to be able to indicate that patterns are in fact inaccesible. I'd be very happy if I could write {{{#!hs elemAbsurd :: Elem () f -> a elemAbsurd EZ = inaccessible elemAbsurd (ES _) = inaccessible }}} Note that ghc ''can already detect that these patterns are in fact inaccessible'': it won't let me write the above: {{{ T.hs:12:12: Couldn't match type ‘()’ with ‘(f, fs)’ Inaccessible code in a pattern with constructor EZ :: forall f fs. Elem (f, fs) f, in an equation for ‘elemAbsurd’ }}} So I think it should be very very simple to change the type checker to allow to write cases like this if and only if the RHS is a specially designated symbol "inaccessible", which could be defined simply as {{{#!hs inaccessible :: a inaccessible = error "inaccessible" }}} in `GHC.Prim` or something. This would seem like very little work, and a correspondingly tiny patch, but with quite a large payoff. Future work in automatically detecting inaccessible cases would not make existing code using this style wrong, it just means that we have to write fewer inaccessible cases by hand; but even with more sophisticated inference algorithms for inaccessible cases there will still be inaccessible cases remaining. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #13243: make test in non-validate configuration fails with a variety of ghci errors
by GHC 04 Sep '18

04 Sep '18

#13243: make test in non-validate configuration fails with a variety of ghci errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting with a fresh checkout of `ghc`, testing in a non-validate configuration fails in a rather peculiar way. e.g., {{{ $ ./boot $ ./configure $ make $ make test }}} Results in a number of test failures of the `ghci` way which suggest that GHCi is having trouble identifying types. e.g., {{{ =====> break026(ghci) 50 of 101 [0, 46, 0] cd "./ghci.debugger/scripts/break026.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break026.script Actual stderr output differs from expected: diff -uw "/dev/null" "./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised" --- /dev/null 2017-01-24 15:20:36.872346204 -0500 +++ ./ghci.debugger/scripts/break026.run/break026.run.stderr.normalised 2017-02-08 15:52:09.290099692 -0500 @@ -0,0 +1,14 @@ + +<interactive>:16:1: + No instance for (Show t1) arising from a use of ‘print’ + Cannot resolve unknown runtime type ‘t1’ + Use :print or :force to determine these types + Relevant bindings include it :: t1 (bound at <interactive>:16:1) + These potential instances exist: + instance Show Ordering -- Defined in ‘GHC.Show’ + instance Show Integer -- Defined in ‘GHC.Show’ + instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ + ...plus 22 others + ...plus 11 instances involving out-of-scope types + (use -fprint-potential-instances to see them all) + In a stmt of an interactive GHCi command: print it *** unexpected failure for break026(ghci) =====> break027(ghci) 51 of 101 [0, 47, 0] cd "./ghci.debugger/scripts/break027.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< break027.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/break027.run/break027.stdout.normalised" "./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised" --- ./ghci.debugger/scripts/break027.run/break027.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 +++ ./ghci.debugger/scripts/break027.run/break027.run.stdout.normalised 2017-02-08 15:52:10.750125249 -0500 @@ -1,8 +1,8 @@ Breakpoint 0 activated at QSort.hs:4:12-13 Breakpoint 1 activated at QSort.hs:5:16-51 Stopped in QSort.qsort, QSort.hs:5:16-51 -_result :: [Integer] = _ -a :: Integer = 3 -left :: [Integer] = _ -right :: [Integer] = _ -a :: Integer -- Defined in ‘interactive:Ghci1’ +_result :: [a] = _ +a :: a = _ +left :: [a] = _ +right :: [a] = _ +a :: a -- Defined in ‘interactive:Ghci1’ *** unexpected failure for break027(ghci) =====> print001(ghci) 11 of 101 [0, 7, 0] cd "./ghci.debugger/scripts/print001.run" && HC="/mnt/work/ghc/ghc- testing/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output " "/mnt/work/ghc/ghc-testing/inplace/test spaces/ghc- stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -ignore-dot-ghci< print001.script Actual stdout output differs from expected: diff -uw "./ghci.debugger/scripts/print001.run/print001.stdout.normalised" "./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised" --- ./ghci.debugger/scripts/print001.run/print001.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 +++ ./ghci.debugger/scripts/print001.run/print001.run.stdout.normalised 2017-02-08 15:51:08.413033889 -0500 @@ -1,10 +1,9 @@ li = (_t1::[Maybe Integer]) Just 0 -li = Just 0 : (_t2::[Maybe Integer]) +li = (_t2::[Maybe Integer]) 6 -li = [Just 0,(_t3::Maybe Integer),(_t4::Maybe Integer), - (_t5::Maybe Integer),(_t6::Maybe Integer),(_t7::Maybe Integer)] -li = [Just 0,_,_,_,_,_] +li = (_t3::[Maybe Integer]) +li = _ [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] -li = [Just 0,Just 1,Just 2,Just 3,Just 4,Just 5] +li = (_t4::[Maybe Integer]) +li = _ *** unexpected failure for print001(ghci) }}} It would be nice to know what is going on here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13243> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8414: ghc-pkg prevents dynamic library only packages
by GHC 04 Sep '18

04 Sep '18

#8414: ghc-pkg prevents dynamic library only packages ------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- GHC supports compiling Haskell libraries as dynamic libraries and building executables against dynamic libraries. GHCi seems to support loading modules from dynamic libraries, too. So it would seem that it should be possible to have packages that only include dynamic libraries, omitting the .a and .o files typically generated. cabal-install allows building dynamic libraries only, for example with the command "cabal install --disable-library-vanilla --enable-shared --disable-library-profiling". However, ghc-pkg register refuses to install the package without the .a files present. This seems to be a bug with ghc-pkg. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8414> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10374: Can't build GHC with a dynamic only GHC installation
by GHC 04 Sep '18

04 Sep '18

#10374: Can't build GHC with a dynamic only GHC installation -------------------------------------+------------------------------------- Reporter: jessicah | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When an installation of GHC doesn't include the vanilla "way", GHC cannot be built from this existing installation of GHC. E.g. using the following mk/build.mk: {{{ V = 0 GhcLibWays = dyn SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O -fasm GhcStage2HcOpts = -O2 -fasm GhcHcOpts = -Rghc-timing GhcLibHcOpts = -O2 DYNAMIC_BY_DEFAULT = YES NoFibWays = STRIP_CMD = : }}} Steps to reproduce: 1. build & install GHC using above configuration 2. rebuild GHC using above configuration, --with-ghc pointing to the installation created in step 1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14963: ghci -fdefer-type-errors can't run IO action from another module
by GHC 03 Sep '18

03 Sep '18

#14963: ghci -fdefer-type-errors can't run IO action from another module -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.1 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: -------------------------------------+------------------------------------- This is enough to trigger a crash on OS X and Linux: Bug1.hs: {{{ module Bug1.hs where import qualified Bug2 test :: IO Bool test = Bug2.failure }}} Bug2.hs: {{{ module Bug2 where failure :: IO Bool failure = return False }}} Shell: {{{ % ghci -fdefer-type-errors -ignore-dot-ghci GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help Prelude> :load Bug [1 of 2] Compiling Bug2 ( Bug2.hs, interpreted ) [2 of 2] Compiling Bug ( Bug.hs, interpreted ) Ok, two modules loaded. *Bug> test ghc: panic! (the 'impossible' happened) (GHC version 8.4.1 for x86_64-apple-darwin): nameModule system $dShow_a1LX Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is specific to 8.4.1, in 8.0.2 I get "False" as expected. If I leave off -fdefer-type-errors, it works. It also seems to be ghci only, compiling with -fdefer-type-errors doesn't have the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 40

[GHC] #14589: The isUpper function should return true for the '\9438' character
by GHC 03 Sep '18

03 Sep '18

#14589: The isUpper function should return true for the '\9438' character -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | 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: -------------------------------------+------------------------------------- {{{ λ> toLower '\9438' '\9438' λ> toUpper '\9438' '\9412' λ> isUpper '\9438' False λ> isLower '\9438' False }}} Here we can observe a contradiction. The `toLower` function does not alter its argument, but `toUpper` does, which tells us that the character 1) has the notion of case 2) it must be lower-cased. On the other hand, both `isUpper` and `isLower` functions return `False` for `\9438` suggesting that it has no notion of case. Apparently, `\9438` is lower-cased and `\9412` is its upper-cased version indeed: {{{ λ> putStrLn "\9438" ⓞ λ> putStrLn "\9412" Ⓞ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8441: Allow family instances in an hs-boot file
by GHC 02 Sep '18

02 Sep '18

#8441: Allow family instances in an hs-boot file ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Compiling an .hs-boot file with a data instance leads to this error: {{{ Illegal family instance in hs-boot file }}} Yet, data instances make good sense in an hs-boot file, in case another module wants to access a constructor declared in the instance. Furthermore, it may sometimes be desirable to allow type family instances in a hs-boot file, as well, in case some including modules need the instance for type simplification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8441> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13930: Cabal configure
by GHC 02 Sep '18

02 Sep '18

#13930: Cabal configure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- `cabal configure` apparently has a space leak when compiled with GHC HEAD but not 8.0. It's not clear whether this is really a GHC regression yet, but here it is certainly GHC version-specific. See https://github.com/haskell/cabal/issues/4589 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21