April 2018 - ghc-tickets

[GHC] #15108: Panic: collectNBinders
by GHC 01 May '18

01 May '18

#15108: Panic: collectNBinders -------------------------------------+------------------------------------- Reporter: cdisselkoen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.4.2 Keywords: panic | Operating System: Linux collectNBinders | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.4.2 panics with the error message `collectNBinders`, when compiling with profiling. This is a very similar bug to #15002, but although #15002 is fixed in 8.4.2, this panic persists. Steps to reproduce: `stack.yaml`: {{{ resolver: nightly-2018-04-30 }}} `bug.cabal`: {{{ name: bug version: 0.1.0.0 build-type: Simple cabal-version: >=1.10 library build-depends: base default-language: Haskell2010 executable bug main-is: Main.hs build-depends: base , bug default-language: Haskell2010 }}} `Main.hs`: {{{ module Main where main :: IO () main = do _ <- return $ getInt Circle return () newtype MyInt = MyInt Int data Shape = Circle | Square getInt :: Shape -> MyInt getInt sh = case sh of Circle -> let (MyInt i) = MyInt 3 in myInt i Square -> let (MyInt i) = MyInt 2 in myInt i where myInt = MyInt }}} Then run: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 $ stack build --profile bug-0.1.0.0: build (lib + exe) Preprocessing library for bug-0.1.0.0.. Building library for bug-0.1.0.0.. Preprocessing executable 'bug' for bug-0.1.0.0.. Building executable 'bug' for bug-0.1.0.0.. [1 of 1] Compiling Main ( Main.hs, .stack-work/dist/x86_64 -linux-tinfo6-nopie/Cabal-2.2.0.1/build/bug/bug-tmp/Main.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.2 for x86_64-unknown-linux): collectNBinders 1 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreSyn.hs:2025:25 in ghc:CoreSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package bug-0.1.0.0 using: /usr/local/home/<USER>/.stack/setup-exe-cache/x86_64-linux- tinfo6-nopie/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.2 --builddir=.stack- work/dist/x86_64-linux-tinfo6-nopie/Cabal-2.2.0.1 build lib:bug exe:bug --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15108> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11323: powerpc64: recomp015 fails with redundant linking
by GHC 01 May '18

01 May '18

#11323: powerpc64: recomp015 fails with redundant linking -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time Test Case: | performance bug driver/recomp15 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... Running main... +Linking Main ... Running main... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11323> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15096: GHC fails to execute gcc on Windows when unicode character is in the path
by GHC 30 Apr '18

30 Apr '18

#15096: GHC fails to execute gcc on Windows when unicode character is in the path -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: #15021 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens when the location of gcc is under a path with non-ASCII directory in it: {{{ PS C:\Users\日\stack-test> & 'C:\Users\日 \AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\bin\ghc.exe' -no- user-package-db .\Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) <no location info>: error: Warning: Couldn't figure out C compiler information! Make sure you're using GNU gcc, or clang Unable to start C:\Users\?\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\mingw\bin/realgcc.exe (error code: 123) `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} Tested with ghc 8.0.2 on Windows Server 2016 (same setup as in #15021). This was discovered as part of the effort to make Haskell tooling work well for users with non-ASCII user names: https://github.com/commercialhaskell/stack/issues/3988 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15096> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15106: Explore using pure unifier instead of monadic one
by GHC 30 Apr '18

30 Apr '18

#15106: Explore using pure unifier instead of monadic one -------------------------------------+------------------------------------- Reporter: goldfire | 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: -------------------------------------+------------------------------------- GHC contains no fewer than three unifiers! This ticket is about removing one of them. Here are the three: 1. The eager monadic unifier, implemented in `TcUnify`, takes the first stab at unification during type inference. If it runs into trouble, it defers the equality to the solver. It returns a coercion. 2. The pure unifier works to sort out type family reductions, instance selection, and rule matching. It's implemented in `Unify`. This unifier returns, upon success, a substitution. 3. The solver contains a unification-like algorithm in `TcCanonical` that decomposes equalities en route to solving them. Simon and I hit upon a radical idea this morning: what if eager unification simply called the pure unifier? The pure unifier can also take a set (or description) of variables that can be in the domain of the returned substitution. In the case of the eager unifier, this domain would be the metavariables. The pure unifier would, if successful, return a substitution from metavariables to types, and the monadic code would simply use this substitution to fill in the types. It's not yet clear what the implications of this change would be on performance, but it seems like an interesting idea to try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15100: `ApplicativeDo` needlessly uses `join` too much
by GHC 30 Apr '18

30 Apr '18

#15100: `ApplicativeDo` needlessly uses `join` too much -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 (CodeGen) | 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: -------------------------------------+------------------------------------- {{{#!hs foo = do A 1 B 2 C 3 return () }}} produces very different code than {{{#!hs foo = do A 1 B 2 C 3 }}} for no good reason. Currently we check to see if the last clause is a `return` or something else, and then bolt a `join` in if it isn't `return`. But this check is too conservative. If it isn't a `return` but doesn't reference any of the variables above, you can still desugar it with `(<*>)`. We found this during a twitch livestream in front of an audience of 127 people. =) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches
by GHC 30 Apr '18

30 Apr '18

#15089: Compiling stage2 with -g causes spurious test suite failures due to stderr mismatches -------------------------------------+------------------------------------- Reporter: mpickering | 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: -------------------------------------+------------------------------------- If you compile stage2 libraries with -g by using `GhcLibHcOpts` then many tests fail with stderr mismatch errors. It would perhaps be more robust to pass `-dsuppress-ticks` by default to tests so that it is possible to compile with debugging information and still run tests successfully. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15089> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15097: Missing instance Applicative (K1 i c)
by GHC 28 Apr '18

