February 2016 - ghc-tickets

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 04 Feb '16

04 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Before we close this, don't we still need to add the flag? Or maybe break out that part of `TcCoercibleFail` into a new test that is disabled in DEBUG mode? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7593: Unable to print exceptions of unicode identifiers
by GHC 04 Feb '16

04 Feb '16

#7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Same as #8118? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7593#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 04 Feb '16

04 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha. I was looking in the wrong place. Good explanation. I've added a comment to the test to flag this up. Now I understand, and we've documented that understanding, I'm happy to close this. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11536: Multitude of different error messages when installed package is missing a module
by GHC 04 Feb '16

04 Feb '16

#11536: Multitude of different error messages when installed package is missing a module -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8060, #9009, | #11023 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (I might clean this up later) Key points: * missing module in 'exposed-modules' field of .cabal file * package name equals some (functioning) installed package * ghc-pkg happily registers the package * errors don't show up until one tries to use the module * error messages are all different and all quite terrible Makefile to reproduce: {{{ GHCPKG=ghc-pkg #GHC=ghc-8.0.0.20160127 GHC=ghc-7.10.3 PACKAGEDB=../.cabal-sandbox/x86_64-linux-$(GHC)-packages.conf.d/ all : $(MAKE) --no-print-directory clean $(MAKE) --no-print-directory setup $(MAKE) --no-print-directory setup1 $(MAKE) --no-print-directory run1 @echo @echo $(MAKE) --no-print-directory clean $(MAKE) --no-print-directory setup $(MAKE) --no-print-directory setup2 $(MAKE) --no-print-directory run2 clean : rm -rf .cabal-sandbox cabal.sandbox.config rm -rf temp dist System *.cabal setup : mkdir temp mkdir -p System/FilePath cabal -v0 sandbox init echo "name: filepath " >> filepath.cabal echo "version: 99999.1.0 " >> filepath.cabal echo "build-type: Simple " >> filepath.cabal echo "cabal-version: >=1.10 " >> filepath.cabal echo "library " >> filepath.cabal echo " exposed-modules: " >> filepath.cabal echo " System.FilePath " >> filepath.cabal echo " System.FilePath.Posix " >> filepath.cabal echo " build-depends: base >=4.8 " >> filepath.cabal echo " default-language: Haskell2010" >> filepath.cabal echo "module System.FilePath (module System.FilePath.Posix) where" >> System/FilePath.hs echo "import System.FilePath.Posix " >> System/FilePath.hs echo "module System.FilePath.Posix where" >> System/FilePath/Posix.hs echo "takeFileName = id " >> System/FilePath/Posix.hs setup1 : @echo @echo 111111111111111111111111111111111 @echo - Remove a module from 'exposed-modules' @echo - Install package @echo - Run some tests @echo sed -i '/System.FilePath.Posix/d' filepath.cabal cabal install -v0 --with-ghc="$(GHC)" run1 : @echo @echo FAILURE MODE 1A @echo -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" -e 'import System.FilePath.Posix' @echo @echo FAILURE MODE 1B @echo -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' @echo @echo FAILURE MODE 1C @echo echo 'import System.FilePath' > temp/Foo.hs echo 'main = print $$ takeFileName "foo/bar"' >> temp/Foo.hs -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" Foo.hs -fforce-recomp setup2 : @echo @echo 222222222222222222222222222222222 @echo - Install package @echo - Remove a module from 'exposed-modules' @echo - Reinstall package @echo - Run some tests @echo cabal install -v0 --with-ghc="$(GHC)" sed -i '/System.FilePath.Posix/d' filepath.cabal cabal install -v0 --with-ghc="$(GHC)" run2 : @echo @echo FAILURE MODE 2A, same as 1A @echo -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" -e 'import System.FilePath.Posix' @echo @echo FAILURE MODE 2B @echo -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' @echo @echo FAILURE MODE 2C @echo echo 'import System.FilePath' > temp/Foo.hs echo 'main = print $$ takeFileName "foo/bar"' >> temp/Foo.hs -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" Foo.hs -fforce- recomp }}} Output (run `make`): {{{ # FAILURE MODE 1A # # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath.Posix' # # <no location info>: # Could not find module ‘System.FilePath.Posix’ # It is a member of the hidden package ‘filepath-1.4.0.0@filep_Ey7a1in9roBAE8bUFJ5R9m’. # make[1]: [run1] Error 1 (ignored) # # FAILURE MODE 1B # # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' # <interactive>: Failed to load interface for ‘System.FilePath.Posix’ # Perhaps you haven't installed the "dyn" libraries for package ‘filepath-99999.1.0’? # Use -v to see a list of the files searched for. # make[1]: [run1] Error 1 (ignored) # # FAILURE MODE 1C # # echo 'import System.FilePath' > temp/Foo.hs # echo 'main = print $ takeFileName "foo/bar"' >> temp/Foo.hs # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" Foo.hs -fforce-recomp # Failed to load interface for ‘System.FilePath.Posix’ # There are files missing in the ‘filepath-99999.1.0’ package, # try running 'ghc-pkg check'. # Use -v to see a list of the files searched for. # make[1]: [run1] Error 1 (ignored) }}} More output: {{{ # FAILURE MODE 2A, same as 1A # # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath.Posix' # # <no location info>: # Could not find module ‘System.FilePath.Posix’ # It is a member of the hidden package ‘filepath-1.4.0.0@filep_Ey7a1in9roBAE8bUFJ5R9m’. # make[1]: [run2] Error 1 (ignored) # # FAILURE MODE 2B # # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' # <interactive>: # ByteCodeLink.lookupCE # During interactive linking, GHCi couldn't find the following symbol: # filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_closure # This may be due to you not asking GHCi to load extra object files, # archives or DLLs needed by your current session. Restart GHCi, specifying # the missing library using the -L/path/to/object/dir and -lmissinglibname # flags, or simply by naming the relevant files on the GHCi command line. # Alternatively, this link failure might indicate a bug in GHCi. # If you suspect the latter, please send a bug report to: # glasgow-haskell-bugs(a)haskell.org # # make[1]: [run2] Error 1 (ignored) # # FAILURE MODE 2C # # echo 'import System.FilePath' > temp/Foo.hs # echo 'main = print $ takeFileName "foo/bar"' >> temp/Foo.hs # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" Foo.hs -fforce-recomp # [1 of 1] Compiling Main ( Foo.hs, Foo.o ) # Linking Foo ... # Foo.o: In function `sKS_info': # (.text+0xae): undefined reference to `filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_closure' # Foo.o: In function `SLc_srt': # (.data+0x88): undefined reference to `filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_closure' # collect2: error: ld returned 1 exit status # make[1]: [run2] Error 1 (ignored) }}} == Analysis * 1A: why mention a hidden (global) package, when it is hidden by a *broken* package. * 1B: misleading suggestion about "dyn" libraries * 1C: why does GHC say I should run ghc-pkg, but 'ghc-pkg check' says everything is fine? * 2A: same as 1A * 2B: scary: ByteCodeLink.lookupCE * 2C: terrible: undefined reference == Bonus With ghc-8.0.1-rc1, failure modes 1B, 1C, 2B and 2C look like this: {{{ # [1 of 1] Compiling Main ( Foo.hs, Foo.o ) # # Foo.hs:1:1: error: # Bad interface file: /home/thomas/tmp/test/filepath/.cabal- sandbox/lib/x86_64-linux- ghc-8.0.0.20160127/filepath-1.4.1.0-87VdeZTuOMDJQ40Wd1kNnE/System/FilePath.hi # Something is amiss; requested module filepath-1.4.1.0@filepath-1.4.1.0-435e90352be17e51f8e362eb5810bcd5:System.FilePath differs from name found in the interface file filep_87VdeZTuOMDJQ40Wd1kNnE:System.FilePath # make: [run2] Error 1 (ignored) }}} Related tickets: * https://github.com/haskell/cabal/issues/2982: Cabal will build and install broken library if other-modules is not complete * https://github.com/haskell/cabal/issues/3093: Missing files in package * #9009 Confusing error message when loading package with TH * #11023: ghci and ghc-pkg disagree about what's exposed * #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules #8060 was closed with: > GHC is not really in the business of checking the well-formedness of archive files installed in the package database, so there is not much GHC can do here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 03 Feb '16

