- ghc-devs - Haskell.org

possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable
by Doug Burke 06 Sep '22

06 Sep '22

I have a test executable which will build with ghc 9.2.3 (and many older versions) but which appears to hang with GHC 9.2.4. I have exhausted what little I know of in debugging this, so any help in identifying the problem would be appreciated. Unfortunately it's a relatively large application, so the following reproducer requires some time/disk space. Thanks fo ryour time, Doug ----------------------------------------------------------------------------------------------------------------- I am on a linux machine (ubuntu 22.04) and have seen this with builds either with stack or nix. % git clone https://gitlab.com/dburke/swish temp % cd temp % git rev-parse HEAD 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae Added to get the timings, but it's not strictly necessary: % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal First a check of a successful build (with stack, GHC 9.0.2): % stack test --resolver lts-19.22 :test-rdfproof ... wait a while [2 of 2] Compiling Main *** Parser [Main]: Parser [Main]: alloc=27576560 time=8.702 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=61957416 time=85.052 *** Desugar [Main]: Desugar [Main]: alloc=19485576 time=16.095 *** Simplifier [Main]: Simplifier [Main]: alloc=1024590752 time=937.479 *** Specialise [Main]: Specialise [Main]: alloc=49779464 time=30.480 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=243444904 time=287.934 *** Simplifier [Main]: Simplifier [Main]: alloc=959971736 time=844.707 *** Simplifier [Main]: Simplifier [Main]: alloc=816465992 time=727.244 *** Simplifier [Main]: Simplifier [Main]: alloc=914290184 time=835.805 Float inwards [Main]: alloc=17448 time=0.007 Called arity analysis [Main]: alloc=19288 time=0.008 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: *** Demand analysis [Main]: Simplifier [Main]: alloc=492772800 time=396.191 Demand analysis [Main]: alloc=435384136 time=234.248 *** Constructed Product Result analysis [Main]: Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 *** Worker Wrapper binds [Main]: Worker Wrapper binds [Main]: alloc=10456160 time=10.538 *** Simplifier [Main]: Simplifier [Main]: alloc=675869616 time=624.538 Exitification transformation [Main]: alloc=20416 time=0.007 *** Exitification transformation [Main]: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: alloc=212059304 time=172.872 Common sub-expression [Main]: alloc=18768 time=0.008 Float inwards [Main]: alloc=17448 time=0.006 *** Common sub-expression [Main]: *** Float inwards [Main]: *** Simplifier [Main]: Simplifier [Main]: alloc=430634768 time=397.868 *** Demand analysis [Main]: Demand analysis [Main]: alloc=144629272 time=70.451 *** CoreTidy [Main]: CoreTidy [Main]: alloc=48438688 time=44.112 *** CorePrep [Main]: *** CodeGen [Main]: CorePrep [Main]: alloc=15032 time=0.012 CodeGen [Main]: alloc=1738308168 time=1051.197 *** systool:as: systool:as: alloc=118376 time=0.481 *** initializing unit database: initializing unit database: alloc=15393080 time=21.985 *** initializing unit database: initializing unit database: alloc=3745512 time=2.507 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=213016 time=0.552 Chasing dependencies: alloc=11345152 time=5.353 Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof ... ... ... then it goes on to run the test ... With 9.2.4 it will not build % ... similar to above but with some information about the versions not ... fully tested with stack ... *** Parser [Main]: Parser [Main]: alloc=24346008 time=8.730 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=58415776 time=44.077 *** Desugar [Main]: Desugar [Main]: alloc=22148416 time=15.693 *** Simplifier [Main]: Simplifier [Main]: alloc=651048904 time=530.123 *** Specialise [Main]: Specialise [Main]: alloc=44412080 time=31.885 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=207753368 time=259.238 *** Simplifier [Main]: Simplifier [Main]: alloc=599788216 time=548.107 *** Simplifier [Main]: Simplifier [Main]: alloc=562910904 time=474.847 *** Simplifier [Main]: Simplifier [Main]: alloc=725093584 time=643.255 Float inwards [Main]: alloc=23720 time=0.011 Called arity analysis [Main]: alloc=25856 time=0.012 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: At this point it just makes my laptop fan spin faster wit h one of my CPUs pegged at 100%, but it never seems to print anything more. For those that prefer nix, you can try the following which shows the same behavior (these are using the same mangled cabal file to get the timings): % nix-shell --argstr compiler ghc923 % cabal test test-rdfproof ... [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25233912 time=9.910 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=57027880 time=45.911 *** Desugar [Main]: Desugar [Main]: alloc=21808096 time=54.569 *** Simplifier [Main]: Simplifier [Main]: alloc=936319072 time=880.189 *** Specialise [Main]: Specialise [Main]: alloc=41599784 time=23.425 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=204955224 time=226.189 *** Simplifier [Main]: Simplifier [Main]: alloc=610153728 time=654.735 *** Simplifier [Main]: Simplifier [Main]: alloc=566346328 time=549.298 *** Simplifier [Main]: Simplifier [Main]: alloc=801330080 time=802.428 *** Float inwards [Main]: Float inwards [Main]: alloc=23160 time=0.012 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25296 time=0.013 *** Simplifier [Main]: Simplifier [Main]: alloc=423629864 time=320.611 *** Demand analysis [Main]: Demand analysis [Main]: alloc=253018800 time=175.884 *** Constructed Product Result analysis [Main]: Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 *** Worker Wrapper binds [Main]: Worker Wrapper binds [Main]: alloc=8622264 time=7.070 *** Simplifier [Main]: Simplifier [Main]: alloc=598294440 time=554.802 *** Exitification transformation [Main]: Exitification transformation [Main]: alloc=26712 time=0.013 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: alloc=179540608 time=226.938 *** Common sub-expression [Main]: Common sub-expression [Main]: alloc=24800 time=0.014 *** Float inwards [Main]: Float inwards [Main]: alloc=23168 time=0.010 *** Simplifier [Main]: Simplifier [Main]: alloc=382679152 time=318.224 *** Demand analysis [Main]: Demand analysis [Main]: alloc=84192056 time=50.989 *** CoreTidy [Main]: CoreTidy [Main]: alloc=45347360 time=44.571 *** CorePrep [Main]: CorePrep [Main]: alloc=34753448 time=10.917 *** CoreToStg [Main]: CoreToStg [Main]: alloc=108293568 time=114.768 *** CodeGen [Main]: CodeGen [Main]: alloc=1475393208 time=858.854 *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: alloc=3732816 time=3.044 *** systool:as: systool:as: alloc=132384 time=0.456 *** initializing unit database: initializing unit database: alloc=7386016 time=4.306 *** initializing unit database: initializing unit database: alloc=4000384 time=12.125 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=313896 time=0.486 Chasing dependencies: alloc=12822240 time=6.459 Linking /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof ... ... versus % nix-shell --argstr compiler ghc924 cabal test test-rdfproof Warning: The package list for 'hackage.haskell.org' is 20 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-9.2.4 -O1 In order, the following will be built (use -v for more details): - swish-0.10.2.0 (test:test-rdfproof) (first run) Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7389248 time=4.462 *** initializing unit database: initializing unit database: alloc=4001312 time=11.664 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=319464 time=0.481 Chasing dependencies: alloc=12861208 time=6.331 [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25236056 time=23.982 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=101830968 time=97.529 *** Desugar [Main]: Desugar [Main]: alloc=24617072 time=19.187 *** Simplifier [Main]: Simplifier [Main]: alloc=665051592 time=558.078 *** Specialise [Main]: Specialise [Main]: alloc=44894576 time=30.341 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208060752 time=245.458 *** Simplifier [Main]: Simplifier [Main]: alloc=602721856 time=555.073 *** Simplifier [Main]: Simplifier [Main]: alloc=563887832 time=529.865 *** Simplifier [Main]: Simplifier [Main]: alloc=727381840 time=606.367 *** Float inwards [Main]: Float inwards [Main]: alloc=23720 time=0.012 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25848 time=0.012 *** Simplifier [Main]: which again hangs

3 4

Updating haddock
by Simon Peyton Jones 05 Sep '22

05 Sep '22

Dear devs I'm working on !8750, which has some knock-on changes that are needed on the Haddock repo. So - in the main repo I have wip/T21623 - in the utils/haddock repo have branch wip/spj-T21623 Periodically I need to rebase on master. Question: what is the Blessed Sequence of Commands that I should use to push the right changes to haddock? I think it is something like: 1. In the main GHC repo, on branch wip/T21623 1. git fetch 2. git rebase origin/master 2. In utils/haddock, 1. identify the set of patches P1..Pn between the trunk and my haddock tip, the changes that I need to haddock. 2. Somehow check out the haddock commit K that corresponds to origin/master 3. Apply P1..Pn on top of K 4. Force-push to origin/wip/spj-T21623 3. Move to the main GHC repo 1. git add utils/haddock 2. Create a patch for that change 3. Push to main repo But I am not sure how to do step 2.2, nor what is an efficient way to do 2.3. I would welcome very precise instructions. Thank you! Simon

2 1

Tags
by Simon Peyton Jones 05 Sep '22

05 Sep '22

I love emacs' tags-query-replace function, which allows me to do a search-and-replace across an entire repo. But to do that I need a TAGS file that, at least, lists all the Hsakell files in GHC. What is the approved way to construct a TAGS file for a bunch of Haskell modules? Is this documented anywhere? Thanks Simon

3 2

CI failures
by Simon Peyton Jones 05 Sep '22

05 Sep '22

Matthew, Ben, Bryan CI is failing in in "lint-ci-config".. See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8916 or https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7847 What's up? Simon

2 2

Benchmarking lexical scan during the downsweep for the ImplicitQualifiedImport proposal
by Tristan Cacqueray 29 Aug '22

29 Aug '22

Hello all, In the context of https://github.com/ghc-proposals/ghc-proposals/pull/500, I am looking for a strategy to measure the impact of resolving modules dependencies using a lexical scan during the downsweep phase. For example, in this branch: https://gitlab.haskell.org/TristanCacqueray/ghc/-/tree/make-lexical-analysis I've added a tokenizer pass in the GHC.Driver.Make.getPreprocessedImports function, and using `/usr/bin/time -o /dev/stdout -v _build/stage1/bin/ghc compiler/GHC/Tc/TyCl.hs 2> /dev/null` I measure: LexicalAnalysis found 91 qualified name, and lasted: 150msec Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.72 Maximum resident set size (kbytes): 142396 Using a clean build I get: Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.68 Maximum resident set size (kbytes): 140012 Now my question is, how would you measure the time and space cost of such change. For example, what profiling tool would you recommend and how can I test a modified ghc to build ghc itself? Thanks in advance, -Tristan

2 2

Instructions to build GHC
by Harendra Kumar 26 Aug '22

26 Aug '22

Hi, I used to follow the instructions in INSTALL.md and README.md in the root of the repo, and they always worked until recently. I am aware that the make based system has been replaced by Hadrian. But it seems these files are not updated with the new build instructions. 1. Either these files should be removed from the source or they should be updated. 2. Where are the new build instructions? Is it hadrian/README.md? If so can we put a pointer to that in INSTALL.md? Thanks, Harendra

1 0

The end of the road for the `make` build system
by Ben Gamari 24 Aug '22

24 Aug '22

Hello all, With the 9.4.2 release being out, we are turning our attention to preparations for 9.6. Among these tasks is the removal of the `make`-based build system, allowing us to finally close #17527. The branch removing `make` can be found in !7094, which we hope to send to Marge by the end of this week. For those of you still using `make`, this is your call to switch. Hadrian's documentation can be found in the tree (`hadrian/doc` [1]), the Wiki [2], and our packagers' migration guide [3]. If you have any remaining issues with Hadrian or its documentation do let us know so that we can address them. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/tree/master/hadrian/doc [2] https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian [3] https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

[ANNOUNCE] GHC 9.4.2 is now available
by Ben Gamari 22 Aug '22

22 Aug '22

The GHC developers are happy to announce the availability of GHC 9.4.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.4.2 This release is primarily a bugfix release addressing a few packaging issues found in 9.4.1. See the [release notes] for a full accounting. Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new Hadrian build system, it is possible that there will be packaging issues. If you enounter trouble while using a binary distribution, please open a [ticket]. Likewise, if you are a downstream packager, do consider migrating to [Hadrian] to run your build; the Hadrian build system can be built using `cabal-install`, `stack`, or the in-tree [bootstrap script]. See the accompanying [blog post] for details on migrating packaging to Hadrian. We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC's Windows toolchain. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy Haskelling, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [Hadrian]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d1… [release notes]: https://downloads.haskell.org/~ghc/9.4.2/docs/users_guide/9.4.2-notes.html [blog post]: https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html

1 0

Partial type synonyms -- first-class!
by ÉRDI Gergő 17 Aug '22

17 Aug '22

As I mentioned at the end of the original thread (but probably no one was interested in this enough to read that far), after a breakthrough idea I have now started working on partial type synonyms that are NOT just defined using macro expansion semantics, and indeed can be a first-class abstraction. I think if I can iron out the wrinkles detailed at the bottom of this message, this would be good for a GHC proposal. 1. Defining partial type synonyms The idea is to typecheck the type synonym declaration type Syn a = MyType _ [a] Int into a type synonym that has some implicit (invisible) type parameters: type Syn {w1} a = MyType w1 [a] Int We don't need to come up with any new design for "what this means": this means exactly the same as type Syn w1 a = MyType w1 [a] Int which is something you can already write today. The only difference is how `w1` is given at use sites. 2. Using partial type synonyms When a partial type synonym is applied, its argument list is expanded by adding wildcard arguments for the invisible parameters. So this use site: Syn Double is typececked into the type application Syn {_} Double Again, we don't need to come up with any new design for "what this means": this is the same as writing `Syn _ Double` into the same position, it's just the `_` is not written in the surface syntax. In particular: * The level of the type variable conjured for the `_` is determined fully by where the `Syn Double` occurs, and not at all by the definition of `Syn` * Using the type synonym `Syn` is only valid where a wildcard occurrence would be valid. In particular, using `Syn` in a type signature causes the signature itself to be regarded as partial (`isCompleteHsSig` returns `False` for it). 3. Implementation I have a proof-of-concept implementation at https://gitlab.haskell.org/cactus/ghc/-/compare/master...cactus%2Fpartial-t… I tried to make it as small a change as I could. Its key points are: * In the renamer, we allow wildcards in `TySynCtx` context * In `tcTySynRhs`, we allow wildcards in the right-hand side, retrieve them from the result of typechecking, and intersperse them with the "normal" type parameters to get a well-scoped telescope. * About a third of the lines changed is just a boring refactoring of `isCompleteHsSig` to be able to look up type synonym `TyCon`s. This is needed because a type signature referring to partial type synonyms will be partial itself once those type synonym applications are elaborated. * When typechecking a type application, implicit arguments get filled with the result of `tcAnonWildCardOcc`. Now, my questions about the problems I've encountered along the way. I hope these questions are concrete enough that I can get concrete answers to them from this list: 1. How do I find the wildcard-originating tyvars robustly? Currently, I am using `candidateQTyVarsWithBinders` but that picks up "regular" out-of-scope tyvars as well. I believe this causes a regression of #17567; furthermore, it means if the user writes `type Syn a = Foo b` it is handled the same as if they wrote `type Syn a = Foo _`, but it would be better to reject it instead. 2. What should the `Role` of these implicit type parameters be? For now, I've went with `Nominal` for lack of a better answer. 3. When typechecking a type application, I need to insert wildcards for these implicit arguments. I am currently using `AnonTCB InvisArg` binders to represent these implicit type parameters, which means by the time I get to `tcInferTyApps`, they would get passed through `instantiate` to `tcInstInvisibleTyBinder`. I currently have a horrible kuldge here to check, before calling `tcInstInivisibleTyBinder`, that the invisible binder's kind doesn't meet the preconditions of it; and if it doesn't, I create a wildcard instead. But of course, it would be nicer if I could put something in the `TcTyConBinder` that identifies these binders properly. Thanks in advance, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------'

5 6

Question about ambiguous predicates in pattern bindings
by Benjamin Redelings 16 Aug '22

16 Aug '22

Hi, 1. I'm reading "A Static semantics for Haskell" and trying to code it up. I came across some odd behavior with pattern bindings, and I was wondering if someone could explain or point me in the right direction. Suppose you have the declaration (x,y) = ('a',2) My current code is yielding: x :: Num a => Char y :: Num a => a However, I notice that ghci gives x the type Char, with no constraint, which is what I would expect. It also gives y the type 'Num b => b', so I don't think it is defaulting a to Int here. The weird results from my code stem from rule BIND-PRED in Figure 15 of https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semanti… E |- bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta => LVE) Here theta = ( Num a ) and LVE = { x :: Char, y :: a }. So, theta => LVE is { x :: Num a => Char, y :: Num a => a } The obvious thing to do is avoid changing a type T to Num a => T if T does not contain a. Also I'm not totally sure if that trick gets to the bottom of the issue. However, the paper doesn't mention define theta => LVE that way. Is there something else I should read on this? 2. If we just chop out predicates which mention variables not in the type ( == ambiguous predicates?) then I'm not totally sure how to create code for this. I would imagine that we have something like tup dn = ('a', fromInteger dn 2) x = case (tup dn) of (x,y) -> x y dn case (tup dn) of (x,y) -> y In this case its not clear where to get the `dn` argument of `tup` from, in the definition of `x`. Can we pass in `undefined`? Should we do something else? If anyone can shed light on this, I would be grateful :-) -BenRI

4 8