- ghc-devs - Haskell.org

Re: GitLab conventions
by Ryan Scott 02 Apr '19

02 Apr '19

Thanks for writing these up! These will be handy references that I'm sure I'll come back to many times. Question: once I've marked my MR as "backport-needed" (and it is merged into master), whose responsibility is it to ensure that it gets merged into the latest release branch (e.g., ghc-8.8)? It it the responsibility of the person who made the MR originally, or is there a process in place for collecting these backport-needed patches into batches and merging them? Ryan S.

2 5

Gitlab email
by Simon Peyton Jones 02 Apr '19

02 Apr '19

Ben I get a lot of email from GitLab. But I miss some that I expect. In particular I've just posted a Discussion comment on https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that comment come to me by email. But it didn't! It's as if Gitlab sends you everyone else's comments, but not your own. Is that right? Is it a setting one can change? Thanks Simon

3 2

GitLab conventions
by Ben Gamari 01 Apr '19

01 Apr '19

Hi everyone, Today I have been working on better documenting our conventions under GitLab. This has resulted in a handful of documents: * A gitlab/issues wiki page [1], describing our triage and issue resolution workflow * A gitlab/merge-requests wiki page [2], describing our patch backport workflow * issue and merge request templates (e.g. [3] and [4]), which will be used by authors of issues and MR, respectively. If you frequent GHC's issue tracker it may be a good idea to look over the triage guide [1] to make sure you understand the implications of our many labels. Also, on the behest of Simon I propose that we start using a comment convention to note the addition of tests on issues (replacing Trac's "Test Case" field). Specifically, I suggest that a comment containing a line beginning with the token "Testsuite-tests:" followed by a series of comma-separated strings denote a set of test-cases for the issue. I have documented this here [5] If there is consensus that this is a sensible and worthwhile convention I will add these comments for the issues imported from Trac next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues [2] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests [3] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/issue_templates/bug.… [4] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/merge_request_templa… [5] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#marking-an-issue-as-…

1 0

Can't build HEAD with the old build system
by Ömer Sinan Ağacan 01 Apr '19

01 Apr '19

I just updated a few-days-old repo and `make` no longer works: $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/ghc-heap/ghc.mk:3: libraries/ghc-heap/dist-boot/build/.depend-v.haskell: No such file or directory libraries/ghci/ghc.mk:3: libraries/ghci/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:437: compiler/stage1/build/.depend-v.haskell: No such file or directory "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -outputdir utils/hsc2hs/dist/build -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o /usr/bin/ld.gold: internal error in find_view, at ../../gold/fileread.cc:336 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/hsc2hs/ghc.mk:21: recipe for target 'utils/hsc2hs/dist/build/tmp/hsc2hs' failed make[1]: *** [utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 I tried a custom build.mk and with no build.mk, got the same error either way. I also tried to build with hadrian and it worked. Is anyone here able to build with the old build system? If this is about my system, any ideas what might be the problem? Ömer

4 8

Newtypes in STG
by Christopher Done 01 Apr '19

01 Apr '19

