extensions >= 0.1.0.1 not compatible with GHC 9.4.8

[ulidtko]

This is to document a consequence of #87 — because of DeepSubsumption and other new extensions, currently the last version of extensions buildable on GHC 9.4.8 is 0.1.0.0.

Versions 0.1.0.1 onwards emit:

src/Extensions/Cabal.hs:393:5: error:
    Not in scope: data constructor ‘Cabal.DeepSubsumption’
    NB: the module ‘Language.Haskell.Extension’ does not export ‘DeepSubsumption’.
    |
393 |     Cabal.DeepSubsumption                   -> Nothing
    |     ^^^^^^^^^^^^^^^^^^^^^

src/Extensions/Cabal.hs:394:5: error:
    Not in scope: data constructor ‘Cabal.TypeData’
    NB: the module ‘Language.Haskell.Extension’ does not export ‘TypeData’.
    |
394 |     Cabal.TypeData                          -> Nothing
    |     ^^^^^^^^^^^^^^

and similar errors — because GHC 9.4.8 shipped with Cabal-syntax == 3.8.1.0 which did not name those extensions.

---

Then, because GHC 9.4.8 is EOL "not recommended for use" — I'm not really asking for any change or support here; @tomjaguarpaw just for your (and others') information.

I could perhaps suggest having empty #else branch here:

extensions/src/Extensions/Cabal.hs

Lines 389 to 395 in 20142a9

	#if __GLASGOW_HASKELL__ >= 906
	Cabal.DeepSubsumption -> Just DeepSubsumption
	Cabal.TypeData -> Just TypeData
	#else
	Cabal.DeepSubsumption -> Nothing
	Cabal.TypeData -> Nothing
	#endif

i.e.

#if __GLASGOW_HASKELL__ >= 906
    Cabal.DeepSubsumption                   -> Just DeepSubsumption
    Cabal.TypeData                          -> Just TypeData
#endif

— IIUC, this'd still give complete case-analysis over all available constructors (in GHC <9.6 / Cabal < 3.10) and avoid compile warnings.

But then again, it's a maintainer decision how far back to keep support.

---

I think a similar issue would also occur with RequiredTypeArguments & GHC <9.10, due to here:

extensions/src/Extensions/Cabal.hs

Lines 396 to 403 in 20142a9

	#if __GLASGOW_HASKELL__ >= 910
	-- This branch cannot be satisfied yet but we're including it so
	-- we don't forget to enablel RequiredTypeArguments when it
	-- becomes available.
	Cabal.RequiredTypeArguments -> Just RequiredTypeArguments
	#else
	Cabal.RequiredTypeArguments -> Nothing
	#endif

@tomjaguarpaw why can't this be with empty #else ?

#if __GLASGOW_HASKELL__ >= 910
    -- This branch cannot be satisfied yet but we're including it so
    -- we don't forget to enablel RequiredTypeArguments when it
    -- becomes available.
    Cabal.RequiredTypeArguments             -> Just RequiredTypeArguments
#endif

[tomjaguarpaw]

Actually, is this not to do with the Cabal-syntax package version rather than the GHC version? That's where Language.Haskell.Extension comes from.

[ulidtko]

@tomjaguarpaw yes, exactly; Cabal-syntax is a boot package, and so its version is interchangeable with GHC version.

Which is why the code is justified to version-check __GLASGOW_HASKELL__ >= 906 instead of MIN_VERSION_Cabal_syntax(3,10,0) — both version checks are basically equivalent, as versions of GHC and of cabal-syntax are in 1-to-1 correspondence (because the latter ships bundled with GHC, and is practically not upgradable).

In other words, code like this would do the same, expressing the intent more precisely & directly:

-- #if __GLASGOW_HASKELL__ >= 906 
 #if MIN_VERSION_Cabal_syntax(3,10,0) 
     Cabal.DeepSubsumption                   -> Just DeepSubsumption 
     Cabal.TypeData                          -> Just TypeData 
 #else 
     Cabal.DeepSubsumption                   -> Nothing 
     Cabal.TypeData                          -> Nothing 
 #endif 

Then my argument is, it's more correct to say:

 #if MIN_VERSION_Cabal_syntax(3,10,0) 
     Cabal.DeepSubsumption                   -> Just DeepSubsumption 
     Cabal.TypeData                          -> Just TypeData 
 #endif 

without the #else branch — because with Cabal-syntax < 3.10, Language.Haskell.Extension.DeepSubsumption is not a definition, so it's never correct to refer to it.

And similarly for the other version checks.

[tomjaguarpaw]

There must be something missing from this story, because extensions on 9.4.8 does compile:

https://github.com/kowainik/extensions/actions/runs/15343334330/job/43174106068

This also succeeds, so cabal-syntax seems upgradeable:

