Enable two warnings (#1245)

[tomjaguarpaw]

because they will be soon be added to -Wall.

See https://gitlab.haskell.org/ghc/ghc/-/issues/15656

I already made this contribution against the ghc-8.10 branch, which in retrospect I think was not where I should have made it. It's fine on that branch, it's just not particularly useful. To get it into new builds of GHC I think I need it on the ghc-head branch. Sorry for the repeated request.

[alexbiehl-gc]

Thanks! CI won't turn green on head branch these days but I will take care of any fallouts.

[bgamari]

@tomjaguarpaw as far as I can tell this does not compile with current GHC master. I'm afraid I'm going to have to revert as it's currently blocking progress in GHC.

@alexbiehl, in general I think it would be best if we don't merge things to ghc-head until we know that they build and the corresponding GHC merge requests are queued. Things become very messy if haddock and ghc evolve in different orders.

[alexbiehl]

@bgamari Makes sense. Sorry for the inconveniences.

[tomjaguarpaw]

@bgamari Where should I put my Haddock commits then? They somehow need to get into this repository so that they are mirrored on Gitlab so that I can update the utils/haddock submodule.

[tomjaguarpaw]

@bgamari says on IRC that I should make a wip/ branch in Gitlab.

[bgamari]

To mirror what I said on IRC: the workflow for getting haddock changes into GHC (documented here) is:

1. push your branch to a wip/ branch on https://gitlab.haskell.org/ghc/haddock (and your GitHub fork, if you want)
2. open a GHC merge request bumping the haddock submodule.
3. wait for the merge request to pass CI and get approval
4. push your haddock changes to GitHub (if you haven't already) and request that they be merged to the ghc-head branch
5. wait for the GitHub MR to be merged; after it's merged queue up the GHC MR for merge

@alexbiehl, I've long thought that things would be simplified if the haddock repository were moved to GitLab; is this something you would be open to discussing?

[alexbiehl-gc]

@bgamari I agree. Unfortunately Haddock and GHC are very tightly coupled. I have even thought about arguing for Haddock to move into the GHC repo but from experience there are more Haddock releases than for GHC so tracking them in a mono repo probably takes the flexibility for different release cadence. But still they are circular dependencies build wise.

Do you have a vision for a simplified development process once we moved over to GitLab? They would still be separate repositories as far as I understand so the general setup won't change that drastically? Is there a GitLab feature that would help us coordinate MRs over several repositories maybe?

On a more tangential note, one thing I am trying to achieve for some time now is to have Haddocks test-suite run on ghc-head branch - it's shown to be a hard problem. My hope is that we can make it possible with the measures we take.

In general, improving matters would be very much appreciated. And I am willing and able to help.