- ghc-devs - Haskell.org

GHC 8.8.2 + cabal-install 3.0.0 finally working on SmartOS x64 20200117 (yet GHC 8.6.5 left less usable)
by Compl Yue 14 Feb '20

14 Feb '20

Folks, I'm glad to report that I finally get GHC 8.8.2 with cabal-install 3.0.0.0 working on SmartOS x64, you can checkout detailed steps and all the patches applied at https://gitlab.haskell.org/complyue/smart-ghc8 The only pity so far, is that the built GHC 8.6.5 has its `ghci` not working with a strange iconv error, and failing building one of my Haskell applications. I myself am going to use 8.8.2 where possible from now on. But given not all great libs have been updated being 8.8 compatible, I feel it still worth some further effort to get 8.6.5 working. And regarding stack, as it's focused on managing binary distributions of GHC (build-from-src not working very well per my experience), it'll need a trusted binary repository for stack to work with on SmartOS. A private http server hosting the bindists should be straight forward, but I'm not interested to host a publicly available binary repository with those bindist tarballs digitally signed (or there're security concerns). If anyone is interested, I'd like to help as far as I can. I would particular like to see Nix be ported to SmartOS/Illumos/Solaris, so I could contribute to nixpkgs instead, which should save more asses in tool dependency resolution, but seems that's not an option in near future. I'm thankful to folks at #ghc and #smartos who helped me so much in this journey. Especially bgamari, without his hints and bleeding edge patches this won't be possible at all. And thanks to geekosaur for his professional insights into the linker situation on SmartOS, quick and precise identification of the problem from the error messages so confusing to me. https://www.mail-archive.com/smartos-discuss@lists.smartos.org/msg05016.html provided the information to get me started at all, and thanks to Jonathan Perkin for confirming the bootstrapping path being a viable route in the first place. Cheers, Compl Yue

2 2

DataCon tag value convention
by Csaba Hruska 12 Feb '20

12 Feb '20

Hello, In theory could GHC codegen work if every data constructor in the whole program have a globally unique tag value instead of starting from 1 for each algebraic data type? Would this break any GHC design decision? Regards, Csaba

3 4

ADT arguments and Levity Polymorphism
by Csaba Hruska 10 Feb '20

10 Feb '20

Hello, Are heap stored ADT's arguments always levity (representation) monomorphic? *(I guess they are otherwise the info table would not be a constant value instead it would be a function that calculates the representation depending on some runtime value.)* Regards, Csaba Hruska

2 2

Adding extra C compiler arguments when building with hadrian?
by Ömer Sinan Ağacan 10 Feb '20

10 Feb '20

In make build system I can add extra C compiler arguments to any flavor using something like BuildFlavour = ... ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcRtsHcOpts += -O0 -g3 How do I do the same in hadrian when defining a flavor? Thanks, Ömer

3 4

Request for two new MR-labels: "review-needed" and "changes-required"
by Andreas Klebinger 10 Feb '20

10 Feb '20

Hello devs, Recently in a MR discussion the topic came up of contributors being frustrated about lack of reviews. As a contributor and as a reviewer the lack of tools to find MR's in need of attention also frustrated me often. I suggest two new MR labels: Label: "review-needed": If a contributor has an MR which he considers to be blocked on (lack of) review he can assign the label to clearly signal this. Label: "changes-required": This is the inverse - if a reviewer looked at a patch and it's clear that the patch needs more work from the contributor this label can signal this. What are the benefits? * As a reviewer I can look for MR's tagged with review-needed and can be sure that time spent reviewing is not wasted. * As a contributor I can mark a patch as changes-required if I think my patch is ready to land, or if I need input on the design. * Core maintainers can more easily identify patches which have been stalled for a long time, making their review a priority. The obvious downside is more labels. Cheers Andreas

3 2

reporting my progress in building ghc 8 on latest smartos
by Compl Yue 10 Feb '20

10 Feb '20

freenode server seems in trouble for this while, and I'd like to take this chance to report my progress to the mailing lists. I'm thankful to folks at #ghc and #smartos who helped me so much in this journey, especially bgamari, without his hints and bleeding edge patches this won't be possible at all. And https://www.mail-archive.com/smartos-discuss@lists.smartos.org/msg05016.html provided the information to get me started at all. So far what's done: :: installed 7.6.3 -> booted 7.10.3 -> booted 8.2.2 -> booted 8.4.4 -> booted 8.6.5 -> booted 8.8.2 Notable issues as I remembered: (I don't remember the details clearly, anyway am to redo it all over again to have everything logged for reprod) * `gmake -i` is used to build 8.2.2 to workaround the stage1 ghc crash after target file generated * 8.6.5's ghci won't start | [root@hswander /build/ghc8]# /opt/local/ghc8.6.5/bin/ghci||| ||| GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help||| ||| ghc: loadArchive: Not an archive: `/usr/lib/iconv'||| ||| ghc: panic! (the 'impossible' happened)||| ||| (GHC version 8.6.5 for x86_64-unknown-solaris2):||| ||| loadArchive "/usr/lib/iconv": failed||| ||| Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug||| * worth to mention that I needed to put "SplitSections=YES" into mk/build.mk even for 8.8.2 or it'll fail, might be unexpected. And dtrace compiler on latest SmartOS don't support C++ style line comment, so I applied this patch to 8.8.2 https://gitlab.haskell.org/snippets/1549 Meanwhile I'm starting a fresh smartos vm to repeat (and log) all steps to make sure others and future me can follow such a reproducible procedure to build later versions. Cheers, Compl

2 2

Missing symbols in ghc-stage2 executable
by Ömer Sinan Ağacan 10 Feb '20

10 Feb '20

Does anyone know why I get so little symbols in stage 2 compiler compared to programs built with the same stage 2 compiler? This is the build.mk I'm using BuildFlavour = quick ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcRtsHcOpts += -O0 -g3 GhcStage2HcOpts += -debug -g5 GhcLibHcOpts += -g5 GhcThreaded = NO BUILD_PROF_LIBS = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO STRIP_CMD = : Symbols in stage 2 compiler built with this build.mk: $ nm /home/omer/haskell/ghc/inplace/lib/bin/ghc-stage2 | wc -l 9202 If I build `main = return ()` with the same compiler: $ cat test.hs main = return () $ /home/omer/haskell/ghc/inplace/bin/ghc-stage2 -g5 -O0 test -fforce-recomp [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ nm test | wc -l 35266 So it seems like a lot of symbols in the libraries are missing in the stage 2 executable. I tried setting `DYNAMIC_GHC_PROGRAMS = NO` but I got even less number of symbols in the stage 2 compiler. I also confirmed this using a debugger program I wrote which can find info table labels of objects in the heap when I run it on `test.hs` above but not when I run it on the stage 2 executable. Ömer

1 1

GHC Test Failures
by Gert-Jan Bottu 10 Feb '20

10 Feb '20

Hi all, It's my first time working on ghc (currently implementing proposal 99 [1]), and I have two issues with the ghc tests that I can't seem to figure out: - Running hadrian/build.sh test -j on my machine causes 78 tests to fail with the following error: collect2: error: ld returned 1 exit status `cc' failed in phase `Linker'. (Exit code: 1) This happens in both my wip branch and on master, both in devel2 and quickest flavour. I've tried hadrian/build.sh clean and even recloned the repo, but the errors are quite persistent. Running the hadrian tests on CI works fine though. - On CI [2], all tests under build pass. Under full-build however, the hadrian tests pass, but a single make test fails : Wrong exit code for haddockHtmlTest()(expected 0 , actual 2 ) Stdout ( haddockHtmlTest ): [1 of 6] Compiling Test.Haddock.Process ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/haddock-test/src/Test/Haddock/Process.hs, Test/Haddock/Process.o ) [2 of 6] Compiling Test.Haddock.Utils ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/haddock-test/src/Test/Haddock/Utils.hs, Test/Haddock/Utils.o ) [3 of 6] Compiling Test.Haddock.Config ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/haddock-test/src/Test/Haddock/Config.hs, Test/Haddock/Config.o ) [4 of 6] Compiling Test.Haddock ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/haddock-test/src/Test/Haddock.hs, Test/Haddock.o ) [5 of 6] Compiling Test.Haddock.Xhtml ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/haddock-test/src/Test/Haddock/Xhtml.hs, Test/Haddock/Xhtml.o ) [6 of 6] Compiling Main ( /builds/Gertjan423/ghc/testsuite/../utils/haddock/html-test/Main.hs, Main.o ) Linking html-test ... Haddock version 2.22.0, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 8.11.0.20200207 Generating documentation... Failed to run Haddock on test package '' Haddock output is at 'haddock-out.log'. This file can be set with `--haddock-stdout`. Testing output files... Some tests crashed. Makefile:19: recipe for target 'htmlTest' failed Stderr ( haddockHtmlTest ): Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.2.0.0 supports 'ghc' version < 8.10): /builds/Gertjan423/ghc/inplace/bin/ghc-stage2 is version 8.11.0.20200207 make[2]: *** [htmlTest] Error 1 *** unexpected failure for haddockHtmlTest(normal) I did make some small Haddock changes, so I did most likely cause this behavior. I just find it strange that this error does not happen on my machine, and even on CI only occurs in the make tests (and only under linux, not under windows). Any tips regarding what could cause this, and how to tackle debugging this would be greatly appreciated :) Cheers, Gert-Jan [1] : https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0099-e… [2] : https://gitlab.haskell.org/Gertjan423/ghc/pipelines/15509

