August 2019 - ghc-devs

seeing home module dependencies
by Sam Halliday 27 Aug '19

27 Aug '19

Hello all, I am writing a tool that uses the ghc api. It works great when I invoke it on user library code but not for test (and executable) components. Consider a very simple user project with this layout lib/Foo.hs lib/Bar.hs test/FooTest.hs test/TestUtils.hs Let's say that Foo imports from Bar and FooTest imports from TestUtils. To start my tool, which for all intents and purposes is just loading a file into ghc, I obtain the ghc flags from cabal's v2-repl (this is the hie-bios hack). I've been sure to make sure that I grab the flags associated to the relevant component. I feel that I need to justify why I'm doing it this way instead of cabal envfiles: they do not include language extensions and other things of that nature, and don't separate library/test/etc. Let's say the user has compiled the project, with tests enabled. The flags for the library might look something like ... -this-unit-id example-1.0-inplace -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db -/home/me/.cabal/store/ghc-8.6.5/package.db -package-db -/home/me/example/dist-newstyle/packagedb/ghc-8.6.5 --package-db /home/me/example/dist-newstyle/build/x86_64-linux/ghc-8.6.5/example-1.0/noopt/package.conf.inplace -package-id transformers-0.5.6.2 ... which all makes sense. If I use these flags then loading Foo.hs will fail because it cannot find Bar. These modules are needed for compilation but not listed in your .cabal file's other-modules: Bar Of course I could suppress this by ignoring warnings, but I want to see those modules.... so I have a workaround! I hacked it by changing the -this-unit-id to a -package-id and it all works great because the compiler already has the interface files for Bar in the packagedb. My tool doesn't write any object files, so I think this is safe. However, when I come to running my tool on test directories, there is no -this-unit-id from v2-repl. I know what the package-id is (from Cabal's plan.json) but it doesn't exist in my packagedb, so I can't re-use my hack. These modules are needed for compilation but not listed in your .cabal file's other-modules: TestUtils And I'm back where I started. So my question is: which flags do I need to provide to the ghc api so that a module can see the interfaces of other modules in the same component? I'm guessing my -this-unit-id hack is horrible and I shouldn't be doing that. What is the correct thing to do? -- Best regards, Sam

2 4

GHC: Policy on -O flags?
by Andreas Klebinger 27 Aug '19

27 Aug '19

Hello ghc-devs and haskell users. I'm looking for opinions on when an optimization should be enabled by default. -O is currently the base line for an optimized build. -O2 adds around 10-20% compile time for a few % (around 2% if I remember correctly) in performance for most things. The question is now if I implement a new optimization, making code R% faster but slowing down the compiler down by C% at which point should an optimization be: * Enabled by default (-O) * Enabled only at -O2 * Disabled by default Cheap always beneficial things make sense for -O Expensive optimizations which add little make sense for -O2 But where exactly is the line here? How much compile time is runtime worth? If something slows down the compiler by 1%/2%/5% and speeds up code by 0.5%/1%/2% which combinations make sense for -O, -O2? Can there even be a good policy with the -O/-O2 split? Personally I generally want code to either: * Typecheck/Run at all (-O0, -fno-code, repl) * Not blow through all my RAM when adding a few Ints while developing: -O ? * Make a reasonable tradeoff between runtime/compiletime: -O ? * Give me all you got: -O2 (-O99999) The use case for -O0 is rather clear, so is -O2. But what do people consider the use case for -O What trade offs seem acceptable to you as a user of GHC? Is it ok for -O to become slower for faster runtimes? How much slower? Should all new improvements which might slow down compilation be pushed to -O2? Or does an ideal solution add new flags? Tell me what do you think. Cheers, Andreas Klebinger

4 3

Cabal reports mismatched interface file ways dyn
by Stefan Schulze Frielinghaus 25 Aug '19

25 Aug '19

Hi all, I'm trying to compile GHC 8.6.5 using the LLVM backend and dynamic linking. My build.mk file looks as follows: include mk/flavours/quick-llvm.mk DYNAMIC_BY_DEFAULT = YES I can build a stage3 compiler. However while executing `make install` the following error shows up: "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install "/devel/ghc86/lib/ghc-8.6.5/bin/ghc" "/devel/ghc86/lib/ghc-8.6.5/bin/ghc-pkg" "/devel/ghc86/lib/ghc-8.6.5" '' '/devel/ghc86' '/devel/ghc86/lib/ghc-8.6.5' '/devel/ghc86/share/doc/ghc-8.6.5/html/libraries' NO ghc-cabal: '/devel/ghc86/lib/ghc-8.6.5/bin/ghc' exited with an error: Bad interface file: dist-install/build/GHC/CString.hi mismatched interface file ways (wanted "dyn", got "") I found similar reports [1,2] from 2013 but no solution. Any ideas how to fix this? Cheers, Stefan [1] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003488.html [2] https://mail.haskell.org/pipermail/ghc-devs/2013-December/003507.html

2 3

Tip for profiling GHC
by Matthew Pickering 24 Aug '19

24 Aug '19

Hi all, I thought for a long while that if you wanted to profile GHC itself then you had to build a profiled version of HEAD. However, this isn't true. The easiest way to profile GHC itself is to write a simple GHC API application and compile that with profiling. Normal GHC distributions come with profiling versions of the ghc library so you can use this to profile released versions of the compiler. For example, here is a simple program that Andreas created when I suggested he did this. https://gist.github.com/mpickering/e13f343f2b35b51693d15582180b1c02 You can specify whatever options you want to start the session, you might imagine compiling a package with cabal and copying the command line flags from there in order to set up a session correctly. Cheers, Matt

1 0

Typechecker plugins and BuiltInSynFamily
by Alexis King 23 Aug '19

23 Aug '19

Hello all, As I’ve been dabbling with typechecker plugins, I’ve found myself primarily using them to define new “magic” type families, and I don’t think I’m alone—Sandy Maguire recently released the magic-tyfams package for precisely that purpose. However, I can’t help but notice that GHC already has good internal support for such type families via BuiltInSynFamily and CoAxiomRule, which are mostly used to implement operations on Nats. As a plugin author, I would love to be able to use that functionality directly instead of being forced to reimplement it myself, for two big reasons: AxiomRuleCo provides significantly more safety from -dcore-lint than UnivCo, but UnivCo is currently the only way to provide evidence for plugin-solved families. The sfInteractTop and sfInteractInert fields of BuiltInSynFamily make it easy to support improvement for custom type families, which I believe would take a non-trivial amount of tricky code to get right using the current typechecker plugin API. Given the above, I started wondering if it is possible to define a BuiltInSynFamily from inside a plugin or, failing that, to modify GHC to expose that functionality to typechecker plugin authors. I am not familiar with GHC’s internals, but in my brief reading of the source code, the following two things seem like the trickiest obstacles: BuiltInSynFamily TyCons need to be injected into the initial name cache, since otherwise those names will get resolved to their ordinary, non-built-in counterparts (e.g. the ordinary open type families defined in GHC.TypeLits). Since CoAxiomRule values actually have functions inside them, they can’t be serialized into interface files. Therefore, it looks like GHC currently maintains a hardcoded list of all the known CoAxiomRules, and tcIfaceCoAxiomRule just searches for a value in that list using a well-known (i.e. not in any way namespaced!) string. I am not knowledgable enough about GHC to say how hard overcoming either of those issues would be. Point 1 seems possible to achieve by arranging for plugins to export the built-in names they want to define and propagating those to the initial name cache, but I don’t know enough about how plugins are loaded to know if that would create any possible circular dependencies (i.e. does the name cache need to already exist in order to load a plugin in the first place?). Point 2 seems harder. My gut instinct is that it could probably be overcome by somehow storing a reference to the plugin that defined the CoAxiomRule in the interface file (by, for example, storing its package-qualified module name), but I’m not immediately certain when that reference should be resolved to the actual CoAxiomRule value. It also presumably needs to complain if the necessary plugin is not actually loaded when the CoAxiomRule needs to be resolved! I’m willing to try my hand at experimenting with an implementation of this if someone can give me a couple pointers on where to start on the above two issues (assuming people don’t think it’s a bad idea to do it at all). Any advice would be appreciated! Thanks, Alexis

2 1

Linker error when adding a new source file
by Jan van Brügge 23 Aug '19

23 Aug '19

Hi, in order to clean up my code, I've moved a bunch of stuff to a new source file, `TcRowTys.hs` that works similar to `TcTypeNats.hs`. But when trying to compile a clean build of GHC, I get a linker error: ``` | Run Ghc LinkHs Stage0: _build/stage0/ghc/build/c/hschooks.o (and 1 more) => _build/stage0/bin/ghc _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.text+0x2814): error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure' _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(PrelInfo.o)(.data+0x578): error: undefined reference to 'ghc_TcRowTys_rowTyCons_closure' _build/stage0/lib/../lib/x86_64-linux-ghc-8.6.5/ghc-8.9.0.20190722/libHSghc-8.9.0.20190722.a(TcHsType.o)(.data+0xdd8): error: undefined reference to 'ghc_TcRowTys_rnilTyCon_closure' collect2: Fehler: ld gab 1 als Ende-Status zurück `gcc' failed in phase `Linker'. (Exit code: 1) ``` I had a look at the Wiki including the FAQ, but did not fine anything about that topic. Does someone know what I have to do for this to work? Cheers, Jan

5 6

Re: `StablePtr` in `ST`
by Matthew Farkas-Dyck 22 Aug '19

22 Aug '19

My colleague responded but said it was rejected from ghc-devs. Message follows: On 21/08/2019, Jon Purdy <evincarofautumn(a)gmail.com> wrote: > Our use case is unsafeCoercing a mutable reference to use as a key in an > IntMap. Our reasoning is that coercing an IORef/STRef is unsuitable because > the underlying MutVar# may move, invalidating the key (i.e., you cannot > safely coerce back if a GC has happened between insertion and reading). (If > that’s incorrect, do enlighten us!) This is a “very nice to have” for our > purposes—with the understanding that it’s wicked unsafe. ;) > > On Tue, Aug 20, 2019, 18:09 David Feuer <david.feuer(a)gmail.com> wrote: > >> You also need to avoid inspecting the StablePtr itself, which is just a >> number, to maintain purity. The whole thing is a bit weird. Why do you >> want >> this anyway? >> >> On Wed, Aug 21, 2019, 7:39 AM David Feuer <david.feuer(a)gmail.com> wrote: >> >>> So something like >>> >>> newtype StablePtr a = StablePtr (StablePtrST RealWorld a)? >>> >>> I suppose that could work with some discipline. You have to assume that >>> foreign code doesn't pick its address out of a hat and so something >>> silly, >>> but I guess you pretty much have to assume that anyway. >>> >>> On Wed, Aug 21, 2019, 5:00 AM Matthew Farkas-Dyck <strake888(a)gmail.com> >>> wrote: >>> >>>> I have been doing some work where i want `StablePtr`, but also to not >>>> be confined to `IO`. I saw the following comment in >>>> "compiler/prelude/PrimOp.hs": >>>> >>>> Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? >>>> [ADR] >>>> >>>> It has been there for 20 years. What is the answer? If it is safe i'll >>>> send the patch generalizing these operations. >>>> _______________________________________________ >>>> Glasgow-haskell-users mailing list >>>> Glasgow-haskell-users(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>>> >>> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> >

1 0

Stream Simon's report on HIW?
by Artem Pelenitsyn 22 Aug '19

22 Aug '19

Hello devs, Could someone at ICFP maybe stream Simon's report on the progress GHC made last year? I'm pretty sure many would like to check it out. Conference management streamed the main event but not the workshops. And workshops videos are such a pain: HIW 2018 is still not up on the ICFP youtube channel, although HIW 2017 and 2016 are: https://www.youtube.com/channel/UCwRL68qZFfub1Ep1EScfmBw/playlists (And Haskell 2018 playlist there has only 8 videos…) -- Kind regards, Artem

2 1

Missing library in Mac OS X instructions?
by Alejandro Serrano Mena 21 Aug '19

21 Aug '19

Hi, I tried to get GHC working from the repo in Mac OS X following the instructions in https://gitlab.haskell.org/ghc/ghc/wikis/building/preparation/mac-osx. At first I got the "error __GNU_MP_VERSION not defined" problem, for which the guide recommends to prepend "CC=clang" to "./configure" , which I did. But even then, I also had to install "gmp" using "brew install gmp". 1. Is it right that I need to install gmp using brew or did I miss some previous step? 2. If (1) is affirmative, how can I help update the docs for building in Mac OS X? Regards, Alejandro

3 3

`StablePtr` in `ST`
by Matthew Farkas-Dyck 20 Aug '19

20 Aug '19

I have been doing some work where i want `StablePtr`, but also to not be confined to `IO`. I saw the following comment in "compiler/prelude/PrimOp.hs": Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR] It has been there for 20 years. What is the answer? If it is safe i'll send the patch generalizing these operations.

2 2