03 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): No, I don't think the example from comment:14 is related. We have {{{ newtype VoidBad a = VoidBad (VoidBad (a,a)) foo5' = coerce :: (VoidBad ()) -> () }}} For `coerce :: (VoidBad ()) -> ()` to typecheck we have to know if `VoidBad ()` and `()` have the same runtime representation. So we need to find out what `VoidBad ()` really is. So we start unwrapping the newtypes of off it. What do we get when we try to unwrap the newtype off of `VoidBad ()`? {{{ VoidBad () = VoidBad ((),()) = VoidBad (((),()),((),())) = VoidBad ((((),()),((),())),(((),()),((),()))) = ... }}} It's clear that the type we apply to `VoidBad` grows exponentially and that `VoidBad ()` diverges. Before adding the ASSERT this is detected by `checkRecTc`. The reason that `checkRecTc` manages to do that in the presence of an exponentially growing argument to `VoidBad` is that `checkRecTc` only counts how many times we've applied `VoidBad`. It never looks at the exponentially growing argument. The reason why we are able to build an exponentially growing arguments with small amount of space and time has to do with sharing. When we apply `VoidBad a = VoidBad (a, a)` it is the *same* `a` that goes to the left and right component of the pair. The `a` is shared between both components. The way we apply `VoidBad a = VoidBad (a, a)` is by using the `substTy` function. We replace every `a` from the right hand side with `a` from the left hand side. But in this case we use the *same* `a`, so the size of the type grows exponentially, but the representation doesn't. The problem arises when `substTy` examines the argument we passed as `a` to look for the free vars to do the ASSERT. Since the type grows exponentially, the time to compute the free vars also grows exponentially and we don't get to the 100th iteration of unwrapping in any reasonable amount of time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10284: Create a dedicated `TypeError` exception type
by GHC 03 Feb '16

