- ghc-tickets - Haskell.org

[GHC] #16259: Hadrian does not work with a cabal v2-installed "happy"
by GHC 08 Feb '19

08 Feb '19

#16259: Hadrian does not work with a cabal v2-installed "happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: -------------------------------------+------------------------------------- I installed happy with: {{{ cabal new-install --symlink-bindir=~/Software/ghc-8.6.3/bin happy }}} where `~/Software/ghc-8.6.3/bin` is in my PATH. When I run `hadrian/build.sh -c --flavour=devel2` I get the following error: {{{ happy: /home/roland/.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9 /HappyTemplate-arrays-coerce: openFile: does not exist (No such file or directory) }}} It's correct, I don't have a file `.cabal/share/x86_64-linux- ghc-8.6.3/happy-1.19.9/HappyTemplate-arrays-coerce`. However I have a file `.cabal/store/ghc-8.6.3/happy-1.19.9-84db80555b9a8f54be2ca475bccbc751401ffbff30194c8c26d08a002a665431/share /HappyTemplate-arrays-coerce`. If I do an old-fashioned `cabal v1-install happy`, it creates the missing file `.cabal/share/x86_64-linux-ghc-8.6.3/happy-1.19.9/HappyTemplate- arrays-coerce` and Hadrian is now able to build! Hadrian should not depend on old-style cabal installs! Program versions: {{{ roland@goms:~/Projekte/ghc$ cat /etc/issue Debian GNU/Linux 9 \n \l roland@goms:~/Projekte/ghc$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 roland@goms:~/Projekte/ghc$ hadrian/build.sh --version Up to date Shake build system, version 0.17.4 roland@goms:~/Projekte/ghc$ happy --version Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. roland@goms:~/Projekte/ghc$ cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16259> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11822: Pattern match checker exceeded (2000000) iterations
by GHC 07 Feb '19

07 Feb '19

#11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- graphviz seems a nice benchmark (not too large, few dependencies) that highlights compiler performance problems on "trivial" source code (cf. https://hackage.haskell.org/package/graphviz-2999.18.0.2/docs/src /Data-GraphViz-Attributes-Complete.html#sameAttribute) Compilation of Compiling Data.GraphViz.Attributes.Colors.X11 and Data.GraphViz.Attributes.Values takes >= 1 second each, and the following happens: {{{ cabal install graphviz-2999.18.0.2 --allow-newer ... [17 of 31] Compiling Data.GraphViz.Attributes.Complete ( Data/GraphViz/Attributes/Complete.hs, dist/dist-sandbox- e6f2c124/build/Data/GraphViz/Attributes/Complete.o ) Data/GraphViz/Attributes/Complete.hs:1013:1: warning: Pattern match checker exceeded (2000000) iterations in an equation for ‘sameAttribute’. (Use -fmax-pmcheck-iterations=n to set the maximun number of iterations to n) }}} I do welcome that ghc emits this warning - I expect you want its occurence to be reported as a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11822> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #16285: Hadrian fails to run the testsuite.
by GHC 07 Feb '19

07 Feb '19

#16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | 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: -------------------------------------+------------------------------------- This is on windows with a tree based on the commit below. {{{ commit a5373c1f (master) Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Jan 16 16:34:24 2019 +0000 Fix bogus worker for newtypes }}} Output as follows. {{{ $ hadrian/build.bat -c -j8 --flavour=quick test Up to date Up to date hadrian: Encountered missing dependencies: libiserv ==8.7 shakeArgsWith 0.001s 0% Function shake 0.010s 0% Database read 0.516s 13% === Database compression 0.074s 1% With database 0.018s 0% Running rules 3.280s 84% ========================= Total 3.900s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:90:5-17: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} Regular build with hadrian works. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16285> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0
by GHC 07 Feb '19

07 Feb '19

