chore: [sc-129896] Upgrade Smurf to GHC 9.2

[codygman]

Story details: https://app.shortcut.com/itprotv/story/129896

I found that hls didn't work with ghc 9.2.4 because of what looks like an ABI error:

clang: error: no such file or directory: '/home/haskell/.cache/hie-bios/dist-smurf-a918fb5fb0f5015a988835da60f0159d/build/aarch64-linux/ghc-9.2.4/recurly-0.0.0.1/noopt/build/Recurly/V3/API/Types/Coupon/Name.dyn_o'
`clang' failed in phase `Linker'. (Exit code: 1)

It just so happens that ghc 9.2.5 release notes has some potentially related items in the changelog:

***** Improve determinism by not inclusing build directories in interface files (#22162).

***** Fix a code generation bug with the native code generator on aarch64 darwin leading to runtime segmentation faults due to an incorrect ABI (#21964)

hls doesn't support 9.2.5 in it's 1.8.0.0 release, but compiling from source as this PR does should (still waiting to test).

Would close #12

---

• I manually tested the code locally to make sure that it works.
• If there is documentation, I made sure it's accurate and up to date.
• If possible, I wrote automated tests for the new behavior.

[codygman]

I can come back and make a conditional here to install 1.8 for 9.0.2 if we really want, but I'd prefer to get things working end to end in smurf first.

[tfausak]

Here is what I'd like:

• If configured to do so, install HLS from source.
• Otherwise attempt to install HLS via GHCup.
• Or do nothing.

I feel like the easiest way to support that would be to have two environment variables: HLS_GIT_REF and HLS_VERSION. If HLS_GIT_REF is set, HLS will be compiled from source using ghcup compile hls -g $HLS_GIT_REF. Otherwise, if HLS_VERSION is set, HLS will be installed using ghcup install hls $HLS_VERSION. If neither are set, HLS is not installed.

Or perhaps we could try to be fancy by keeping the single HLS_VERSION variable and checking to see if it looks like a commit. If it does, compile; otherwise install.

if echo "$HLS_VERSION" | grep --extended-regexp --quiet '^[0-9a-f]{40}$'
then echo compile
else echo install
fi

For example:

$ if echo '1.8.0.0' | egrep -q '^[0-9a-f]{40}$'; then echo compile; else echo install; fi
install

$ if echo '5d56aa70a84807d7659e72eacd4d91fee08dbdbb' | egrep -q '^[0-9a-f]{40}$'; then echo compile; else echo install; fi
compile

That way we can use HLS_VERSION=1.8.0.0 for GHC_VERSION=9.0.2 (as we currently do), but also support HLS_VERSION=5d56aa70a84807d7659e72eacd4d91fee08dbdbb for GHC_VERSION=9.2.5 and GHC_VERSION=9.4.3.

What do you think?

[tfausak]

I was curious how this impacted the final image size:

• This branch's image (public.ecr.aws/acilearning/haskell:9.2.5-dd2f65799eb8e64913382a2c299e932608b5fa20) is 531 MB.
• The default branch's image (public.ecr.aws/acilearning/haskell:9.2.4-08f0de6f7cf16cb1707e97ce43370b0649faf1fd) is 632 MB.

So this branch is ... smaller? That's not what I expected. But that's great!

[tfausak]

I think that HLS was not actually installed: https://github.com/acilearning/docker-haskell/actions/runs/3432059625/jobs/5720913699#step:3:951

/bin/sh: 1: 9.2.5: not found

The command that failed was test -n "$HLS_VERSION" && "$GHC_VERSION" == "9.2.5". The && is not interpreted as part of the conditional. Instead it's running the second command only if the first one succeeded. I think what you meant instead was test -n "$HLS_VERSION" -a "$GHC_VERSION" = '9.2.5'.