April 2018 - ghc-devs

Re: Plan for GHC 8.6.1
by Ryan Scott 20 Apr '18

20 Apr '18

I have one major feature planned: -XDerivingVia. I haven't made a patch yet, since the idea itself is still technically going through the proposal process at [1]. But the feedback seems pretty positive, so I think I'll submit it to the committee next week for final consideration. There is an implementation that's 99% already at [2], so there shouldn't be much of a delay in getting it to Phabricator once the committee gives the go-ahead. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/120 [2] https://github.com/RyanGlScott/ghc/tree/deriving-via-8.5

2 1

Re: Accessing 'Annotations' of modules in external packages
by Christiaan Baaij 20 Apr '18

20 Apr '18

ghc-devs is probably a better location for GHC API questions. Anyhow, you might want to look at some code in the Clash compiler: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775… We use that to find the following annotations in compiled packages: http://hackage.haskell.org/package/clash-prelude-0.99/docs/Clash-Annotation… Anyhow, the gist of: https://github.com/clash-lang/clash-compiler/blob/6ec3ca426bfaaaddcd3692775… is: * You need a `Module` to start with (you can e.g. get one from a `CoreBndr`) * You need to load the interface file (.hi) for that module. * One you have the contents of the interface file, you can do `TcIface.tcIfaceAnnotations (GHC.mi_anns iface)` to get something of the `Annotation` type. Hope that helps. -- Christiaan On 18 April 2018 at 23:01, Ranjit Jhala <jhala(a)cs.ucsd.edu> wrote: > > Hi all, > > I'm looking for some help using the GHC API to > > access the 'Annotations' (created using the 'ANN' > > mechanism) within modules of *external* packages > > i.e. non-home modules.Currently I'm using > > hscEPS :: HscEnv -> IO ExternalPackageState > > and then using the field > > eps_PIT :: !PackageIfaceTable > > and from there, accessing the > > mi_anns :: [IfaceAnnotation] > > field of the > > data ModIface > > stored in the PackageIfaceTable but this ends in an unfortunate: > > ``` > panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-apple-darwin): > No mi_anns in PIT > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > ``` > > Perhaps this is because, as the documentation for `mi_anns` says: > > Annotations NOT STRICT! we read this field lazily from the interface > file > > but I am not sure how to proceed at this point? Do I need a _different_ > HscEnv? Or perhaps I need to set up/initialize the HscEnv separately? > > Any pointers would be most welcome! > > Thanks! > > Ranjit. > > > > > > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > >

1 0

Re: GHC extensions
by Ryan Scott 19 Apr '18

19 Apr '18

Hi Peter, > What does exactly happen if an extension is needed for a certain language element, but it is not present? Generally, these manifest as runtime checks of the form (xopt LangExt.TheLanguageExtensionName dflags). For an example, see [1], where GHC checks if the TypeFamilyDependencies extension is enabled, and if not, subsequently throws an error. > Does the type checker still continue its business after encountering such an error; or does it stop, and dump its the error messages? It depends. Sometimes, GHC uses the addErrTc function to add an error but not cause an outright failure, continuing until there is a fatal error. The failWithTc function, on the other hand, adds an error and causes GHC to exit, reporting all errors it's collected up to that point. (The example in [1] does this.) Ryan S. ----- [1] http://git.haskell.org/ghc.git/blob/5d76846405240c051b00cddcda9d8d02c880968…

1 0

GHC extensions
by Peter Podlovics 18 Apr '18

18 Apr '18

Hi everyone, I have a question about handling missing extension errors in modules. What does exactly happen if an extension is needed for a certain language element, but it is not present? I couldn't find the code segment where error messages are handled, and since there are no immediate program interrupts at their creation site (e.g.: at TcValidity.checkValidType), I can only assume that there is some tricky laziness in action here. Does the type checker still continue its business after encountering such an error; or does it stop, and dump its the error messages? Thanks in advance, Peter

1 0

Windows: cannot create here-doc
by Simon Peyton Jones 18 Apr '18

18 Apr '18