#15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.5 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ _build/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all- packages -no-user-package-db '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id base-4.12.0.0' '-package- id ghc-prim-0.5.3' '-package-id integer-simple-0.1.1.1' '-package-id rts-1.0' -i -i_build/stage1/libraries/base/build -i_build/stage1/libraries/base/build/autogen -ilibraries/base/. -Iincludes -I_build/generated -I_build/stage1/libraries/base/build -I_build/stage1/libraries/base/build/include -Ilibraries/base/include -I/home/travis/build/snowleopard/hadrian/ghc/_build/stage1/lib/x86_64 -linux-ghc-8.5.20180617/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/base/build/autogen/cabal_macros.h -optc- std=gnu99 -optc-fno-stack-protector -optP-std=gnu99 -odir _build/stage1/libraries/base/build -hidir _build/stage1/libraries/base/build -stubdir _build/stage1/libraries/base/build -Wnoncanonical-monad-instances -optc- Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/base/GHC/Num.hs -o _build/stage1/libraries/base/build/GHC/Num.o -O0 -H64m -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -ghcversion- file=/home/travis/build/snowleopard/hadrian/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags -Wno-trustworthy-safe Exit code: 1 Stderr: ghc: panic! (the 'impossible' happened) (GHC version 8.5.20180617 for x86_64-unknown-linux): Can't use Natural in base }}} We noticed this in hadrian land (in [https://github.com/snowleopard/hadrian/issues/499 this PR] and [https://github.com/snowleopard/hadrian/issues/629] and noticed that this happens: - with 8.4.2 as the boot compiler but not 8.2.2 - with integer-simple as the integer library - only with the quickest flavour (or more generally when we build GHC.Natural with -O0) Some optimisation seems critical to making any trace of `Natural` disappear, but this seems rather fragile. The code that throws the error got introduced in fe770c211631e7b4c9b0b1e88ef9b6046c6585ef. The full build log is available [https://travis- ci.org/snowleopard/hadrian/jobs/393259151#L4209 here], anchored to where the error appears. An example of hadrian command to reproduce the problem, assuming a configured build tree: `hadrian/build.sh --flavour=quickest --integer- simple -j4`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15286> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #16082: Sort out treatment of underscores in types
by GHC 07 Feb '19

07 Feb '19

#16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 can count 4 different meanings for underscores in Haskell programs: 1. A pattern for which we don't care to write a name. (This dates back to antiquity.) Example: {{{#!hs const x _ = x }}} 2. An expression for which we want GHC to tell us what its expected type should be. (Relatively new: these are typed holes.) Example: {{{#!hs plus x y = x + _ }}} 3. A type which we want GHC to infer, by looking at the expression. (Relatively new: these are wild cards in partial type signatures.) Example: {{{#!hs plus :: forall a. Num a => a -> a -> _ plus x y = x + y }}} 4. A type which we want GHC to infer, by looking at the underscore's context. (Relatively new: these are wild cards in type applications.) Example: {{{#!hs x = const @_ @Bool 'x' -- the _ is inferred to mean Char }}} Problems arise with the advent of visible kind application (#12045): In type signatures, 3 of these meanings make sense (2, 3, and 4). In type/data family patterns, 3 of these meanings make sense (1, 2, and 4). Ideally, the user should have the opportunity to choose which meaning they want. In contrast, right now we use heuristics: in visible type/kind applications, we always use (4); otherwise, we use (1) (in patterns) or (3) (in types). This is a mess, for at least three reasons: A. Users might conceivably want different behavior than what we provide. For example, perhaps a user is writing an intricate pattern (at either term or type level) and wants to know the type (resp. kind) of the next bit of pattern. Or maybe the user wants to do this in a visible type application. Right now, there's just no way to do this. B. It causes trouble for pretty-printing. Aside from term-level patterns, all the uses of underscores above are stored identically in the AST. This means that they are printed identically. But that's strange. For example, uses (3) and (4) might have different underscores meaning different variables. Should we number the underscores? But that would be silly for usage (1). It's all a bit muddy. C. This causes awkwardness in the implementation. #12045 has to twiddle DynFlags to get its desired behavior, and that's sad. This ticket is to track resolutions to these problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16082> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16292: Wildcards in visible kind application
by GHC 07 Feb '19

07 Feb '19

#16292: Wildcards in visible kind application -------------------------------------+------------------------------------- Reporter: simonpj | 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: -------------------------------------+------------------------------------- `TcHsType.tcInferApps` contains this terrible code {{{ ; ki_arg <- addErrCtxt (funAppCtxt orig_hs_ty hs_ki_arg n) $ unsetWOptM Opt_WarnPartialTypeSignatures $ setXOptM LangExt.PartialTypeSignatures $ -- Urgh! see Note [Wildcards in visible kind application] -- ToDo: must kill this ridiculous messing with DynFlags }}} It's a knock-on from the Visible Kind Application patch -- see the Note referred to above. But it's ghastly and we must fix it. There's a [https://github.com/ghc- proposals/ghc-proposals/pull/194 GHC Proposal about this], but it's relatively ambitious. Maybe there is a shorter term thing we can do here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType
by GHC 06 Feb '19