Hi all, Could you offer some insight into newtypes at the STG level? Here’s the context: 1. I’m working on this interpreter for STG (https://github.com/chrisdone/prana) and I’m trying to generate a pristine AST where all names in it are resolved to something known to me. 2. I’ve compiled ghc-prim and integer-gmp without issue, and I’m compiling base and there remains one last frontier which is newtypes. These are the culprits pointed out if I compile base: chris@precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch Preprocessing library for base-4.11.1.0.. Building library for base-4.11.1.0.. [1 of 244] Compiling GHC.Base [2 of 244] Compiling GHC.IO [3 of 244] Compiling GHC.Real [4 of 244] Compiling Data.Semigroup.Internal ... [snip] ... [242 of 244] Compiling Data.Functor.Compose [243 of 244] Compiling Data.Fixed [244 of 244] Compiling Data.Complex Errors in Data.Foldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in Foreign.Marshal.Pool: Variable name not found: base:Foreign.Marshal.Pool.Pool Errors in GHC.ExecutionStack.Internal: Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace Errors in Data.Bifoldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in System.Timeout: Variable name not found: base:System.Timeout.Timeout Errors in Data.Data: Variable name not found: base:Foreign.Ptr.WordPtr Variable name not found: base:Foreign.Ptr.IntPtr Variable name not found: base:Data.Semigroup.Internal.Any Variable name not found: base:Data.Semigroup.Internal.All I looked these up, and they all appear to be *uses* of a newtype. For example, in the Timeout function: http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.ht… I printed out the full [StgTopBinding] list and got: let { sat_s27NC [Occ=Once] :: IO Timeout [LclId] = [] \u [] fmap $fFunctorIO Timeout newUnique; } in >>= $fMonadIO sat_s27NC sat_s27NT; Oddly (or not?), they’re used as values, not constructors. This error comes from this part of my code: StgSyn.StgApp occ arguments -> AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments If it was used as a constructor, it’d appear in this position, where looking up the ID would produce a “Data constructor name not found” error: StgSyn.StgConApp dataCon arguments types -> ConAppExpr <$> lookupDataConId dataCon <*> traverse fromStgGenArg arguments <*> pure (map (const Type) types) My understanding of newtypes at this stage is hazy. It seems like: - They ought to be erased and replaced with coercions by now. If they’re not replaced, it’s because they’re in a not-quite-id position like fmap Timeout .... (Arguably these could be fixed in base with a Data.Coerce.coerce?) - However, the CoreTidy/PrepPgm processing modules don’t seem to have removed or replaced these, or introduced a binding that would do something. At this stage what would you recommend? At this point type-checking is done, and I only care about interpreting the code. So I suppose they could be id for all it matters to the interpreter? I imagine they aren’t actually supposed to allocate something here. And I’m certain that any pattern matching on a newtype is also erased away by this point. Cheers! Chris

3 4

GitHub Mirror is broken
by Artem Pelenitsyn 31 Mar '19

31 Mar '19

Hello devs, This is just to let you know that the latestes commit on GitHub ghc/ghc repo dates back to 22th of January. Personally, I find GitHub mirror quite useful for ocasional searches over the code base. Therefore, I'd appreciated repairing the mirror. -- Best of luck, Artem Pelenitsyn

5 5

gitlab.haskell.org is down
by Shayne Fletcher 29 Mar '19

29 Mar '19

Hi, It seems gitlab.haskell.org has been down since around 17:30 GMT. Outage? -- 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.

5 5

GitLab down
by Ben Gamari 28 Mar '19

28 Mar '19

Hi everyone, Due to unplanned maintenance gitlab.haskell.org is currently down. Sorry for the inconvenience. I'll post updates as appropriate. Cheers, - Ben

1 0

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

28 Mar '19

Simon: > Perhaps the remaining un-tracked dependencies will be fewer and easier to nail? There are a few other cases where we `need` only a subset of direct dependencies that "cover" all others. For example, `setup-config` files produced when configuring a package are used to signal the completion of package configuration, which might produce a few other hard-to-predict files, such as “build/include/HsBaseConfig.h”. I just realised that if one wants to have “hermetic builds”, where build commands are executed in a sandbox, then it is absolutely necessary to declare all direct dependencies without exception, because they will need to be made available in the sandbox for the build command to succeed. David: > Perhaps the best step forward is to simply silence the linting > using `trackAllow ["//*.hi"]` for haskell object rules. Then > I can continue tracking down other missing dependencies in > Hadrian with fsatrace linting. Yes, this looks like the best approach for now. Cheers, Andrey

2 1

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

27 Mar '19

Simon's insight is great: if deep dependencies are captured by shallow dependencies then the cloud build system is correct even if only direct shallow inputs are tracked. That's a very non-trivial invariant, and I guess this means we can't rely on fsatrace linting for GHC compilation rules, because all deep dependencies will be reported as untracked. Cheers, Andrey On 27 Mar 2019 18:27, Simon Peyton Jones <simonpj(a)microsoft.com> wrote: With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" But I question that assumption. As I mentioned, with GHC at least, the if a deep dependency changes then one of the shallow dependencies will change. So I claim that even for cloud build it should be enough to depend only on shallow dependencies. This is only true because GHC offers this guarantee. We’d need to be sure that every deep dependency was either ‘needed’ or was reflected in the contents (perhaps via a fingerprint) another ‘needed’ thing. Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of David Eichmann Sent: 27 March 2019 17:12 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Neil Mitchell <ndmitchell(a)gmail.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Re: Hadrian Transitive Dependencies Hello, To reiterate some definitions consider this scenario: * A.hs imports B.hs and B.hs imports C.hs * `ghc -M A.hs` reports that A.o depends on: A.hs, B.hi * `ghc -c A.hs` produces A.o and accesses A.hs, B.hi, and C.hi There seems to be some confusion about the term "Direct Dependency" I'll use these definitions: "Shallow Dependency": With respect to a haskell object file X.o, the shallow dependencies are the source file X.hs and interface files Y.hi for all modules Y imported by X. * These are the dependencies of X.o as reported by `ghc -M X.hs` * In the above scenario: * * A.o depends on: A.hs, B.hi "Deep Dependency": With respect to a haskell object file X.o, the deep dependencies are all hi files required by ghc to build X.o excluding direct dependencies: * This is a subset of modules transitively imported by X * These dependencies are NOT reported by `ghc -M X.hs` "Direct Dependency": if the command to create file X accesses file Y, then X directly depends on Y (= Y is a direct dependency of X). * In the above scenario: * * A.o directly depends on: A.hs, B.hi, and C.hi * SPJ noted that .hi files list direct dependencies. * The direct dependencies of a haskell object file is the union of its shallow and deep dependencies. "Direct Output": All files created by a rule. With that in mind, and considering a cloud build system where "all direct inputs and direct outputs must be declared" (where this agrees with the definitions above) can we do the following for the build rule of a haskell object file X.o? 1. `need` the shallow dependencies as reported by `ghc -M`. This guarantees that all shallow and deep dependencies (i.e. all direct dependencies) are built. 2. build X.o and X.hi 3. Inspect X.hi to derive the direct dependencies (and hence deep dependencies) 4. `needed` the deep dependencies Is there already an easy way to inspect *.hi files in this way? Is this use of `needed` valid? - David E On 3/27/19 3:05 PM, Andrey Mokhov wrote: 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><mailto:ndmitchell@gmail.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk><mailto:andrey.mokhov@newcastle.ac.uk>; GHC developers <ghc-devs(a)haskell.org><mailto:ghc-devs@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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…> 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.well-t…> Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England

3 2