% cabal repl -w ghc-9.4.8 -z -b extensions==0.1.0.1
Resolving dependencies...
Build profile: -w ghc-9.4.8 -O1
In order, the following will be built (use -v for more details):
 - Cabal-syntax-3.10.3.0 (lib) (requires download & build)
 - Cabal-3.10.3.0 (lib) (requires download & build)
 - extensions-0.1.0.1 (lib) (requires build)
 - fake-package-0 (interactive) (lib) (first run)
Downloading  Cabal-syntax-3.10.3.0
Downloaded   Cabal-syntax-3.10.3.0
Downloading  Cabal-3.10.3.0
Starting     Cabal-syntax-3.10.3.0 (lib)
Downloaded   Cabal-3.10.3.0
Building     Cabal-syntax-3.10.3.0 (lib)
Installing   Cabal-syntax-3.10.3.0 (lib)
Completed    Cabal-syntax-3.10.3.0 (lib)
Starting     Cabal-3.10.3.0 (lib)
Building     Cabal-3.10.3.0 (lib)
Installing   Cabal-3.10.3.0 (lib)
Completed    Cabal-3.10.3.0 (lib)
Starting     extensions-0.1.0.1 (lib)
Building     extensions-0.1.0.1 (lib)
Installing   extensions-0.1.0.1 (lib)
Completed    extensions-0.1.0.1 (lib)
Configuring library for fake-package-0...
Warning: No exposed modules
GHCi, version 9.4.8: https://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /tmp/cabal-repl.-565939/setcwd.ghci
ghci> 

[ulidtko]

Ah, so this is where I had a wrong assumption...

is practically not upgradable

Evidently, it is. 💡

What this means for distro packagers @tomjaguarpaw, is a need to backport cabal-syntax to a newer version than the one in GHC boot libs (for older GHCs + newest extensions). Not really sure if shadowing boot-libs in this manner entails more issues or not.

[tomjaguarpaw]

I guess extensions is at fault here, and we should guard by cabal-syntax version.

[ulidtko]

What do you think of widening this version bound?

extensions/extensions.cabal

Lines 88 to 97 in e654ff8

	-- We need to pin a single major version of
	-- Cabal here because the main reason we use
	-- Cabal is for its list of extensions. Later
	-- versions have strictly more extensions, and
	-- we'll have missing patterns if we try to
	-- support more than one major version. If
	-- this causes problems in practice let's
	-- revisit this decision and come up with
	-- another approach.
	, Cabal ^>= 3.14

By means of

1. changing #if __GLASGOW_HASKELL__ >= 906 to #if MIN_VERSION_Cabal_syntax(3,10,0)
2. removing the #else cases

Edit: I can propose a PR if it sounds good

[tomjaguarpaw]

That sounds like the "right" thing to do, but I dread the CI matrix that we're going to have to implement to confirm that all relevant combinations of cabal and GHC versions work correctly together. Is it really not possible for all users to use Cabal 3.14 in practice?

[ulidtko]

ArchLinux still hasn't updated to 9.6 even — so I'm afraid no, that'd be a very long shot 😔

Edit: I'll see what I can do with the CI

[tomjaguarpaw]

But as we've established, Cabal 3.14 is compatible with 9.4, so why does it matter if Arch hasn't updated to 9.6?

[ulidtko]

Oh, because of the initially posted compile error in extensions — despite using very little from the library, extensions can't be built with Cabal-syntax == 3.8.1.0 from GHC 9.4 bootlibs (without additional backports).

I.e. I'm not claiming to be blocked — extensions latest is certainly installable with 9.4; it just requires additional backporting effort for library packagers, and the unsavory multi-version bootlibs package shadowing situation.

[tomjaguarpaw]

I don't understand how the compile error can happen though. extensions-0.1.0.1 depends on Cabal ^>= 3.10 (https://hackage.haskell.org/package/extensions-0.1.0.1) and Cabal-syntax 3.10 has DeepSubsumption: https://hackage.haskell.org/package/Cabal-syntax-3.10.1.0/docs/Language-Haskell-Extension.html#t:KnownExtension

Surely there should just be a bounds error?

[ulidtko]

I'm planning to bring this up for discussion with Arch maintainers, but they're doing something nasty with haskell packages 😔 There's a tool that's often used to "pre-process" cabal-files when wrapping them into arch packages. The default modus operandi of that tool is to erase all version bounds.

So, that's how. 😒

[tomjaguarpaw]

Ah OK!

So do we agree that extensions >= 0.1.0.1 is actually compatible with GHC 9.4.8? And if so the bug report perhaps belongs on an Arch tracker then?

[ulidtko]

@tomjaguarpaw I'm super confident that the only outcome that'll lead to, will be a recommendation to communicate with upstream (which I'm doing here already) — and if that fails, a vendor-patch.

Everyone would be better off without vendor patches, if at all possible.

(And currently, the issue has led to an extensions == 0.1.0.0 pin)

I generally think it's good courtesy for libraries to declare as wide dependency requirements as is sensible; this makes things easier on consumers' end. As the maintainer, you're of course in position to insist on "latest cabal only" in this case, but IMO it's unnecessarily restrictive, and could be substantially relaxed.