upgrade to ghc-9.4 parse tree

[shayne-fletcher]

• this pr migrates hlint to the ghc-9.4.1 parse tree
• the minimum ghc version for building hlint with this pr becomes ghc-9.0.1
  • accordingly i've removed 8.10 from .github/workflws/ci.yml
  • of course with 9.4.1 being now available, one hopes we can add 9.4 to that matrix in the near future
• regarding issue Flip ghc-lib default to True #1385:
  • ghc-lib-parser-ex switched to always linking ghc-lib-parser by default in pr switch auto default to false shayne-fletcher/ghc-lib-parser-ex#123
  • the companion change to hlint in pr Flip ghc-lib default to True #1385 has yet to land been abandoned in light of this PR being accepted
  • since the choice of defaults must be consistent between these two packages, replicate Flip ghc-lib default to True #1385 in this pr accordingly

[shayne-fletcher]

sadly, this pr fails with macOS 9.2.2 same as #1385. fixed in 9.2.3 and note also that 9.2.2 is now two minor versions behind (ghc-9.2.4 was released early aug). perhaps it's worth reconsidering if we might patch 'ci.yml' as per this comment #1385 (comment)?

[shayne-fletcher]

i think we'll be needing @ndmitchell 's final say on this & its timing but nonetheless, if you have the time & patience, your review would be very welcome @zliu41 😊 🙏 !

[ndmitchell]

Nice work!

[ndmitchell]

Good call - this seems like the right time to flip this default

[shayne-fletcher]

jolly good. i've taken the liberty of pushing the change to ci.yml then that bumps the macOS compiler to ghc-9.2.3 .

[sol]

@ndmitchell @shayne-fletcher what's the rationale for this change?

For ormolu I was proposing to use ghc by default when possible (tweag/ormolu#948). Are there any potential drawbacks with that?

[shayne-fletcher]

@sol the motivation is discussed in #1376. i don't know of any drawbacks. you may find this blog post helpful.

[shayne-fletcher]

fixes #1376

[ndmitchell]

Thanks Shayne! I did leave some notes, which it appears GitHub completely dropped, so from memory:

of course with 9.4.1 being now available, one hopes we can add 9.4 to that matrix in the near future

What stops us from doing that now?

perhaps it's worth reconsidering if we might patch 'ci.yml' as per this comment

Why is what we get in CI lagging so far behind?

[shayne-fletcher]

What stops us from doing that now?

i just did a quick foray to find out:

• ghc-9.4.1 was released sun 2022-08-07 (just this week):

  • there's an install issue on macOS (at least):

    • i've patched my local install to work-around this

    • expect ghc-9.4.2 to be released this week to fix that:

      • see https://www.mail-archive.com/[email protected]/msg20589.html

  • we don't have CI testing of ghc-lib-parser, ghc-lib-parser-ex w/9.4.1 yet

    • i have however verified my local builds via cabal w/9.4.1:

      • ghc-lib-parser, ghc-lib-parser-ex & hlint (9.4 parse tree)
• now regarding hlint CI:

  • seems we can't say ghc: ['9.4', ...] in ci.yml for ubuntu-latest:

    • see https://github.com/ndmitchell/hlint/runs/7809786617

  • seems we can't say ghc: '9.4' in ci.yml for windows-latest:

    • see https://github.com/ndmitchell/hlint/runs/7809894556

  • we can however say ghc: ['9.4.1', ...] for ubuntu-latest & ghc: '9.4.1' for windows-latest

    • here i skip macOS-latest due to the install issue mentioned above

  • however, both of these builds fail on ghc-exactprint (needed for apply-refact-0.10.0.0) (@zliu41 any chance you might be able to help with this? 🙏)

    • see https://github.com/ndmitchell/hlint/runs/7809368346:

            Building library for ghc-exactprint-1.5.0..
            [ 1 of 10] Compiling Language.Haskell.GHC.ExactPrint.Orphans ( src\Language\Haskell\GHC\ExactPrint\Orphans.hs, dist\build\Language\Haskell\GHC\ExactPrint\Orphans.o )
        
            src\Language\Haskell\GHC\ExactPrint\Orphans.hs:55:18: error:
            Error:     Not in scope: type constructor or class ‘AnnsLet’
            cabal.exe: Failed to build ghc-exactprint-1.5.0 (which is required by
               |
            exe:refactor from apply-refact-0.10.0.0). See the build log above for details.
            55 | instance Default AnnsLet where
               |                  ^^^^^^^

Why is what we get in CI lagging so far behind?

sorry, i have no skills in this area - i'm just cargo-culting from what i find here. perhaps you have a contact somewhere you might ask for us?

[shayne-fletcher]

What stops us from doing that now?

we may find ourselves waiting on some package upgrades also. for example, the ghc-lib project (ghc-lib-gen's dependence on aeson mostly i think) indicates that the upper-bounds of at least these packages need relaxing to be built with ghc-9.4.1:

OneTuple
splitmix
attoparsec
scientific
hashable
integer-logarithms
primitive
scientific
data-fix
aeson
indexed-traversable
semialign
indexed-traversable-instances
unordered-containers
assoc
these
text-short
time-compat
uuid-types
split

[shayne-fletcher]

What stops us from doing that now?

we may find ourselves waiting on some package upgrades also. for example, the ghc-lib project (ghc-lib-gen's dependence on aeson mostly i think) indicates that the upper-bounds of at least these packages need relaxing to be built with ghc-9.4.1:

[...]

hmmm... now that i reflect on it, likely this won't be an issue for us since after all, we got a build plan just fine with my local 9.4.1 builds & it would seem, our CI forays above 😊