Build with aeson >= 2.0

[jneira]

• I am continuing @Anton-Latukha's work from try enable brittany #2473 in this branch https://github.com/jneira/haskell-language-server/tree/brittany-9.0.1

• As the new version of brittany needs aeson >= 2.0 we have to jump into that wagon (or patch brittany to support aeson <= 2.0 and ghc-9.0.1 at same time)

• So we have to go down the rabbit hole to get aeson-2 for ghc >= 9.01:

  • Support aeson >= 2.0 ennocramer/floskell#68
  • On Hackage lsp-types release restricts to aeson <1.6 lsp#373
  • Add support for aeson >= 2.0 stylish-haskell#387

• Upstream brittany deps which need support for ghc-9.0.1 (so needed to make available brittany+9.0.1 in hackage)

  • multistate: Allow base 4.15 lspitzner/multistate#8
  • data-tree-print: Allow base < 4.17 and ghc <= 9.2.1 lspitzner/data-tree-print#3
  • butcher: Support for base-4.15 and ghc-9.0.* lspitzner/butcher#8

• Needed to support aeson-2 for ghc < 9.0.1 (not mandatory)

  • Consider backport support for extras >=1.7.10 and aeson >= 2.0 to hlint-3.2 ndmitchell/hlint#1328
  • Brittany support for aeson-2.0 + ghc < 9.0.1

[jneira]

Of course floskell is not buildable with aeson >= 2.0:

src/Floskell/ConfigFile.hs:93:26: error:
Error:     • Couldn't match type: HashMap.HashMap k0 JSON.Value
                     with: Data.Aeson.KeyMap.KeyMap JSON.Value
      Expected: JSON.Object
        Actual: HashMap.HashMap k0 JSON.Value
    • In the first argument of ‘JSON.Object’, namely
        ‘(HashMap.unionWith mergeJSON l r)’
      In the expression: JSON.Object (HashMap.unionWith mergeJSON l r)
      In an equation for ‘mergeJSON’:
          mergeJSON (JSON.Object l) (JSON.Object r)
            = JSON.Object (HashMap.unionWith mergeJSON l r)
   |
93 |             JSON.Object (HashMap.unionWith mergeJSON l r)
   |                          ^^^^^^^^^^^^^^^

[jneira]

or patch brittany to support aeson <= 2.0 and ghc-9.0.1 at same time

given aeson >= 2.0 inlcudes an important security related patch i think we should try to use it here

[jneira]

PR to add aeson >= 2.0 to floskell: ennocramer/floskell#69

[jneira]

hls-plugin-api needs to be patched, several errors like:

src\Ide\Plugin\Properties.hs:240:25: error:
Error:     • Couldn't match expected type ‘A.Key’ with actual type ‘T.Text’
    • In the second argument of ‘(A..:)’, namely ‘keyName’
      In a stmt of a 'do' block: txt <- o A..: keyName
      In the expression:
        do txt <- o A..: keyName
           if txt `elem` enumValues then
               pure txt
           else
               fail
                 $ "invalid enum member: "
                     <> show txt <> ". Expected one of " <> show enumValues
    |
240 |           txt <- o A..: keyName

    | 

the fix should be backwards compatible as we have to support libraries with only support for aeson < 2.0 (hlint-3.2) or aeson >= 2.0 (brittany)

[jneira]

After checking master version of lsp packages works with hls, including the test suite, will release new versions

[michaelpj]

I suspect we can sort out hls-plugin-api in a way that works nicely both pre- and post-2.0

[jneira]

I suspect we can sort out hls-plugin-api in a way that works nicely both pre- and post-2.0

@michaelpj
haskell/aeson#881 (comment) suggests create a fromKey/toKey and make it work with Text and Aeson.Key using CPP but i would love to do it without cpp conditions (like you did for lsp, using hte Aeson api differently)

[jneira]

stylish-haskell also would need support for aeson >= 2.0: haskell/stylish-haskell#387

[jneira]

And packages (hls-plugin-api, ghcide,..) need to be adapted to the new lsp version, which supports in turn aeson-2.
As the aeson-2 thin is getting more complex, i would focus in lsp packages first, leveraging @michaelpj work here: https://github.com/michaelpj/haskell-language-server/tree/mpj/wip-hls-lsp-upgrade
I am continuing the work there in this one https://github.com/haskell/haskell-language-server/tree/hls-lsp-upgrade

[michaelpj]

given aeson >= 2.0 inlcudes an important security related patch i think we should try to use it here

Just to reiterate on this, I'm fairly sure that the security issue is not relevant for HLS as it isn't parsing untrusted input.

[jneira]

I am gonna reopen to track the possible use of aeson 2 for ghc < 9.0.1 and brittany upstream deps needing support for ghc >= 9.0.1

[michaelpj]

I am gonna reopen to track the possible use of aeson 2 for ghc < 9.0.1

Do we need to do this?

[jneira]

I am gonna reopen to track the possible use of aeson 2 for ghc < 9.0.1

Do we need to do this?

No strictly, but we can take ride of some pesky fromString . unpack which can be reaplaced with directs Aeson.Key.fromText.
And well we could use new aeson-2.x versions with possible new bug fixes or perf improvements for ghc < 9.0.1

[michaelpj]

IMO it's not worth spending lots of effort on. We can force it once we're only supporting GHC 9 :p

[jneira]

IMO it's not worth spending lots of effort on. We can force it once we're only supporting GHC 9 :p

agree, we are also tracking here stylish-haskell and Brittany deps support for aeson/ghc-9.0 but maybe we could move that to the ghc-9.0 support and close this

will do

[jneira]

ok, i've moved the pending tasks to #297 and give up on get aeson-2.0 support for ghc < 9.0.1 so closing this