October 2018 - ghc-tickets

[GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness
by GHC 02 Nov '18

02 Nov '18

#14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7210 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} }}} {{{ [1 of 1] Compiling Main ( Temp.hs, Temp.o ) Temp.hs:1:19: error: • Unexpected strictness annotation: {-# UNPACK #-}Maybe • In the type ‘{-# UNPACK #-}Maybe Int’ In the definition of data constructor ‘A’ In the data declaration for ‘A’ | 1 | data A = A { a :: {-# UNPACK #-} Maybe Int} | }}} The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite. A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14761> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level
by GHC 01 Nov '18

01 Nov '18

#15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- A file A defines a typeclass, and gives an instance for all types a, and exports a function relying on said typeclass. A file B defines a data type, makes it a specific `OVERLAPPING` instance of that class, and uses the function defined in A. Which instance ends up being picked for B depends on the optimisation level those files are compiled with. **Minimal test case** //A.hs// {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_GHC -fno-warn-simplifiable-class-constraints #-} module A where import Data.Maybe class A a where someValue :: a -> Maybe Int instance A a where someValue = const Nothing getInt :: A a => a -> Int getInt x = fromMaybe 0 $ someValue x }}} //B.hs// {{{#!hs module B where import A data B = B Int instance {-# OVERLAPPING #-} A B where someValue (B x) = Just x getBInt :: Int getBInt = getInt $ B 42 }}} //Main.hs// {{{#!hs import B main :: IO () main = putStrLn $ "B: " ++ show getBInt }}} To reproduce: {{{ $ ghc -O0 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 42 $ ghc -O2 -fforce-recomp Main.hs && ./Main [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Linking Main ... B: 0 }}} The fix introduced to fix ticket:14434 instructs the "short-cut solver" to not automatically choose a matching instance if it marked as `INCOHERENT` or `OVERLAPPABLE`, but in this case the instance is not marked in any way. This might be the source of the bug? Additionally, whatever the optimisation level, ghc emits a warning about the `A a =>` class constraint being simplifiable; but if it is removed, then the program prints "0" in both cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15135> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15654: Use deriving Functor in the codebase
by GHC 01 Nov '18

01 Nov '18

#15654: Use deriving Functor in the codebase -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- In many places in compiler/ we manually define a Functor instance (`git grep "instance Functor"` shows 60). I think we could switch to `deriving` in most (or all?) cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15821: Implement constant folding for Naturals
by GHC 01 Nov '18

01 Nov '18

#15821: Implement constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table. To fix this you will want to implement rules similar to those for `Integer` in the `PrelRules` module. Additionally, you will need to comment back in the `CONSTANT_FOLDED` pragmas in `GHC.Natural` (see Phab:D5267) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15494: Cannot install GHC through stack on NixOS
by GHC 31 Oct '18

31 Oct '18

#15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: install | Operating System: Linux fail,NixOS,Linux | Type of failure: Installing GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- stack setup gives me this error: Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file-system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15494> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so
by GHC 31 Oct '18

31 Oct '18

#14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: 1. Make a pristine git checkout 2. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc. 3. Check ghc version to verify that this ghc build is the one in `/usr/local/bin` 4. Try to compile the following `hello.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH main = putStrLn $(litE (stringL "Hello")) }}} It should fail with an error message similar to: {{{ <no location info>: error: ghc: panic! (the 'impossible' happened) (GHC version 8.3.20171120 for x86_64-unknown-linux): Dynamic linker not initialised CallStack (from -prof): Linker.CAF (<entire-module>) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} and: {{{ <no location info>: error: <command line>: can't load .so/.DLL for: libHSghc-prim-0.5.2.0.so (libHSghc-prim-0.5.2.0.so: cannot open shared object file: No such file or directory) }}} By contrast, the following do *not* trigger the error: - Building GHC without uncommenting the `BuildFlavour` line in `build.mk` - Compiling with the `inplace/bin/ghc-stage2` in the GHC source tree - Compiling a `hello.hs` that does not use TemplateHaskell Further system info: - Debian 9 - Cabal version 1.24 - GHC 8.0.1 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14512> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory
by GHC 31 Oct '18

31 Oct '18

#15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I had a file called `Main.hs` in my top-level GHC folder. When running `./utils/ghc-in-ghci/run.sh`, the script tried to load this random file. I'm not sure which `Main` it is trying to load but it was not the right one! Workaround: Don't have a file called `Main.hs` in the top-level directory. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15834: genSym is not thread safe with respect to setNumCapabilities
by GHC 30 Oct '18

30 Oct '18

#15834: genSym is not thread safe with respect to setNumCapabilities ----------------------------------------+--------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In a large proprietary application using the GHC API, we observe really weird errors (e.g. overlapping instances for {{{Eq Foo}}} and {{{Eq Bar}}}, where {{{Foo}}} and {{{Bar}}} are completely unrelated, and come from different modules). The pattern we follow is: * Running with the threaded RTS, 1 initial thread * Create a new unique supply with {{{mkSplitUniqSupply}}} and put it in an {{{MVar}}}. * Repeating many times: * Set the thread count higher (e.g. 8) using {{{setNumCapabilities}}} * On many threads in parallel: * Obtain a new unique supply on the original with {{{splitUniqSupply}}}, protected by the {{{MVar}}}, and update the other one in the {{{MVar}}} * Use that unique supply to interact with the GHC API * Set the thread count back to 1 Our observations of the errors are best explained by the unique names not being nearly as unique as they might be expected to be. Reading the code for {{{genSym}}}: {{{#!c if (n_capabilities == 1) { GenSymCounter = (GenSymCounter + GenSymInc) & UNIQUE_MASK; checkUniqueRange(GenSymCounter); return GenSymCounter; } else { HsInt n = atomic_inc((StgWord *)&GenSymCounter, GenSymInc) & UNIQUE_MASK; checkUniqueRange(n); return n; } }}} It only does an {{{atomic_inc}}} if {{{n_capabilities == 1}}}, but it doesn't read {{{n_capabilities}}} atomically, so is it suffering a race? The solution was to set the thread count initially, before any interactions with the GHC API, which seems to solve the problem. Alas, we don't have a reproducible test case, and in fact were unable to reproduce it anywhere but our Linux CI, and even then non-deterministically. The problem does not currently impact us (the workaround is robust), but it seemed worth sharing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15834> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts
by GHC 30 Oct '18

30 Oct '18

#15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE FunctionalDependencies, FlexibleContexts #-} module Bug where class C a b | b -> a where f :: a -> b y = x where x :: (C () b, C Bool b) => b x = f () }}} {{{ $ ghc -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-openbsd): StgCmmEnv: variable not found $dC_a1lC local binds for: f $tc'C:C $tcC $trModule $tc'C:C1_r1mz $tc'C:C2_r1n0 $krep_r1n1 $krep1_r1n2 $krep2_r1n3 $krep3_r1n4 $krep4_r1n5 $tcC1_r1n6 $tcC2_r1n7 $krep5_r1n8 $krep6_r1n9 $krep7_r1na $trModule1_r1nb $trModule2_r1nc $trModule3_r1nd $trModule4_r1ne $krep8_r1nf $krep9_r1ng Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15767> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15838: Warn about unused dependencies
by GHC 30 Oct '18

30 Oct '18

#15838: Warn about unused dependencies -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- GHC loads packages lazily, so at the end of compilation (at least in `--make` mode) it knows all the dependencies, required to compile the code. See `eps_PIT` in `ExternalPackageState`. If we compare this list with the list of packages, passed on command like via `--package-id`, then we'll get a list of unused dependencies. I propose to add a flag `-Wunused-packages`, off by default, which will report the unused packages if any. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15838> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2