September 2019 - ghc-devs

What does a milestone mean?
by Matthew Pickering 24 Sep '19

24 Sep '19

Hi, It seems that basically every new issues gets triaged with the 8.10.1 milestone, what does this mean? It seems like a lot of the issue's won't get fixed for 8.10, or at any foreseeable point in the future which dilutes the milestoning. Therefore I don't think we should assign a certain milestone to a ticket unless either 1. The issue is considered necessary to fix for that milestone (ie, a regression) 2. Someone is planning to work on the ticket for that milestone (ie, a feature/improvement) Then the milestone actually has some meaning. Cheers, Matt

2 1

Filtering GitLab mentions
by Ben Gamari 24 Sep '19

24 Sep '19

Hi everyone, During a discussion on procedural matters earlier today it was (yet again) noted that GitLab notification emails are quite chatty and consequently it is easy to lose the signal in the noise. However, during this discussion we also realized that much of the issue can be mitigated with a simple email filter to identify explicit @-mentions. I find that: from:gitlab.haskell.org and @bgamari and header:X-GitLab-Discussion-Id isolates emails arising from @-mentions fairly effetively. If your MUA doesn't support filtering by arbitrary headers you can replace the "header" predicate with simply a mention of the word "commented". If you are active on GitLab I would encourage you to setup such a filter; I was surprised by how many comments I had overlooked. Cheers, - Ben

1 0

GHC 8.10.1 Release Plan
by Ben Gamari 23 Sep '19

23 Sep '19

tl;dr. If you have unmerged work that you would like to be in GHC 8.10 please reply to this email and submit it for review in the next couple of weeks. Hello everyone, Now that GHC 8.8.1 is behind us it is time that we begin thinking about 8.10. There seems to be broad consensus within the subset of the community that I sampled that we should try to hold to the usual release date near the end of year for 8.10.1. I believe that this is a feasible goal with the caveat that we push the final release back by a couple of weeks in recognition that busy schedules of the holiday season tends to throw unexpected wrenches into the release process. In particular I would suggest the following concrete schedule: October 18 2019: start of one week freeze in preparation for branching October 25 2019: ghc-8.10 branch cut November 8 2019: 8.10.1-alpha1 November 22 2019: 8.10.1-alpha2 December 6 2019: 8.10.1-alpha3 December 20 2019: 8.10.1-rc1 January 10 2020: Final 8.10.1 release If you have yet-unmerged work that you would like to see in GHC 8.10 please do be in touch and open a merge request ASAP. One obvious question is how we will avoid the many delays that plagued the 8.8.1 release. Without delving too deep into the specific reasons for these delays, the reasons fell into two buckets: 1. delays due to CI stabilization 2. coordination delays with upstream libraries 3. fallout from MonadFail changes which landed only late in the release cycle Of these, (1) is largely behind us and (3) will be avoided by ensuring that core libraries changes are landed *before* the branch date. This leaves consideration (2). The problem of upstream library coordination has always been a tricky one but has grown more acute as our release schedule has accelerated. While no technical solution will eliminate the issue entirely, we believe that decoupling GHC's release schedule from those of its dependencies' is an important mitigation. We will be discussing this with upstream library maintainers in the coming weeks to establish how we can ensure that releases are available well ahead of the GHC 8.10 release, ideally by alpha2. Cheers, - Ben

7 7

Test cases and missing RTS linker
by Stefan Schulze Frielinghaus 18 Sep '19

18 Sep '19

Hi all, How is a test case supposed to be marked if it makes use of the RTS linker which itself is not supported on some architectures? For example, some test cases are marked for a particular architecutre like PowerPC64 that it fails because of a missing RTS linker. Style (A) test('T10052', [when(arch('powerpc64') or arch('powerpc64le'), expect_broken(11259)), req_interp], makefile_test, ['T10052']) Whereas another test case is marked to be skipped if RTS linker is missing. Style (B) test('static-plugins', [extra_files(['simple-plugin/']), unless(config.have_RTS_linker, skip), expect_broken_for(16803, prof_ways), extra_run_opts('"' + config.libdir + '"')], compile_and_run, ['-package ghc -isimple-plugin/']) If style (A) is the way to go, then for every architecture which does not support the RTS linker a when-clause must be added. If style (B) is the way to go, then shouldn't we change all test cases of style (A) to style (B)? Personally I prefer style (B) over (A) because it makes it easier to add an architecture where the RTS linker is not provided. Even if the RTS linker is provided after some time, then the test case must not be changed. Once PowerPC64 supports the RTS linker all when-clauses must be removed. Any thoughts which style to use? Cheers, Stefan

