Relax upper bound on Cabal dependency

[mpilgrem]

Tested by building Hpack on Windows with a dependency on Cabal-3.10.1.0 (which is provided by GHC 9.6.1).

[sol]

This looks good 👍

We can't currently merge this as the test suite doesn't build. Either we need to get rid of the problematic dependencies, or wait until the test dependencies catch up.

@mpilgrem for the time being can you add a Hackage meta data revision? I added you to the maintainer group.

[mpilgrem]

@sol, I have revised the package description on Hackage. I'll see if I can help bump the packages on which the hpack tests depend.

[mpilgrem]

The test's dependency on haskell-src-meta has been updated and all the tests now pass except for Windows/GHC system (the GitHub-hosted runner provides GHC 9.6.1). Something quite odd seems to be happening with GHC 9.6.1 and the network-3.1.2.8 package.

2023-03-22T18:25:24.4876444Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\network-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c\lib\libHSnetwork-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c.a: unknown symbol `__mingw_vsprintf'
2023-03-22T18:25:24.4878193Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\network-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c\lib\libHSnetwork-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c.a: unknown symbol `getWSErrorDescr'
2023-03-22T18:25:24.4883582Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\network-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c\lib\libHSnetwork-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c.a: unknown symbol `networkzm3zi1zi2zi8zma94109d985a3fd357964536a98a836f98063395c_NetworkziSocketziInternal_withSocketsInit_closure'
2023-03-22T18:25:24.4886599Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\network-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c\lib\libHSnetwork-3.1.2.8-a94109d985a3fd357964536a98a836f98063395c.a: unknown symbol `networkzm3zi1zi2zi8zma94109d985a3fd357964536a98a836f98063395c_NetworkziSocketziBuffer_zdwsendBuf_closure'
2023-03-22T18:25:24.4890594Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\tls-1.6.0-7469c75440b0f5a3c4f86b6656eebeb1e2602c71\lib\libHStls-1.6.0-7469c75440b0f5a3c4f86b6656eebeb1e2602c71.a: unknown symbol `networkzm3zi1zi2zi8zma94109d985a3fd357964536a98a836f98063395c_NetworkziSocketziByteStringziIO_zdwrecv_closure'
2023-03-22T18:25:24.4894576Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\tls-1.6.0-7469c75440b0f5a3c4f86b6656eebeb1e2602c71\lib\libHStls-1.6.0-7469c75440b0f5a3c4f86b6656eebeb1e2602c71.a: unknown symbol `tlszm1zi6zi0zm7469c75440b0f5a3c4f86b6656eebeb1e2602c71_NetworkziTLSziBackend_zdtcBackend_closure'
2023-03-22T18:25:24.4898783Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\connection-0.3.1-644b48b4c7eedf60f5f889483800658cde602d9b\lib\libHSconnection-0.3.1-644b48b4c7eedf60f5f889483800658cde602d9b.a: unknown symbol `tlszm1zi6zi0zm7469c75440b0f5a3c4f86b6656eebeb1e2602c71_NetworkziTLSziContextziInternal_zdtcContext_closure'
2023-03-22T18:25:24.4903236Z ghc-9.6.1.exe:  | C:\cabal\store\ghc-9.6.1\http-client-t_-0.3.6.1-d7c73eb524e98153a6dfec921b441b65244eec1e\lib\libHShttp-client-t_-0.3.6.1-d7c73eb524e98153a6dfec921b441b65244eec1e.a: unknown symbol `connectionzm0zi3zi1zm644b48b4c7eedf60f5f889483800658cde602d9b_NetworkziConnectionziTypes_SockSettingsSimple_con_info'
2023-03-22T18:25:24.4907091Z ghc-9.6.1.exe:  | D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.1\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o: unknown symbol `httpzmclientzmtzuzm0zi3zi6zi1zmd7c73eb524e98153a6dfec921b441b65244eec1e_NetworkziHTTPziClientziTLS_tlsManagerSettings_closure'
2023-03-22T18:25:24.4908827Z ghc-9.6.1.exe: Could not load Object Code D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.1\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o.
2023-03-22T18:25:24.4909260Z 
2023-03-22T18:25:24.5055664Z 
2023-03-22T18:25:24.5056064Z <no location info>: error: 
2023-03-22T18:25:24.5058806Z [49 of 53] Compiling Hpack            ( src\Hpack.hs, D:\\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.1\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack.o )
2023-03-22T18:25:24.7813561Z [50 of 53] Compiling HpackSpec        ( test\HpackSpec.hs, D:\\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.1\hpack-0.35.2\t\spec\build\spec\spec-tmp\HpackSpec.o )
2023-03-22T18:25:25.2804588Z [51 of 53] Compiling Hpack.CabalFileSpec ( test\Hpack\CabalFileSpec.hs, D:\\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.1\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\CabalFileSpec.o )
2023-03-22T18:25:25.2910676Z 
2023-03-22T18:25:25.2911713Z Access violation in generated code when reading 0x20
2023-03-22T18:25:25.2912161Z 
2023-03-22T18:25:25.2912421Z  Attempting to reconstruct a stack trace...
2023-03-22T18:25:25.2912700Z 
2023-03-22T18:25:25.3743412Z    Frame	Code address
2023-03-22T18:25:25.4276447Z  * 0x2271efd930	0x7ff76c5b34f6 C:\ghcup\ghc\9.6.1\bin\ghc-9.6.1.exe+0x42834f6
2023-03-22T18:25:25.4279779Z  * 0x2271efd9b0	0x7ff76b28bc1f C:\ghcup\ghc\9.6.1\bin\ghc-9.6.1.exe+0x2f5bc1f
2023-03-22T18:25:25.4283374Z  * 0x2271efd9e0	0x7ff76b28c6b8 C:\ghcup\ghc\9.6.1\bin\ghc-9.6.1.exe+0x2f5c6b8
2023-03-22T18:25:25.4286173Z  * 0x2271efd9e8	0x7ff76bd2f68f C:\ghcup\ghc\9.6.1\bin\ghc-9.6.1.exe+0x39ff68f
2023-03-22T18:25:25.4290688Z  * 0x2271efd9f0	0x7ef468b285d0
2023-03-22T18:25:25.4295193Z  * 0x2271efd9f8	0x18d15e6d090
2023-03-22T18:25:25.4299565Z  * 0x2271efda00	0x49d6d
2023-03-22T18:25:25.4303964Z  * 0x2271efda08	0x7ef464870cb8
2023-03-22T18:25:25.4304165Z 
2023-03-22T18:25:25.5388898Z Error: cabal-3.10.1.0.exe: Failed to build test:spec from hpack-0.35.2. The
2023-03-22T18:25:25.5389829Z build process terminated with exit code 11

I don't know what is causing that. I can build network-3.1.2.8 on Windows 11 with Stack and GHC 9.6.1 (with allow-newer).

[sol]

Thanks @mpilgrem.

2023-03-22T18:25:25.2911713Z Access violation in generated code when reading 0x20

This looks bad, but I assume nothing that's wrong with our code. If you would rather get this merged now than wait until a solution emerges, we could change the GHC version for the Windows build for the time being https://github.com/sol/hpack/blob/main/.github/workflows/build.yml#L39. We also want to enable 9.6 for Linux.

[sol]

Ideally, network really should be a boot library.

[mpilgrem]

I have asked at GHC's repository: https://gitlab.haskell.org/ghc/ghc/-/issues/23309.

[mpilgrem]

@sol, the solution to the GHC 9.6.1/CI/Windows glitch has been found: GHC 9.4.5 and GHC 9.6.1 need to be used with newly-released network-3.1.2.9 (haskell/network#552). I know what that would mean for Stack builds - an extra-dep in the YAML file, until the Stackage snapshots catch up - but how does it work with Cabal (the tool) builds? Should I add a network >= 3.1.2.9 dependency to the package.yaml file?

[sol]

@sol, the solution to the GHC 9.6.1/CI/Windows glitch has been found: GHC 9.4.5 and GHC 9.6.1 need to be used with newly-released network-3.1.2.9 (haskell/network#552).

Thanks @mpilgrem for digging into this.

Should I add a network >= 3.1.2.9 dependency to the package.yaml file?

From what I understand TheRightSolution™ would be to add Hackage revisions for network < 3.1.2.9.

Those revisions should make sure that network < 3.1.2.9 will not be selected for GHC 9.4.5 / 9.6.1 on Windows. I would hope that something like

if impl(ghc >= 9.4.5) && os(windows)
  buildable: false

will work.

@andreasabel do you think this is appropriate? Can you help with this?

Alternatively, or in addition, we can constrain network in package.yaml. We could again do something like:

when:
  condition: impl(ghc >= 9.4.5) && os(windows)
  dependencies: network >= 3.1.2.9

But maybe constraining network unconditionally is simpler / more robust.