Tamar I think your suggestion of adding # Set user-defined locale export LANG=$(locale -uU) worked. No more perl messages. Still having various troubles... Here's the current one (log below). I'm getting lots of ./configure: line 2534: cannot create temp file for here-document: Device or resource busy And finally checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables I have environment variables TEMP and TMP set. Oddly, re-running configure gets further - see second log below. All deeply strange. Thanks Simon Log 1: first run of 'sh validate -fast' Creating libraries/array/ghc.mk Creating libraries/base/ghc.mk Creating libraries/binary/ghc.mk Creating libraries/bytestring/ghc.mk Creating libraries/Cabal/Cabal/ghc.mk Creating libraries/containers/ghc.mk Creating libraries/deepseq/ghc.mk Creating libraries/directory/ghc.mk Creating libraries/dph/dph-base/ghc.mk Creating libraries/dph/dph-prim-interface/ghc.mk Creating libraries/dph/dph-prim-seq/ghc.mk Creating libraries/dph/dph-prim-par/ghc.mk Creating libraries/dph/dph-lifted-base/ghc.mk Creating libraries/dph/dph-lifted-boxed/ghc.mk Creating libraries/dph/dph-lifted-copy/ghc.mk Creating libraries/dph/dph-lifted-vseg/ghc.mk Creating libraries/filepath/ghc.mk Creating libraries/ghc-boot/ghc.mk Creating libraries/ghc-boot-th/ghc.mk Creating libraries/ghc-compact/ghc.mk Creating libraries/ghc-prim/ghc.mk Creating libraries/ghci/ghc.mk Creating libraries/haskeline/ghc.mk Creating libraries/hpc/ghc.mk Creating libraries/integer-gmp/ghc.mk Creating libraries/integer-simple/ghc.mk Creating libraries/mtl/ghc.mk Creating libraries/parallel/ghc.mk Creating libraries/parsec/ghc.mk Creating libraries/pretty/ghc.mk Creating libraries/primitive/ghc.mk Creating libraries/process/ghc.mk Creating libraries/random/ghc.mk Creating libraries/stm/ghc.mk Creating libraries/template-haskell/ghc.mk Creating libraries/terminfo/ghc.mk Creating libraries/text/ghc.mk Creating libraries/time/ghc.mk Creating libraries/transformers/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/vector/ghc.mk Creating libraries/Win32/ghc.mk Creating libraries/xhtml/ghc.mk Booting . Booting libraries/base/ Booting libraries/directory/ Booting libraries/ghc-prim/ Booting libraries/integer-gmp/ Booting libraries/process/ Booting libraries/terminfo/ Booting libraries/time/ Booting libraries/unix/ ./configure: line 2534: cannot create temp file for here-document: Device or resource busy checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-pc-mingw64 checking host system type... x86_64-pc-mingw64 checking target system type... x86_64-pc-mingw64 Build platform inferred as: x86_64-unknown-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... configure: Extracting Windows toolchain from archives (may take a while)... configure: In-tree MingW-w64 tree created checking for genlib... no configure: Making in-tree perl tree configure: In-tree perl tree created checking for -windres... no checking for windres... windres checking for -dllwrap... no checking for dllwrap... dllwrap checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe ./configure: line 5421: cannot create temp file for here-document: Device or resource busy checking whether the C compiler works... no sed: can't read conftest.c: No such file or directory configure: error: in `/c/code/HEAD': configure: error: C compiler cannot create executables See `config.log' for more details $ Log 2: run of "./configure" $ ./configure ./configure: line 2542: cannot create temp file for here-document: Device or resource busy configure: loading site script /usr/local/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.5.20180402 checking for GHC Git commit id... inferred 6ae53e4f4af1a156a875e05a2c12efeaa2e7d902 checking for ghc... /c/fp/HP-8.2.2/bin/ghc checking version of ghc... 8.2.2 GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... C:/code/HEAD configure: Checking for Windows toolchain tarballs... checking for genlib... no checking for -windres... no checking for -dllwrap... no checking for -objdump... C:/code/HEAD/inplace/mingw/bin/objdump.exe checking whether the C compiler works... yes checking for C compiler default output file name... a.exe checking for suffix of executables... .exe checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether C:/code/HEAD/inplace/mingw/bin/gcc.exe accepts -g... ./configure: line 5717: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C89... ./configure: line 5793: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory sed: can't read conftest.c: No such file or directory unsupported checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking minix/config.h usability... no checking minix/config.h presence... ./configure: line 1796: cannot create temp file for here-document: Device or resource busy sed: can't read conftest.c: No such file or directory no checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking how to run the C preprocessor... C:/code/HEAD/inplace/mingw/bin/gcc.exe -E checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/fp/HP-8.2.2/lib/../mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for C:/code/HEAD/inplace/mingw/bin/gcc.exe option to accept ISO C99... none needed checking for -ld... C:/code/HEAD/inplace/mingw/bin/ld.exe checking whether ld is GNU ld... YES checking whether ld understands --build-id... yes checking whether ld understands -no_compact_unwind... yes checking whether ld understands -filelist... no checking for -objdump... (cached) C:/code/HEAD/inplace/mingw/bin/objdump.exe checking for ranlib... C:/code/HEAD/inplace/mingw/bin/ranlib.exe checking for -strip... no checking for libtool... /usr/bin/libtool checking for -clang... no checking for llc-5.0... no checking for llc... no checking for opt-5.0... no checking for opt... no configure: Creating links for in-tree file handling routines. 'utils/lndir/fs.c' => 'utils/fs/fs.c' 'utils/lndir/fs.h' => 'utils/fs/fs.h' 'utils/unlit/fs.c' => 'utils/fs/fs.c' 'utils/unlit/fs.h' => 'utils/fs/fs.h' 'rts/fs.c' => 'utils/fs/fs.c' 'rts/fs.h' => 'utils/fs/fs.h' 'libraries/base/include/fs.h' => 'utils/fs/fs.h' 'libraries/base/cbits/fs.c' => 'utils/fs/fs.c' configure: Routines in place. Packages can now be build normally. checking whether #! works in shell scripts... yes checking version of gcc... 7.2.0 checking whether GCC supports -no-pie... yes checking for extra options to pass gcc when compiling via C... -fwrapv -fno-builtin checking whether C compiler is clang... no checking whether C compiler has an LLVM back end... no checking Setting up CFLAGS, LDFLAGS, IGNORE_LINKER_LD_FLAGS and CPPFLAGS... done checking Setting up CONF_CC_OPTS_STAGE0, CONF_GCC_LINKER_OPTS_STAGE0, CONF_LD_LINKER_OPTS_STAGE0 and CONF_CPP_OPTS_STAGE0... done checking Setting up CONF_CC_OPTS_STAGE1, CONF_GCC_LINKER_OPTS_STAGE1, CONF_LD_LINKER_OPTS_STAGE1 and CONF_CPP_OPTS_STAGE1... done checking Setting up CONF_CC_OPTS_STAGE2, CONF_GCC_LINKER_OPTS_STAGE2, CONF_LD_LINKER_OPTS_STAGE2 and CONF_CPP_OPTS_STAGE2... done checking for .subsections_via_symbols... no checking whether your assembler supports .ident directive... yes checking for GNU non-executable stack support... no checking for a working context diff... diff -U 1 checking for a BSD-compatible install... /usr/bin/install -c checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe is GNU ar... yes checking for ar arguments... q checking whether C:/code/HEAD/inplace/mingw/bin/ar.exe supports @file... yes