1 0

validate-whitespace
by Alejandro Serrano Mena 18 Sep '19

18 Sep '19

Hi GHC devs, I have made a rebase to bring my merge request [ https://gitlab.haskell.org/ghc/ghc/merge_requests/1659] up to date with the current GHC codebase. In the process there were some conflicts (as expected) which I could solve. However, now that I have pushed the result, I get these messages from the CI infrastructure: $ validate-whitespace .git $(git rev-list $base..$CI_COMMIT_SHA) ===================================================================================== commit 0d92f8c898ccbf2ffb602bc75e50e9ffd44811d8 has whitespace linter issues: *ERROR* compiler/typecheck/TcUnify.hs:810: introduces trailing whitespace > " " *ERROR* compiler/typecheck/TcUnify.hs:818: introduces trailing whitespace > " = " Validation FAILED for 0d92f8c898ccbf2ffb602bc75e50e9ffd44811d8 ===================================================================================== commit 465d27f2119d7bdbe06832dd79c3848e27b4aaef has whitespace linter issues: *ERROR* compiler/typecheck/TcExpr.hs:1315: introduces trailing whitespace > " ; subst <- if xopt LangExt.ImpredicativeTypes dflags " *ERROR* compiler/typecheck/TcExpr.hs:1472: introduces trailing whitespace > " _ -> return emptyTCvSubst " *ERROR* compiler/typecheck/TcExpr.hs:1513: introduces trailing whitespace > " " Validation FAILED for 465d27f2119d7bdbe06832dd79c3848e27b4aaef ===================================================================================== Validation FAILED because at least one commit had linter errors! What is the right approach to fix these problems? I can fix the whitespace issues in a new commit, but I don't see how to fix them in all the interim commits :( Thanks in advance and kind regards, Alejandro

2 1

Fwd: Why do Constraint Tuple data constructors exist?
by Joe Crayne 17 Sep '19

17 Sep '19

My question arrised in the following context: ``` module ForEachHelper where import Data.Kind import GHC.TypeLits type family ForEach (c :: k -> Constraint) (xs :: [k]) :: Constraint where ForEach c '[] = () ForEach c (x:xs) = (c x, ForEach c xs) type family Replicate n x where Replicate 0 x = '[] Replicate n x = x : Replicate (n-1) x data ForEachHelper n c x where ForEachHelper :: ForEach c (Replicate n x) => ForEachHelper n c x -- The following solve function was actually in another module from the definitions above: solve :: ( KnownNat n, c x -- Solved via plugin: -- , ForEach c (Replicate n x) ) => p c -> q x -> ForEachHelper n c x solve pc px = ForEachHelper ``` I was trying to write a plugin that could solve the (ForEach c (Replicate n x)) constraint. I need an EvTerm that this constraint. The first thing I tried was to use the given EvTerm for the (c x) constraint without change. This causes the program to compile but ultimately and, perhaps not surprisingly, it segfaults when code relies upon the constraint. Then I decided that (ForEach c (Replicate n x)) is a constraint tuple and the proof term should be a tuple constructed using a constraint tuple data constructor. However, this is apparently not possible. When I tried the following code in the initialization of my plugin: cpairCon <- tcLookupDataCon (cTupleDataConName 2) it triggers an error: Can't find interface-file declaration for data constructor GHC.Classes.(%,%) Searching GHC source, I cannot find where or how constraint data constructors are used and notes on commit ffc21506894c7887d3620423aaf86bc6113a1071 were not helpful to me either. Why do constraint tuple data constructor names exist at all if we cannot use them for anything? Is it possible for a plugin to solve the (ForEach c (Replicate n x)) constraint by some other means?

2 1

Changes in GHC API modularity with the "Encode shape information in PMOracle" MR
by Shayne Fletcher 17 Sep '19

17 Sep '19

Some time back, the `ghc-lib` project split into two targets : `ghc-lib-parser` for those projects that just need to produce syntax trees and `ghc-lib` (re-exporting `ghc-lib-parser` modules) having the remaining modules for projects that need to go on and distill parse trees to Core. The idea of course was to reduce build times for tools like hlint that only need parse trees. Roughly, `ghc-lib-parser` got about 200 files and `ghc-lib` 300. Today after landing `7915afc6bb9539a4534db99aeb6616a6d145918a`, "Encode shape information in `PmOracle`", `ghc-lib-parser` now needs 543 files and `ghc-lib` gets just 25. That may be just bad luck for `ghc-lib-parser` and the way it has to be but I thought I should at least mention the knock-on effect of this change on the modularity of the GHC API in case this consequence hasn't been considered? -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.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.

3 8

compiler plugin pass order
by Anton Antich 16 Sep '19

16 Sep '19

Dear all, we started exploring Haskell-to-DotNet compiler in frames of a larger project and would like to clarify one issue: is it possible to control the order in the compilation pipeline in which the compiler plugins get called? Inserting .Net compilation via Plugin seems a cleaner way than using GHC API from scratch for a lot of reasons, but the challenge is as follows: we compile from STG but inside the plugin core2core passes have not been called yet, and without them some important optimizations are missing. To illustrate the issue, this function "plus x = x + 4" gets compiled to a nice stg function with core2core (core2core, corePrep, coreToStg, stg2stg): plus :: forall a. Num a => a -> a [LclIdX, Arity=2, Unf=OtherCon []] = [] \r [$dNum_s1bl x] let { sat_s1bz [Occ=Once] :: a [LclId] = [$dNum_s1bl] \u [] let { sat_s1by [Occ=Once] :: Integer [LclId] = CCCS S#! [4#]; } in fromInteger $dNum_s1bl sat_s1by; } in + $dNum_s1bl x sat_s1bz; Inside the plugin, it is only possible to do the same pipeline but *without* the core2core passes, and it gets compiled with additional THUNK: [sat_s1gp :: forall a. Num a => a -> a [LclId] = [] \r [$dNum_s1ga x] let { sat_s1go [Occ=Once] :: a [LclId] = [$dNum_s1ga] \u [] let { sat_s1gn [Occ=Once] :: Integer [LclId] = CCCS S#! [4#]; } in fromInteger $dNum_s1ga sat_s1gn; } in + $dNum_s1ga x sat_s1go;, plus :: forall a. Num a => a -> a [LclIdX] = [] \u [] sat_s1gp;, So the question is - is there any way to ask GHC to run the plugin as LAST in the core2core passes process so that we get the optimized core and convert it to stg? Alternatively, maybe STG plugins should also be introduced? Should be an easy enough change. Thank you for comments / suggestions / ideas!

2 1

eqType modulo associated types?
by Conal Elliott 16 Sep '19

16 Sep '19

It looks to me like `eqType` accounts for type synonyms but not associated types. Is there a variant that compares modulo associated types, or perhaps a type normalizing operation to apply before `eqType`? Thanks, - Conal

3 3

GHC/StgToCmm/Con.hs
by Shayne Fletcher 14 Sep '19

14 Sep '19

Anyone understand what's going on here (HEAD) on Windows? ``` 2019-09-14T19:06:40.1438283Z # Running: git clone https://gitlab.haskell.org/ghc/ghc.git 2019-09-14T19:06:40.1879263Z Cloning into 'ghc'... 2019-09-14T19:07:02.4403717Z error: unable to stat just-written file compiler/GHC/StgToCmm/Con.hs: No such file or directory ``` -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* <https://digitalasset.com/>, creators of *DAML <https://daml.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.

3 4