1 0

Free dictionary variables in elaborated core expressions
by Yiyun Liu 03 Feb '20

03 Feb '20

Hi ghc-devs, About 10 days ago, I made a thread about defining a function called elaborateExpr which turns a string into a core expression <https://github.com/yiyunliu/ghc-elaboration-test/blob/8f362ad92dc6601b4cb7e…> within an interactive context. Now here's an unexpected behavior which I'm not sure how to deal with. Given the expression: (\x -> x + 1) :: Int -> Int I expect to get something that looks like: \ (x :: Int) -> + @ Int GHC.Num.$fNumInt x (GHC.Types.I# 1#) where GHC.Num.$fNumInt is the exported dictionary. What I actually get is something like this: \ (x :: Int) -> + @ Int $dNum_someuniqueid x (GHC.Types.I# 1#) where $dNum_someuniqueid is a free dictionary variable within the expression. I was confused by the occurrence of the free variable $dNum at first, but after running the command: "ghc -ddump-ds-preopt somefile.hs" to dump the core bindings, I found that the dictionary variables like $dNum_ are actually local variables defined at the top-level. My objective is to inline those top-level dictionary definitions into the core expression using let bindings, but it seems tricky since I'm doing everything within an interactive context. Calling getBindings <https://hackage.haskell.org/package/ghc-8.6.5/docs/GHC.html#v:getBindings> only gives me the expression I elaborated, but the dictionary is no where to be found. Interestingly, when I turn on flags such as "DeferTypedHoles" or "DeferOutOfScopeVariables", all the dictionaries are defined locally in let bindings. However, I can't replicate that behavior even with the flags on in the interactive context. How do I find the dictionaries? Thanks, - Yiyun

