Which stage 0 compiler are you using? It seems to be <= 8.10 and still has 8038cbd96f4 merged which seems contradictory. Anyway the alternative seems to be redundant from the beginning and should have been removed IMO. I have opened https://gitlab.haskell.org/ghc/ghc/merge_requests/2564 to fix this. Does it work after applying this patch? Sylvain On 27/01/2020 12:42, Simon Peyton Jones via ghc-devs wrote:

It would be good to know how to fix this.  It’s blocking my builds.

For some reason it doesn’t seem to kill CI

Simon

*From:*Simon Peyton Jones *Sent:* 25 January 2020 20:26 *To:* ghc-devs <ghc-devs@haskell.org> *Subject:* stage2 build fails

I’m getting this with “sh validate –legacy”

compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, -Werror=overlapping-patterns]

    Pattern match is redundant

    In an equation for ‘settings’: settings s | otherwise = ...

     |

1344 |             | otherwise = panic $ "Invalid cfg parameters." ++ exampleString

     |               ^^^^^^^^^

This is when compiling the stage-2 compiler.  There’s an ifdef in DynFlags thus

#if __GLASGOW_HASKELL__ <= 810

            | otherwise = panic $ "Invalid cfg parameters." ++ exampleString

#endif

but somehow it’s not triggering for the stage2 compiler.

Any ideas?  It’s blocking a full build.

This #ifdef was added in 8038cbd96f4, when GHC became better at reporting redundant code.

Simon

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

| Indeed it would be nice to know which compiler you are using to | bootstrap. I suspect Sylvain is correct that the alternative can be | removed but first I would like to understand why this is arising only | now. I'm using 8.6.4 as my bootstrap compiler. But this message occurs only when compiling the *stage2* compiler with the *stage1* compiler. At that moment the bootstrap compiler is irrelevant. It's as if the build system doesn't know that the stage1 compiler is >= 8.10 Simon | -----Original Message----- | From: Ben Gamari <ben@smart-cactus.org> | Sent: 27 January 2020 14:51 | To: Simon Peyton Jones <simonpj@microsoft.com>; ghc-devs <ghc- | devs@haskell.org> | Subject: Re: stage2 build fails | | Simon Peyton Jones via ghc-devs <ghc-devs@haskell.org> writes: | | > I'm getting this with "sh validate -legacy" | > | > compiler/main/DynFlags.hs:1344:15: error: [-Woverlapping-patterns, - | Werror=overlapping-patterns] | > | > Pattern match is redundant | > | > In an equation for 'settings': settings s | otherwise = ... | > | > | | > | > 1344 | | otherwise = panic $ "Invalid cfg parameters." ++ | exampleString | > | > | ^^^^^^^^^ | > This is when compiling the stage-2 compiler. There's an ifdef in | DynFlags thus | > | > #if __GLASGOW_HASKELL__ <= 810 | > | > | otherwise = panic $ "Invalid cfg parameters." ++ | exampleString | > | > #endif | > but somehow it's not triggering for the stage2 compiler. | > Any ideas? It's blocking a full build. | > This #ifdef was added in 8038cbd96f4, when GHC became better at | reporting redundant code. | > Simon | | Indeed it would be nice to know which compiler you are using to | bootstrap. I suspect Sylvain is correct that the alternative can be | removed but first I would like to understand why this is arising only | now. | | Cheers, | | - Ben

I did "sh validate --legacy" which uses "make maintainer-clean". I'll try again to double check. Is there any particular file I should remove? Simon | -----Original Message----- | From: Ben Gamari <ben@smart-cactus.org> | Sent: 27 January 2020 18:59 | To: Simon Peyton Jones <simonpj@microsoft.com>; ghc-devs <ghc- | devs@haskell.org> | Subject: RE: stage2 build fails | | Simon Peyton Jones <simonpj@microsoft.com> writes: | | > | Indeed it would be nice to know which compiler you are using to | > | bootstrap. I suspect Sylvain is correct that the alternative can be | > | removed but first I would like to understand why this is arising only | > | now. | > | > I'm using 8.6.4 as my bootstrap compiler. But this message occurs only | when compiling the *stage2* compiler with the *stage1* compiler. At that | moment the bootstrap compiler is irrelevant. | > | > It's as if the build system doesn't know that the stage1 compiler is >= | 8.10 | > | Hmm, interesting. Has this tree been cleaned in the last month or two? | I suspect that this may have something to do with the changes to the | GHC_STAGE macro that were merged a while back (perhaps a stale header | file?). | | Cheers, | | - Ben