06 Feb '19

#14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- `IOErrorType` has a "`ResourceVanished`" constructor: https://hackage.haskell.org/package/base-4.10.1.0/docs/src/GHC.IO.Exception… But there is no way to detect this for an `IOException` or `IOErrorType`. Here is some real-world code I found, where the author wants to catch "`ResourceVanished`", but resorts to catching all `IOException`: https://hackage.haskell.org/package/http-client-tls-0.3.5.1/docs/src /Network-HTTP-Client-TLS.html#convertConnection Docs for `hPutBuf` also mention the public existence of "`ResourceVanished`": https://hackage.haskell.org/package/base-4.10.1.0/docs/GHC-IO- Handle.html#v:hPutBuf Suggestion: We need to add functions: {{{#!haskell isResourceVanished :: IOError -> Bool resourceVanishedErrorType :: IOErrorType isResourceVanishedErrorType :: IOErrorType -> Bool }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #16264: Install reqlib'd libraries during CI
by GHC 06 Feb '19

06 Feb '19

#16264: Install reqlib'd libraries during CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | 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 tests requiring external libraries are hardly ever run. We likely don't want to run them in every job but we should have at least one job that makes a point of doing so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16264> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16294: Code generation corrupts writes to Addr#
by GHC 06 Feb '19

06 Feb '19

#16294: Code generation corrupts writes to Addr# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | 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: -------------------------------------+------------------------------------- This issue affects at least GHC 8.4.4 and GHC 8.6.3. Here is a somewhat minimal example: {{{#!hs {-# language BangPatterns #-} {-# language MagicHash #-} {-# language UnboxedTuples #-} {-# options_ghc -Wall -Werror -O2 #-} import Data.Primitive import Data.Void import Data.Word import Data.Monoid import GHC.IO (IO(..)) import Foreign.Storable import Numeric (showHex) import qualified GHC.Exts as E import qualified Data.Primitive as PM main :: IO () main = do arr <- compute 0xABCD 0x79 putStrLn (showString "raw packet: " . appEndo (foldMap (Endo . showHex) (E.toList arr)) $ "") compute :: Word16 -> Word8 -> IO ByteArray compute totlen prot = do buf <- PM.newPinnedByteArray 28 PM.setByteArray buf 0 28 (0 :: Word8) let !(Addr addr) = PM.mutableByteArrayContents buf !ptr = E.Ptr addr :: E.Ptr Void pokeByteOff ptr 0 (0x45 :: Word8) pokeByteOff ptr 1 (0 :: Word8) pokeByteOff ptr 2 (totlen :: Word16) pokeByteOff ptr 4 (0 :: Word16) pokeByteOff ptr 6 (0 :: Word16) pokeByteOff ptr 8 (0x40 :: Word8) pokeByteOff ptr 9 (prot :: Word8) touchMutableByteArray buf PM.unsafeFreezeByteArray buf touchMutableByteArray :: MutableByteArray E.RealWorld -> IO () touchMutableByteArray (MutableByteArray x) = touchMutableByteArray# x touchMutableByteArray# :: E.MutableByteArray# E.RealWorld -> IO () touchMutableByteArray# x = IO $ \s -> case E.touch# x s of s' -> (# s', () #) }}} For those curious about the particular interleaving of 8-bit and 16-bit writes, this was adapted from code that fills out an `iphdr` for use with raw sockets. The output will be dependent on your platform's endianness. On my little-endian architecture, I get: {{{ raw packet: 450cdab00004079000000000000000000 }}} As we expect, the `abcd` from the source gets flipped to `cdab` because of the little endian architecture this ran on. However, it starts in an unusual place. It's not even byte-aligned. Something, possible a cmm optimization or a codegen optimization, makes the `writeWord16OffAddr#` end up straddling three bytes. Someone will probably want to write a more minimal example that eliminates the use of the `primitive` library. Sorry to be the bearer of bad news :( -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16294> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16106: Remove PowerPC OS X (Darwin) support
by GHC 06 Feb '19

06 Feb '19

#16106: Remove PowerPC OS X (Darwin) support --------------------------------+--------------------------------- Reporter: trommler | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: MacOS X Architecture: powerpc | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+--------------------------------- OS X for PowerPC is not supported by Apple anymore. GHC's support has most likely bit-rotted and we have no test machine. Let's go ahead and remove support for PowerPC Darwin. The following components contain PowerPC Darwin specific code: * native code generator * RTS * driver * build system -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16106> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7