2 2

Allowing Windows CI to fail
by Ben Gamari 03 Feb '20

03 Feb '20

Hi everyone, After multiple weeks of effort struggling to get Windows CI into a stable condition I'm sorry to say that we're going to need to revert to allowing it to fail for a bit longer. The status quo is essentially holding up the entire merge queue and we still seem quite far from resolving the issues. I have summarised the current state-of-play in #17777. In short, the gcc toolchain likely can't be used reliably on Windows due to its ubiquitous use of `exec`, which cannot be reliably implemented on Windows. Switching to LLVM as our native toolchain was my (initially promising) last-ditch attempt at avoiding this issue but sadly this looks to be a long road. My current attempt is stuck on an inscrutable loader error. For the short-term, I am afraid I have run out of time for this effort. My current plan is to merge what I can from my wip/windows-ci branch but again enable the Windows CI jobs' allow_failure flag so that its unreliable nature doesn't hold up otherwise-passing CI jobs. While it's unfortunately that we still lack reliable CI on Windows, I think the effords of the last few weeks were quite worthwhile. We now have: * A much better understanding of the issues affecting us on Windows * Significantly better documentation and automation for producing our mingw toolchain artifacts * better scripting for setting up Windows CI runners * fixed several bugs in the ghc-jailbreak library used to work around the Windows MAX_PATH limitation Many thanks to Tamar Christina for his many hours of patient help. Without him, GHC's Windows support would be in significantly worse shape than it is. Users of GHC should note that the CI issues we are struggling with *do not* affect compiled code. These bugs manifest only as (rare) failed compilations (particularly when building GHC itself); however, once compilation succeeds the program that results is correct and reliable. Cheers, - Ben

2 2