update/make default GHC 9.0

[simonmichael]

Update tests, stack, CI configs for GHC 9.0. Part of #1503.

[simonmichael]

@Xitian9 in case you have some spare time: Hledger.Data.Json is producing an unstable order for object fields, or at least different between our GHC 8.10 and GHC 9.0 builds. Possibly related to the *KV code ? pairs or mconcat producing a different ordering ?

$ stack exec -- shelltest hledger/test/json.test -i1:hledger/test/json.test:1: [Failed]
Command (at line 6):
hledger -f- reg --output-format=json
Expected stdout: 
[
    [
        "2019-01-01",
        null,
        "",
        {
            "pbalanceassertion": null,
            "pstatus": "Unmarked",
            "pamount": [
                {
                    "aprice": null,
                    "acommodity": "AAA",
                    "aquantity": {
                        "floatingPoint": 1,
                        "decimalPlaces": 1,
                        "decimalMantissa": 10
                    },
                    "aismultiplier": false,
    ...(1165 more)
Got stdout:      
[
    [
        "2019-01-01",
        null,
        "",
        {
            "pdate": null,
            "poriginal": null,
            "ptags": [],
            "paccount": "a",
            "pdate2": null,
            "ptype": "VirtualPosting",
            "pbalanceassertion": null,
            "pstatus": "Unmarked",
            "pamount": [
                {
                    "aprice": null,
                    "acommodity": "AAA",
                    "astyle": {
                        "aspr...(1165 more)

         Test Cases  Total      
 Passed  0           0          
 Failed  1           1          
 Total   1           1          

I think these are the package versions used in the GHC 8.10 build:

hledger-lib-1.22
template-haskell-2.16.0.0
Decimal-0.5.2
Glob-0.10.1
aeson-1.5.6.0
aeson-pretty-0.8.8
ansi-terminal-0.11
array-0.5.4.0
base-4.14.1.0
base-compat-batteries-0.11.2
blaze-markup-0.8.2.8
bytestring-0.10.12.0
call-stack-0.3.0
cassava-0.5.2.0
cassava-megaparsec-2.0.2
cmdargs-0.10.21
containers-0.6.2.1
data-default-0.7.1.1
directory-1.3.6.0
doctest-0.18.1
extra-1.7.9
file-embed-0.0.14.0
filepath-1.4.2.1
hashtables-1.2.4.1
megaparsec-9.0.1
mtl-2.2.2
old-time-1.1.0.3
parser-combinators-1.2.1
pretty-simple-4.0.0.0
regex-tdfa-1.3.1.1
safe-0.3.19
tabular-0.2.2.8
tasty-1.4.1
tasty-hunit-0.10.0.3
template-haskell-2.16.0.0
text-1.2.4.1
time-1.9.3
timeit-2.0
transformers-0.5.6.2
uglymemo-0.1.0.1
unordered-containers-0.2.14.0
utf8-string-1.0.2

And these with the GHC 9.0 build:

hledger-lib-1.22
template-haskell-2.17.0.0
Decimal-0.5.2
Glob-0.10.1
aeson-1.5.6.0
aeson-pretty-0.8.8
ansi-terminal-0.11
array-0.5.4.0
base-4.15.0.0
base-compat-batteries-0.11.2
blaze-markup-0.8.2.8
bytestring-0.10.12.1
call-stack-0.4.0
cassava-0.5.2.0
cassava-megaparsec-2.0.2
cmdargs-0.10.21
containers-0.6.4.1
data-default-0.7.1.1
directory-1.3.6.1
doctest-0.18.1
extra-1.7.9
file-embed-0.0.14.0
filepath-1.4.2.1
hashtables-1.2.4.1
megaparsec-9.0.1
mtl-2.2.2
old-time-1.1.0.3
parser-combinators-1.3.0
pretty-simple-4.0.0.0
regex-tdfa-1.3.1.1
safe-0.3.19
tabular-0.2.2.8
tasty-1.4.1
tasty-hunit-0.10.0.3
template-haskell-2.17.0.0
text-1.2.4.1
time-1.9.3
timeit-2.0
transformers-0.5.6.2
uglymemo-0.1.0.1
unordered-containers-0.2.14.0
utf8-string-1.0.2

[simonmichael]

containers-0.6.2.1 -> containers-0.6.4.1 maybe.

[Xitian9]

Perhaps related to this: haskell/aeson#837

[Xitian9]

Just random speculation here: this might be related to the change in underlying integer representation in ghc-9.0.

The question is what to do about it. The ordering of fields has never been guaranteed by the aeson library, and any choice we make may fail on other platforms or when versions change. Ideally we would find a way to test which does not care about field ordering: either with unit tests or some other non-functest. Alternately we could make sure to sort the output before printing, but this seems like unnecessary work just to make sure functests work.

[simonmichael]

If we don't find a better solution (like requiring some newer lib version that guarantees stable ordering), I think sorting outselves is a good option. Nobody cares about the performance hit at this point and it would allow us to keep testing json as we migrate to GHC 9.0. It's also more usable for users.

[Xitian9]

Actually, it looks like aeson-pretty provides an option for specifying sort order if we don't use the default configuration. I'll submit a PR.

[Xitian9]

Question: do we want to tweak the sort order so it is identical to identical to that in the tests (essentially manually defining the order: very labour intensive), or do we want a sensible order which differs from previous behaviour, like alphabetical?

[simonmichael]

We'd prefer a sensible order, it's ok to change this.

[Xitian9]

Implemented in #1618.

[simonmichael]

Thank you very much! Merging that and this, so we can now use GHC 9.0 by default.