2 2

Re: Memory usage exploding for complex pattern matching
by Victor Miraldo (UU) 17 Apr '18

17 Apr '18

Hello all, Following up on this, I have created a trac ticket https://ghc.haskell.org/trac/ghc/ticket/14987#no2 as suggested a couple days ago. In order to try to hack my way through and get my library to compile, I tried progressively adding more and more pattern synonyms to try to avoid exhaustiveness checking,yet, something really surprising happened. Big examples have type errors where small ones don't! I tried documenting the process in a repository: https://github.com/VictorCMiraldo/ghc-14987-repro-pipeline Unfortunately, however, I couldn't get the self contained repros in the repository above to throw type errors. Hence, I'm attaching my full code. Compiling the file src/Generics/MRSOP/Examples/GoAST.hs gives type errors, even though it is being generated by the same template haskell code as the other files inside Examples, all of which compile just fine. To trigger the error, just run `stack build`. It really is a shame that the combination of pattern synonyms that shows the best memory performance crashes completely on bigger examples. Any suggestions are appreciated, thank you very much! Have a great weekend! Cheers, Victor On Fri, Mar 30, 2018 at 5:23 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: > "Victor Miraldo (UU)" <v.cacciarimiraldo(a)uu.nl> writes: > >> Hello, >> >>>>>> I have just tried compiling my code with 8.4.2 and using >>>>>> -fmax-pmcheck-iterations=0, >>>>>> I gave GHC 12GB of ram and it still ran out (through `ulimit >>>>>> -v$((1024*1024*12))`). >>>>>> >>>>> Hmmm, I'm a bit confused. Why are our results so different? How >>>>> precisely are you invoking GHC? >>>> >>>> Here I meant my whole code, not just the repro. I could have been more clear. >>>> Nevertheless, I'm calling it through stack: >>>> >>> I'll admit that I am a bit lost; Minimal.hs compiles for me with a >>> maximum residency of ~3.5 GBytes with both -O1 and the PM check enabled >>> using GHC 8.4.1. Is this not the repro you are referring to? >> >> I get the same behavior as you for Minimal.hs. >> >> The "my code" above referred to the whole library that I'm developping. >> In fact, the Minimal.hs file contains a distilled version of that library with >> a template haskell splice that we are trying to use in one of our >> fully fledged examples. >> > Okay, I just wanted to be certain we were indeed seeing the same > behavior. Indeed 3.5 GB is quite a lot of memory for a 700 LoC program, > even one with the deep matches seen in Minimal.hs. > > Cheers, > > - Ben >