28 Apr '18

#15097: Missing instance Applicative (K1 i c) -------------------------------------+------------------------------------- Reporter: ekmett | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.2 Libraries | 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.Generics has common instances for various haskell classes. It is missing the instance for Applicative (K1 i c) -- `K1 i` is morally like `Const` so it should have the same set of instances. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15083: cannot install GHC on CentOS
by GHC 28 Apr '18

28 Apr '18

#15083: cannot install GHC on CentOS -------------------------------------+------------------------------------- Reporter: kbrown | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the information of my system: {{{ > cat /etc/*release CentOS Linux release 7.4.1708 (Core) NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" VERSION_ID="7" PRETTY_NAME="CentOS Linux 7 (Core)" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:centos:centos:7" HOME_URL="https://www.centos.org/" BUG_REPORT_URL="https://bugs.centos.org/" CENTOS_MANTISBT_PROJECT="CentOS-7" CENTOS_MANTISBT_PROJECT_VERSION="7" REDHAT_SUPPORT_PRODUCT="centos" REDHAT_SUPPORT_PRODUCT_VERSION="7" }}} I want to build a Stack project on this system, but I receive an "impossible" error even when I try to build a trivial project. {{{ >wget https://www.stackage.org/stack/linux-x86_64-static >tar -xzf linux-x86_64-static > cp stack-1.6.5-linux-x86_64-static/stack .local/bin/ > stack new stacktest Downloading template "new-template" to create project "stacktest" in stacktest/ ... The following parameters were needed by the template but not provided: author-email, author-name, category, copyright, github-username You can provide them in /home/users/ksb/.stack/config.yaml, like this: templates: params: author-email: value author-name: value category: value copyright: value github-username: value Or you can pass each one as parameters like this: stack new stacktest new-template -p "author-email:value" -p "author- name:value" -p "category:value" -p "copyright:value" -p "github- username:value" Looking for .cabal or package.yaml files to use to init the project. Using cabal packages: - stacktest/ Selecting the best among 13 snapshots... * Matches lts-11.6 Selected resolver: lts-11.6 Initialising configuration using resolver: lts-11.6 Total number of user packages considered: 1 Writing configuration to file: stacktest/stack.yaml All done. > stack build [1 of 2] Compiling Main ( /home/users/ksb/.stack/setup-exe-src /setup-mPHDZzAJ.hs, /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): toStgWord: Unknown platformWordSize: 0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building simple Setup.hs using: /home/users/ksb/.stack/programs/x86_64-linux/ghc-8.2.2/bin/ghc -rtsopts -threaded -clear-package-db -global-package-db -hide-all-packages -package base -main-is StackSetupShim.mainOverride -package Cabal-2.0.1.0 /home/users/ksb/.stack/setup-exe-src/setup-mPHDZzAJ.hs /home/users/ksb/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -o /home/users/ksb/.stack/setup-exe-cache/x86_64-linux/tmp-Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 Process exited with code: ExitFailure 1 }}} Can you help me identify why this build failed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15083> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15057: Lint types created by newFamInst
by GHC 27 Apr '18

27 Apr '18

#15057: Lint types created by newFamInst -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15012, we observed a terrible failure resulting from `newFamInst` creating a type family instance with an unbound type variable on the right-hand side. What's worse, `-dcore-lint` didn't catch it! Let's fix that by calling `lintType` on the types involved in `newFamInst`. A wrinkle in this plan is that `lintType` currently expands all type synonyms, but the offending type in #15012 had the unbound variable occur in a type synonym application, so expanding type synonyms would make this naughtiness seemingly vanish (from Core Lint's perspective). We should configure `lintType` so that one can control its type synonym expansion behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15057> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #14149: Tyepchecker generates top-level unboxed coercion
by GHC 27 Apr '18

27 Apr '18

#14149: Tyepchecker generates top-level unboxed coercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Consider this code {{{ {-# OPTIONS_GHC -fdefer-out-of-scope-variables #-} module Foo where import Data.Coerce f :: Bool f = coerce (k :: Int) }}} It generates a lint error: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: warning: [RHS of cobox_a11N :: (Int :: *) ~R# (Bool :: *)] The type of this binder is unlifted: cobox_a11N Binder's type: (Int :: *) ~R# (Bool :: *) *** Offending Program *** $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Foo"#) cobox_a11N :: (Int :: *) ~R# (Bool :: *) [LclId[CoVarId]] cobox_a11N = typeError @ ('TupleRep '[]) @ ((Int :: *) ~R# (Bool :: *)) "Foo.hs:8:5: error:\n\ \ \\226\\128\\162 Couldn't match representation of type \\226\\128\\152Int\\226\\128\\153 with that of \\226\\128\\152Bool\\226\\128\\153\n\ \ arising from a use of \\226\\128\\152coerce\\226\\128\\153\n\ \ \\226\\128\\162 In the expression: coerce (k :: Int)\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = coerce (k :: Int)\n\ \(deferred type error)"# f :: Bool [LclIdX] f = (typeError @ 'LiftedRep @ Int "Foo.hs:8:13: error: Variable not in scope: k :: Int\n\ \(deferred type error)"#) `cast` (cobox_a11N :: (Int :: *) ~R# (Bool :: *)) *** End of Offense *** }}} Reason: this rather hacky test in `TcUnify.buildImplication` {{{ ; if null skol_tvs && null given && (not deferred_type_errors || not (isTopTcLevel tc_lvl)) }}} did take account of `Opt_DeferOutOfScopeVariables`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14149> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5