January 2019 - ghc-tickets

[GHC] #16157: Duplicate symbol error on Windows
by GHC 09 Jan '19

09 Jan '19

#16157: Duplicate symbol error on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `T11072gcc` is failing on Windows with {{{ Wrong exit code for T11072gcc()(expected 0 , actual 2 ) Stderr ( T11072gcc ): GHC runtime linker: fatal error: I found a duplicate definition for symbol ghczmprim_GHCziClasses_zdp31ZLzvz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUz2cUzvZR_info whilst processing object file C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\testsuite\tests\ghci\linking\dyn\T11072gcc.run\bin_impl_gcc\libASx.dll.a The symbol was previously defined in C:\GitLabRunner\builds\78d7d3f9\0\ghc\ghc\libraries\ghc-prim\dist- install\build\HSghc-prim-0.5.3.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.7.20190106 for x86_64-unknown-mingw32): loadArchive "C:\\GitLabRunner\\builds\\78d7d3f9\\0\\ghc\\ghc\\testsuite\\tests\\ghci\\linking\\dyn\\T11072gcc.run\\bin_impl_gcc\\libASx.dll.a": failed Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[2]: *** [Makefile:85: compile_libAS_impl_gcc] Error 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16157> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15938: Hadrian's recompilation check is extremely slow
by GHC 09 Jan '19

09 Jan '19

#15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong. I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15938> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 43

[GHC] #16162: External interpreter is broken on Windows
by GHC 09 Jan '19

09 Jan '19

#16162: External interpreter is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- There is plenty of evidence to suggest that the external interpreter is currently broken on Windows: * #14271 reports crashes when running `ghci` * #16156 reports a number of testsuite failures -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16162> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #16158: T15094 fails on Windows
by GHC 09 Jan '19

09 Jan '19

#16158: T15094 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- `T15904` fails with: {{{ =====> T15904(normal) 1996 of 6747 [0, 6, 0] cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904 Wrong exit code for T15904()(expected 0 , actual 2 ) Stdout ( T15904 ): [1 of 1] Compiling T15904 ( T15904.hs, T15904.o ) Linking "T15904".exe ... Stderr ( T15904 ): "T15904".exe.manifest: openFile: invalid argument (Invalid argument) make[2]: *** [Makefile:7: T15904] Error 1 *** unexpected failure for T15904(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16158> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14576: Internal error when compiling TH code with profiling on Windows
by GHC 09 Jan '19

09 Jan '19

#14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the GHC API with this minimal example, compiled with profiling enabled: {{{#!hs module Main where import GHC import GHC.Paths ( libdir ) main = runGhc (Just libdir) $ do env <- getSession dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "A.hs" Nothing setTargets [target] load LoadAllTargets }}} Invoking the main executable: {{{ testprof }}} While A.hs contains a TH splice: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where $(return []) }}} The compiler crashes: {{{ testprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} The walkaround is to use -fexternal-interpreter, in that case, the crash does not happen. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14576> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16159: plugin-recomp-change fails on Windows
by GHC 09 Jan '19

09 Jan '19

#16159: plugin-recomp-change fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ Wrong exit code for plugin-recomp-change()(expected 0 , actual 2 ) Stderr ( plugin-recomp-change ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run C://GitLabRunner//builds//78d7d3f9//0//ghc//ghc//inplace//mingw//bin/ld.exe: cannot find -lHSplugin-recompilation-0.1-7bwXt6gOi6GLkV25gq6uB8 collect2.exe: error: ld returned 1 exit status `gcc.exe' failed in phase `Linker'. (Exit code: 1) make[2]: *** [Makefile:112: plugin-recomp-change] Error 1 *** unexpected failure for plugin-recomp-change(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16159> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16161: plugin-recomp-impure fails on Windows
by GHC 09 Jan '19

09 Jan '19

#16161: plugin-recomp-impure fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) Stdout ( plugin-recomp-impure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin- recomp-test.o ) Stderr ( plugin-recomp-impure ): Access violation in generated code when executing data at 0x0 Attempting to reconstruct a stack trace... Frame Code address Null address make[2]: *** [Makefile:98: plugin-recomp-impure] Error 11 *** unexpected failure for plugin-recomp-impure(normal) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16161> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16110: Explicit foralls in associated type family defaults are completely ignored?
by GHC 09 Jan '19

09 Jan '19