Thanks -- I'll try that. Simion | -----Original Message----- | From: Stefan Schulze Frielinghaus <ml@stefansf.de> | Sent: 28 January 2020 11:32 | To: Simon Peyton Jones <simonpj@microsoft.com> | Cc: Ben Gamari <ben@smart-cactus.org>; ghc-devs <ghc-devs@haskell.org> | Subject: Re: stage2 build fails | | I ran into a similar(?) problem a while ago. "make maintainer-clean" | does not necessarily remove every generated file. See for example | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fpipermail%2Fghc-devs%2F2019- | August%2F018049.html&data=02%7C01%7Csimonpj%40microsoft.com%7Cd2614760 | 6ba1488142db08d7a3e5bbce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6371 | 58079800335489&sdata=GRkcbjTJ7rSZiCrIMnXF2l5c0wS1h4GVfPkyCnRkNYU%3D&am | p;reserved=0 | | Since then I only use | | git clean -dfxq && git submodule foreach git clean -dfxq | | which worked reliably for me (beware that this removes any untracked | file). Maybe this helps? | | Cheers, | Stefan | | On Tue, Jan 28, 2020 at 10:41:33AM +0000, Simon Peyton Jones via ghc-devs | wrote: | > I did "sh validate --legacy" which uses "make maintainer-clean". | > | > I'll try again to double check. Is there any particular file I should | remove? | > | > Simon | > | > | -----Original Message----- | > | From: Ben Gamari <ben@smart-cactus.org> | > | Sent: 27 January 2020 18:59 | > | To: Simon Peyton Jones <simonpj@microsoft.com>; ghc-devs <ghc- | > | devs@haskell.org> | > | Subject: RE: stage2 build fails | > | | > | Simon Peyton Jones <simonpj@microsoft.com> writes: | > | | > | > | Indeed it would be nice to know which compiler you are using to | > | > | bootstrap. I suspect Sylvain is correct that the alternative can | be | > | > | removed but first I would like to understand why this is arising | only | > | > | now. | > | > | > | > I'm using 8.6.4 as my bootstrap compiler. But this message occurs | only | > | when compiling the *stage2* compiler with the *stage1* compiler. At | that | > | moment the bootstrap compiler is irrelevant. | > | > | > | > It's as if the build system doesn't know that the stage1 compiler | is >= | > | 8.10 | > | > | > | Hmm, interesting. Has this tree been cleaned in the last month or | two? | > | I suspect that this may have something to do with the changes to the | > | GHC_STAGE macro that were merged a while back (perhaps a stale header | > | file?). | > | | > | Cheers, | > | | > | - Ben | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd26147606ba1488142db08d7 | a3e5bbce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637158079800335489&a | mp;sdata=Lp01b0COxfxCitC%2BsmSUKlbOTKZhFwY4H%2FdNff2PdAc%3D&reserved=0

Simon Peyton Jones <simonpj@microsoft.com> writes:

git clean -dfxq && git submodule foreach git clean -dfxq

That made it work! Thank you.

(Of course I have no idea *what* file 'make maintainer-clean' isn't removing, but maybe we should not worry over-much.)

Right, given that this only occurs with the make build system my inclination has been to just live with it until we finally switch to Hadrian. Out of curiosity, is there a reason you are not using Hadrian in this tree? Cheers, - Ben

Simon Peyton Jones <simonpj@microsoft.com> writes:

| Out of curiosity, is there a reason you are not using Hadrian in this | tree?

Yes... I tried again three weeks ago and ran into several obstacles that I asked about on ghc-devs at the time. I'd be happy to re-state them when it's a good time to do so.

Ahh yes, #17534. I've been working around this when it occurs by removing the dyn_o errant file. However, I agree that this gets rather tiresome. We'll have to prioritize this. Cheers, - Ben