Fix incomplete-record-updates warnings

[jhrcek]

Fixing some ghc warnings that show up in CI as discussed in #1056 (comment)

There are some issues in ghc with -fwarn-incomplete-record-updates giving false positives, e.g.
https://gitlab.haskell.org/ghc/ghc/-/issues/5728
https://gitlab.haskell.org/ghc/ghc/-/issues/17783

Some of those should be fixed in recent versions of GHC (9+),
but we can avoid them even on GHC 8 by using RecordWildCards trick mentioned here
The other instances of this warning are fixed by restructuring the code a bit to make it more obvious to GHC that all cases are handled.

[andreasabel]

Thanks for your efforts!

As it stands, I am opposed to code changes just to work around false positives in a GHC warning mechanism. If the warning is unsound, we should switch it off rather than change the code (unless we can change the code without making any sacrifices, but I do not see it here).

So I am +1 on silencing the warning with -Wno-..., ideally in a per-file basis.
I am -1 on these code changes.

[andreasabel]

I find this version (with the magic dots .. in the record update) harder to comprehend. I consider this a fringe feature of GHC Haskell (I am seeing it for the first time now).
There might be some risks of unintentionally introducing bugs by shadowing one of the record fields introduced by the .. pattern which is then picked up by the .. update, is there?

I think that in the contrary we should strive to get rid of all the .. magic and be more explicit about what is in scope.

So, I'd rather not change code to work around an incorrect GHC warning mechanism. Rather switch off the warning.

[andreasabel]

Same here, I am opposed.

[jhrcek]

It's not that -fwarn-incomplete-record-updates is unsound.
It actually found bunch of places that could potentially fail at runtime with incomplete pattern marches.
The only issue is that GHCs prior to version 9 can give this warning even for some cases where the failure condition provably cannot happen. I removed the usage of RecordWildCards from my PR. Let me know if you're against even this less invasive vefsion of the fixes and I'll close this PR.
Btw. any idea why CI is failing on 9.0.2?

[andreasabel]

Btw. any idea why CI is failing on 9.0.2?

Yes, this is mysterious. I am suspecting that the package-db caching is unsound:

hackage-server/.github/workflows/ci.yml

Lines 41 to 47 in 71bc801

	- name: Cache cabal global package db
	id: cabal-global
	uses: actions/cache@v2
	with:
	path: |
	~/.cabal
	key: ${{ runner.os }}-${{ matrix.versions.ghc }}-${{ matrix.versions.cabal }}-cabal-global-${{ hashFiles('cabal.project') }}

I am pushing a new, idiomatic CI from

• Auto-generate more complete CI via haskell-ci #1061

[andreasabel]

I am ok with this modified PR. Using \case would be a cosmetical improvement.
If you rebase this PR onto master, I hope the CI will succeed!

[jhrcek]

Thank you for updating CI, LambdaCase suggestion applied.

[andreasabel]

Thanks, @jhrcek !