03 Feb '16

#10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check. In practice, this involves evaluating certain expressions to WHNF at run- time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type- checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`. Yes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10284> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #10345: Testsuite timeout_multiplier setting does not work as expected
by GHC 03 Feb '16

03 Feb '16

#10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the default timeout but that setting seems to be ignored and the test is killed only after the default timeout time. I added my test to `all.T` file like this: {{{ test('tc265', timeout_multiplier(0.01), compile, ['']) }}} I also tried putting timeout setting into an array (`[timeout_multiplier(0.01)]`) but with no result. Merijn reports having same problems and bypassing them by writing a test that forks itself and kills the child process after a given timeout - see [[GhcFile(libraries/base/tests/T8089.hs)]]. I am adding a note on [[wiki:Building/RunningTests/Adding#Thesetupfield]] that this field does not work currently. Once this bug is fixed we need to remove that note. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10345> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 03 Feb '16

03 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't know. I still don't understand WHY this assert is causing exponential behaviour in this example and I'm reluctant to suppress it until we know. In `typecheck/should_fail/TcCoercibleFail` I see {{{ newtype Fix f = Fix (f (Fix f)) foo6 = coerce :: Fix (Either Int) -> Fix (Either Age) foo7 = coerce :: Fix (Either Int) -> () }}} which is presumably the cause of the problem? But that looks nothing like the example in comment:8. Nor can I see where 100-level unwrappping would happen. So I'm lost. Fortunately it doesn't affect a normal stage-2 validate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled
by GHC 03 Feb '16

03 Feb '16

#11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): What are the next steps here? I can make it a flag and use it to make the test pass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11518#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11527: Pattern match translation suboptimal
by GHC 03 Feb '16

03 Feb '16

#11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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: -------------------------------------+------------------------------------- Compile the following code and look at the (sad) intermediate code: {{{ baz :: Integer -> Int -> Int baz 10 1 = 1 baz 20 1 = 2 baz 10 2 = 2 baz 20 2 = 3 baz 10 3 = 1 baz 20 3 = 2 baz 10 4 = 2 baz 20 4 = 3 baz _ _ = 0 }}} The pattern match compiler has not rearranged the clauses, and so it produces an 8 level deep nested test. Now change the type signature to {{{ baz :: Int -> Int -> Int }}} Now the pattern match compiler does its job and rearranges the clauses to make the tests 2 levels deep. The same phenomenon happens when matching string literals. For the predefined String type the right thing happens, but for some other string type (using OverloadedStrings) it doesn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11527> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5