#16110: Explicit foralls in associated type family defaults are completely ignored? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While playing around with GHC HEAD recently, I noticed some rather bizarre behavior when trying to use explicit `forall`s with associated type family defaults. Let's pop open GHCi and recreate it: {{{ $ inplace/bin/ghc-stage2 --interactive -XTypeFamilies -XScopedTypeVariables GHCi, version 8.7.20181215: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> class C a where { type T a b; type forall b. T a b = Either a b } }}} OK, so far, so good. Now let's see what happens when I omit the `b`: {{{ λ> class C a where { type T a b; type forall. T a b = Either a b } }}} That... works? Wow, I wouldn't have expected that... But it gets even worse—I can type in utter nonsense, and GHCi will accept it: {{{ λ> class C a where { type T a b; type forall dup dup dup. T a b = Either a b } λ> class C a where { type T a b; type forall (a :: a). T a b = Either a b } λ> class C a where { type T a b; type forall (a :: k) k. T a b = Either a b } }}} How could this possibly happen? After looking at the source code to see how associated type family defaults are renamed, it becomes clear why this is the case. Here is how they are [http://git.haskell.org/ghc.git/blob/ef57272e28f5047599249ae457609a079d8aebe… renamed]: {{{#!hs rnTyFamDefltEqn cls (FamEqn { ... , feqn_bndrs = bndrs , ... }) = do { ... ; return (FamEqn { ... , feqn_bndrs = ASSERT( isNothing bndrs ) Nothing , ... }, ...) } }}} Not only are the type variable binders ignored, there's actually an `ASSERT`ion in place which assumes that there will be no binders whatsoever! (I haven't checked, but I suspect the code above will trigger a failure on that `ASSERT`ion.) My questions after seeing all of this are: * Should we be accepting explicit `forall`s in associated type family defaults at all? * If so, should we remove this strange invariant that the binders will always be `Nothing`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16115: Missing associated type instance not reported with error
by GHC 09 Jan '19

09 Jan '19

#16115: Missing associated type instance not reported with error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed [https://stackoverflow.com/questions/53987924/haskell-couldnt- match-expected-type-item-nat-with-actual-type this SO question] was caused by a warning disappearing as a result of the error it caused. {{{#!hs {-# language TypeFamilies, DataKinds #-} module NoWarning where data Nat = Zero | Succ Nat deriving Show class FromList a where type Item a :: * fromList :: [Item a] -> a instance FromList Nat where fromList [] = Zero fromList (a:as) = Succ (fromList as :: Nat) fish :: Nat fish = fromList [(),(),()] }}} If you delete `fish`, you get a nice warning: {{{ NoWarning.hs:8:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘Item’ • In the instance declaration for ‘FromList Nat’ | 8 | instance FromList Nat where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} But with `fish`, all you get is {{{ NoWarning.hs:13:18: error: • Couldn't match expected type ‘Item Nat’ with actual type ‘()’ • In the expression: () In the first argument of ‘fromList’, namely ‘[(), (), ()]’ In the expression: fromList [(), (), ()] | 13 | fish = fromList [(),(),()] | }}} That warning is the proper explanation of the problem, and it's just missing! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16115> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15578: Honour INLINE pragmas on 0-arity bindings
by GHC 08 Jan '19

08 Jan '19

#15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- Currently if we see {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} we won't inline `x`, lest we duplicate the work of `factorial 200`. But * Occasionally it's very important to inline `x`: see Trac #15519 for a real-world example. * Suppose `x` is used exactly once, not inside a lambda, thus {{{ x = blah {-# INLINE x #-} g = ...x... }}} Then, if there is ''no'' INLINE pragma, `x` will get inlined (by `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This is insane! * INLINE says "inline me at every saturated call", where "saturated" is determined by the number of arguments syntactically to the left of the "=" in the source bindings. In this case, there are no arguments to the left, so every occurrence is saturated. So it's inconsistent not to inline. Bottom line: if a 0-ary binding has an INLINE pragma, I think we should inline it at every use site * Regardless of the work duplication * Including inside lambdas Note, however, that there is a real risk that full laziness will float it right back out again. Consider again {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} After inlining we get {{{ f y = ...(factorial 200)... }}} but it's entirely possible that full laziness will do {{{ lvl23 = factorial 200 f y = l...lvl23... }}} That's a problem for another day. Presumably the reason the user wanted to inline it was to get some rule to fire, and this change gives at least some chance that will happen, and makes INLINE behave consistently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15578> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22