2 1

CI builds failing
by David Feuer 16 Apr '18

16 Apr '18

It looks like the recent differential builds are all failing like this: compiler/main/DynamicLoading.hs:79:19: warning: [-Wunused-matches] Defined but not used: ‘hsc_env’ | 79 | initializePlugins hsc_env df | ^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (r_apc3 :: TYPE rep_apc2) rep_apc2 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [compiler/stage1/build/PrelRules.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Oddly, I don't see a commit to master failing like this. What's going on? David

3 3

Question about TypeInType
by Iavor Diatchki 16 Apr '18

16 Apr '18

Hello, I was experimenting with TypeInType and run into a problem, that can be reduced to the following example. Does anyone have any insight on what causes the error, in particular why is `IxKind` not being reduced? -Iavor {-# Language TypeInType, TypeFamilies #-} module Help where import Data.Kind type family IxKind (m :: Type) :: Type type family Value (m :: Type) :: IxKind m -> Type data T (k :: Type) (f :: k -> Type) type instance IxKind (T k f) = k type instance Value (T k f) = f {- [1 of 1] Compiling Help ( Desktop/Help.hs, interpreted ) Desktop/Help.hs:13:31: error: • Expected kind ‘IxKind (T k f) -> *’, but ‘f’ has kind ‘k -> *’ • In the type ‘f’ In the type instance declaration for ‘Value’ | 13 | type instance Value (T k f) = f | ^ Failed, no modules loaded. -}

3 3

RE: Nested Implications
by Simon Peyton Jones 16 Apr '18

16 Apr '18

Mathias I suspect substImplication was removed simply because it was never called, but I’m not certain. The entire cloning and substitution business is very heavyweight. Here’s an alternative idea: * Gather ‘fuvs’, the set of all free unification variables of the constraint you are about to solve. * Solve the constraint * For each variable in ‘fuvs’, set its IORef to Flexi; that is, simply undo any unification that has taken place. That seems simple, very non-invasive, and robust. Simon From: Matthías Páll Gissurarson <pallm(a)student.chalmers.se> Sent: 10 April 2018 00:57 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Nested Implications Greetings Simon, I've been working on implementing the valid substitutions for typed holes in terms of nested implications, and I think I've worked out how to do it. But one thing bothers me. To use the implications that are passed along with the ReportErrCtxt, I have to clone the type variables within, to avoid having side-effects that could impact later searches. I clone the type variables and create a substitution from the old variables to the new, which I'd like to apply to the implication. When I was looking around for how to do that, I came across this code in GHC 7.6.3 https://downloads.haskell.org/~ghc/7.6-latest/docs/html/libraries/ghc-7.6.3…<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.ha…> The `substImplication` function does precisely what I want, i.e. applies a substitution to an implication. However, that code is no longer present in GHC 8.5! The git history doesn't go far enough back for me to find an explanation, so I wanted to ask: why was this function removed? Is there something I should be wary of if I re-implement it? Please correct me if my approach is all wrong, I'd like to hear what you had in mind. -- - Matthías Páll Gissurarson

1 0

GHC Core / STG to supercombinators
by Csaba Hruska 16 Apr '18

16 Apr '18

Hello, I'd like to use GHC as a haskell frontend in a project. I wonder what is the easiest way to compile Haskell to supercombinators (top level functions) using GHC as a library. Is it possible to use the simplifier to transform the parsed Haskell source to supercombinators? i.e. to do - eta expansion - closure conversion - lambda lifting Regarding the eta expansion and lambda lifting it seems (according the comments in simplifier code) it does not guarantee to make these transformations in every case. If GHC could transform the Core representation to supercombinators, which transformation should I use from *CoreToDo*? https://github.com/ghc/ghc/blob/master/compiler/simplCore/CoreMonad.hs#L107- L135 I'd like to use GHC as a frontend for my custom code generator which can handle (lazy) top level functions only. Is it better to use GHC as a library or is it better to write a compiler plugin to capture the core representation. I do not want to optimize the Core at all neither want to use other parts of GHC's backend (i.e. codegen). Ideally GHC would typecheck and transform everything to top level function and my system would do the rest. Do you know what would be the easiest way to do this? (i.e. via *CoreToDo* or custom calls for the simplifying functions) Or would it be simpler to generate top level (lazy) functions from STG? Regards, Csaba Hruska

3 2