- ghc-devs - Haskell.org

RE: Hadrian Transitive Dependencies
by Andrey Mokhov 27 Mar '19

27 Mar '19

Hi David, We had a discussion about this with Neil some time ago, and I think we had the following list of progressively more complex invariants for different types of build systems: · Non-cloud build systems: *all direct inputs must be declared*. If you miss a direct input dependency then a build may complete successfully but with an incorrect result. · Cloud build systems: *all direct inputs and direct outputs must be declared*. If you miss a direct output then a build may fail because the cloud will not be able to restore the corresponding output. · Cloud build systems with shallow (deferred) materialisation of build artefacts: *all transitive inputs and direct outputs must be declared*. Let’s say you’d like to download the resulting GHC binary directly, without materialising any intermediate artefacts. Then you’ll need to know GHC’s ultimate transitive inputs. I think for now we are really keen to make Hadrian a cloud build system, but whether shallow builds are valuable enough is not clear. Maybe not. Therefore, I’d say we don’t need to track transitive inputs right now. Furthermore, if we were to track all transitive inputs, we would lose the desirable early cutoff property, which prevents rebuilding after adding a comment in a file on which a lot of other files transitively depend on. Having said that, if we really access a file during compilation, then I think it is *not* a transitive dependency by definition! Any file which is accessed during a build rule is a direct dependency. > GHC is reading *.hi files that are not reported as dependencies by > `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive > dependencies! So, here I’m confused. If we read a file A when compiling a file B, then it’s by definition a direct dependency. Perhaps we just read too much? Maybe the solution is to switch to fine-grained `ghc -M` mode, to analyse import dependencies for a single module instead of doing it transitively, which I believe was discussed in a ticket some time ago? I can’t find this ticket, but I think Alp was looking into it at some point. Alp: do you remember it? Thank you for all your work on Hadrian! Cheers, Andrey From: David Eichmann [mailto:davide@well-typed.com] Sent: 27 March 2019 12:54 To: Neil Mitchell <ndmitchell(a)gmail.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; GHC developers <ghc-devs(a)haskell.org> Subject: Hadrian Transitive Dependencies Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295<https://gitlab.haskell.org/ghc/ghc/issues/16295>. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here<https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _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 mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but transitive dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

5 5

Hadrian Transitive Dependencies
by David Eichmann 27 Mar '19

27 Mar '19

Hello Shake/Hadrian contributors and the like, Recently I've been putting Hadrian's fsatrace linting feature to good use, tracking down missing dependencies in Hadrian. Ultimately, we want to use shake's cloud build / shared cache feature and ensure it works across CI builds. Unfortunately the feature isn't working smoothly with Hadrian: see #16295 <https://gitlab.haskell.org/ghc/ghc/issues/16295>. This is very desirable to improve CI build times. It is my understanding that in order to get caching to work: 1. All accessed files must declared with `need` AND 2. All created files must be declared with `produces` (or be the target of the build rule) Is my understanding correct? Or is there a weaker condition (perhaps only 2 is necessary)? If I'm correct, this amounts to fixing all fsatrace lint errors. See here <https://gitlab.haskell.org/ghc/ghc/issues/16400#note_188901> for a breakdown of lint errors / missing dependencies. A large portion of these are Haskell interface files (i.e. *.hi files). Before building a Haskell object file, dependencies are discovered via `ghc` using the `-M -include-pkg-deps` options. Unfortunately, shake's fsatrace linting complains about other *.hi files being accessed! For example when building `stage1/libraries/mtl/build/Control/Monad/RWS/Class.o` we get the following dependencies from ghc: _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : libraries/mtl/Control/Monad/RWS/Class.hs _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Prelude.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Monoid.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Strict.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/RWS/Lazy.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Identity.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Maybe.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Except.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Error.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Writer/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/State/Class.hi _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o : _build/stage1/libraries/mtl/build/Control/Monad/Reader/Class.hi And shake complains of the following missing deps: _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 mtl-2.2.2' '-package-id base-4.13.0.0' '-package-id transformers-0.5.5.0' -i -i_build/stage1/libraries/mtl/build -i_build/stage1/libraries/mtl/build/autogen -ilibraries/mtl/. -Iincludes -I_build/generated -I_build/stage1/libraries/mtl/build -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/include -I/home/david/ghc/_build/stage1/lib/x86_64-linux-ghc-8.9.20190325/rts-1.0/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage1/libraries/mtl/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/mtl/build -Wnoncanonical-monad-instances -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -c libraries/mtl/Control/Monad/RWS/Class.hs -o _build/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o -O2 -H32m -Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations -Wcompat -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -XHaskell2010 -XSafe -ghcversion-file=/home/david/MEGA/File_Dump/Well-Typed/GHC/_nosync_git/ghc/_build/generated/ghcversion.h -Wno-deprecated-flags Lint checking error - _build/HEAD_default/stage1/libraries/mtl/build/Control/Monad/RWS/Class.o - 22 values were used but not depended upon: Used: _build/HEAD_default/stage0/lib/settings Used: _build/HEAD_default/stage0/lib/platformConstants Used: _build/HEAD_default/stage0/lib/llvm-targets Used: _build/HEAD_default/stage0/lib/llvm-passes Used: _build/HEAD_default/stage0/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/package.conf.d/package.cache Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Float.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Base.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Types.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Maybe.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Writer/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Lazy.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/State/Strict.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Reader.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/List.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/transformers-0.5.5.0/Control/Monad/Trans/Cont.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/ghc-prim-0.5.3/GHC/Tuple.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/IO/Exception.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/integer-gmp-1.0.2.0/GHC/Integer/Type.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/Data/Either.hi Used: _build/HEAD_default/stage1/lib/x86_64-linux-ghc-8.9.20190325/base-4.13.0.0/GHC/Natural.hi GHC is reading *.hi files that are not reported as dependencies by `ghc -M -include-pkg-deps`. This is because they are not direct, but /transitive/ dependencies! How do we fix these lint errors (again with the goal of using shakes shared cache feature)? Some ideas: * Wildly over approximate dependencies. This may be easier to implement but cause unneeded recompilation (when a false dependency changes). Either: * `need` all dependent packages' interface files recursively as well as transitive dependencies reported by `ghc -M -include-pkg-deps` within the current package. OR * OR `need` all transitive dependencies reported by `ghc -M -include-pkg-deps`. This will likely result in fewer dependencies but requires a bit more work in recovering dependent packages' dependency graphs. * Perhaps transitive dependencies are not important for shared caching to work. Change shakes linting feature to allow (untracked?) transitive dependencies to be accessed. Feed back would be greatly appreciated. David Eichmann -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

2 1

Re: GitLab seems quite poorly
by Ryan Scott 25 Mar '19

25 Mar '19

Things still appear not to work whenever I try to push a new branch: fatal: unable to access 'https://gitlab.haskell.org/RyanGlScott/ghc.git/': The requested URL returned error: 500 Ryan S.

2 1

GitLab seems quite poorly
by Matthew Pickering 25 Mar '19

25 Mar '19

I don't know what has changed since yesterday but pushing new branches to GitLab is broken. The two most recent branches pushed to origin 404 when you click on the link. https://gitlab.haskell.org/ghc/ghc/branches https://gitlab.haskell.org/ghc/ghc/tree/wip/mp/15646 I also pushed some commits to a fork and the MR which they appear on didn't update at all. Perhaps a symptom of the same problem. Also a recent MR by Ben complains of the source branch for the MR not existing. https://gitlab.haskell.org/ghc/ghc/merge_requests/625 The summary is that GitLab seems unusable at the moment. Did you fiddle with anything recently Ben? Cheers, Matt

3 5

How to access a wiki page?
by Matthew Pickering 22 Mar '19

22 Mar '19

I made a wiki page for something I am working on but now I can't access the page anymore. The search thankfully displays the page as the first result. https://gitlab.haskell.org/search?utf8=%E2%9C%93&search=core+representation… But if I click on the page then it takes me to a UI which asks me to create a new page. This is obviously a bug in gitlab but how can I get to the page anyway? Cheers, Matt

3 3

GHC wiki fixup
by Tobias Dammers 21 Mar '19

21 Mar '19

Hello all, I am about to push a relatively large set of semi-automatic changes to the GHC wiki on GitLab (https://gitlab.haskell.org/ghc/ghc/wikis) This changeset is the result of re-running the original Trac import, with a few bugfixes applied to it, and then cherry-picking the resulting changes to the wiki onto the live wiki. Among other things, this fixes the following issues: - Mangled table layouts (GitLab's Markdown implementation does not support inline markup inside tables): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/45 - Mangled code blocks (for some reason, the original import threw away significant whitespace inside syntax-highlighted code blocks): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/37 - Some links to GHC source files pointing to gitlab.haskell.org/ghc/ghc/wikis/trac/ghc/browse/..., which is of course nonsense, now point to the correct location in the GitLab source code viewer: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/53 - Some remaining links to the old Trac install have been fixed: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/26 - Some incorrectly quoted blocks may or may not be fixed by this as well: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/46 - During the original import, we experienced HTTP errors on some pages, leading to "CONVERSION ERROR" pages being rendered instead. The re-run should have fixed these by sheer virtue of GETting those pages again now that there is less load on the Trac server. Since we used the wiki in its pre-migration state (as currently seen on https://trac.haskell.org/ghc) as the data source, we have to be careful not to accidentally undo changes made to the GitLab wiki in the meantime. I tried to mitigate this by manually picking changes, and I think I got it right, but as with all manual efforts, it is possible that I made a mistake here or there. The changeset is pretty large, and most of it is perfectly boring, so I applied quite a bit of automation to keep it manageable. So if you find anything broken on the wiki that looked OK so far, or if you see any of your edits disappear, please holler, and I'll do my best to fix it. Fortunately, this is a git repo, so nothing is permanently lost either way. And of course I apologize for any inconvenience in advance. Cheers, Tobias

1 1

Windows release quality
by Andreas Klebinger 19 Mar '19

19 Mar '19

Hello Devs, After running into #16408 today I realized there is as of yet no released bindist of the 8.6 series which I would consider stable for windows. GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 GHC 8.6.3 loops forever if compiling certain code using TH on windows. This affects some very popular hackage packages: (#16057) <https://gitlab.haskell.org/ghc/ghc/issues/16057> GHC 8.6.4 (marked stable) currently ships without profiling libraries, making profiling impossible. Being stuck with 8.4 is one thing, and if properly communicated not too bad. But it requires work to even find out about these (major) issues and to discover that 8.6 is NOT production ready for windows. We offered the broken 8.6.3 as stable for weeks without any indication that it was broken. We still serve GHC 8.6.4 as stable without any hint about the missing profiling libraries. I can't offer solutions in this case but I feel like something about the release management has to change if . Having to check the GHC bugtracker to find out if the current stable release is actually stable is just not sustainable.

3 3

Discussion: Hadrian's defaults
by Spiwack, Arnaud 19 Mar '19

19 Mar '19

I’ve been using Hadrian for a while. And I really like it. But I think, based on my experience and also the reading of the soon to be freshly reforged newcomers’ guide, that it could be greatly improved by changing the default of some of the more common options: - The -c option should be the default. One of the cool thing about Hadrian is that it needs fewer steps to completion, as it knows how to run the boot and configuration script. It’s not always what you want, but if it isn’t, it should befall to you to specify it. The most common use is the default (-c is, for instance, used in the newcomers’ guide). The reverse flag could be --no-configure. - --freeze1 should be the default. Ok, this one is harder. It’s almost always the right thing to call --freeze1 and forgetting it can have big consequences. So let’s make --freeze1 the default, add a flag --rebuild1 to force the rebuilding of stage 1. However, this requires an exception: if stage 1 was never built, we should build it, even without the flag --rebuild1. - Eventually, the new --share option should be the default as well. But maybe the paint is a bit too fresh on this. If I missed something (other defaults which should be changed, or reason to keep the defaults as they currently are) reply to this thread.

8 14

[ambiguous occurrence bug?]
by Shayne Fletcher 19 Mar '19

19 Mar '19

Sorry in advance if I should be posting questions of this kind elsewhere (please tell me if so!). Consider this two file program: ``` module T where main = undefined module Main where import T main = putStrLn "Hello world!" ``` Both 8.4.3 and 8.6.3 agree: ``` Main.hs:1:1: error: Ambiguous occurrence ‘main’ It could refer to either ‘T.main’, imported from ‘T’ at Main.hs:2:1-8 (and originally defined at Main.hs:2:1-4) or ‘Main.main’, defined at Main.hs:5:1 ``` Is this expected behavior? Does it not contradict "If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported" ( https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the latter, is this a bug? What am I missing? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

4 8

Trac -> Gitlab migration: A little issue with assignees
by Roland Senn 19 Mar '19

19 Mar '19

After some days off, I returned to my work on GHC. I looked up my tickets in Gitlab with a search on assignee=RolandSenn [1]. The system returned a list of 8 open tickets. Two of them are interesting: #14025 and #15336. Once upon a time I assigned them to me, worked on them, but unfortunately then I found them too difficult. So a couple of weeks ago I unassigned them in the good old Trac system. It seems, that these unassign operations weren't copied to Gitlab! For my 2 tickets, this is no problem, I can re-unassign them manually. However, I think, there are other tickets that were unassinged by their previous owners some time ago. Most probably some or all of them now got re-assinged during the migration to Gitlab. [1] https://gitlab.haskell.org/ghc/ghc/issues?scope=all&utf8=%E2%9C%93& state=opened&assignee_username[]=RolandSenn

2 1