Cabal solver shall consider *-extensions

[hvr]

I thought I had seen this feature request filed ages ago, but couldn't find it (the closest related side-comment I did find was #335 (comment)). In any case, here it is (again) explicitly:

It's possible (and afaik recommended) to list used language extensions in the .cabal file. However, that information is currently used too late, after the cabal solver has already locked into an install-plan.

Instead, the Cabal solver should regard the declared {default,other}-extensions as a dependency, and integrate that information with the solving algorithm, thereby allowing to backtrack to other package-versions/install-plans if the current compiler is known not to provide the requested language extensions

/cc @dcoutts

[23Skidoo]

Is the problem that extensions can be conditionally enabled by flags? Otherwise this could be implemented by just not considering such packages in the first place.

[hvr]

@23Skidoo yeah, that's exactly why this can't be implemented as a trivial pre-filtering step...

[kosmikus]

Yes, interesting suggestion. So this isn't quite as easy as it sounds, because the solver uses its own simplified index format right now, and discards the extensions information during an initial conversion step. So the implementation of this would have to extend the solver-specific index format with extension information. Then we'd need a mapping from GHC versions to supported extensions. Is this available somewhere already? Can one query GHC for this easily? Once we have the supported extensions available as an input to the solver, and the extended index info mentioned above, the actual filtering should be very easy.

[hvr]

@kosmikus afaik, Cabal knows which language extensions a compiler provides, see CompilerInfo API at http://hackage.haskell.org/package/Cabal-1.22.3.0/docs/Distribution-Compiler.html and http://hackage.haskell.org/package/Cabal-1.22.3.0/docs/Distribution-Simple-Compiler.html

[hvr]

PS: Here's the cabal configure check against the required *-language: and *-extensions specifications Cabal performs currently (after cabal solving):

cabal/Cabal/Distribution/Simple/Configure.hs

Lines 568 to 583 in d860aee

	-- check languages and extensions
	let langlist = nub $ catMaybes $ map defaultLanguage
	(allBuildInfo pkg_descr)
	let langs = unsupportedLanguages comp langlist
	when (not (null langs)) $
	die $ "The package " ++ display (packageId pkg_descr0)
	++ " requires the following languages which are not "
	++ "supported by " ++ display (compilerId comp) ++ ": "
	++ intercalate ", " (map display langs)
	let extlist = nub $ concatMap allExtensions (allBuildInfo pkg_descr)
	let exts = unsupportedExtensions comp extlist
	when (not (null exts)) $
	die $ "The package " ++ display (packageId pkg_descr0)
	++ " requires the following language extensions which are not "
	++ "supported by " ++ display (compilerId comp) ++ ": "
	++ intercalate ", " (map display exts)

[kosmikus]

Ok great. Then this part is easy. So I think this makes this a relatively easy (but not quite trivial), to work on for someone who wanted to gain a little bit of understanding on how the solver works.

[dcoutts]

Yes, I think ultimately the solver should be extended to cover several other kinds of dependency in addition to libraries: build tools, language extensions, C libs etc.

For language extensions we need to know which extensions are supported by the current compiler, which we already have infrastructure for. So then once the solver is extended to accept the set of supported extensions then it's easy to plug together.

The main challenge is extending the solver to cope with multiple different kinds of dependency. For some, like build-tools they're very similar to build libs in that there is something you can install to satisfy the dependency. With language extensions (and there's some others in this category) we can treat them as fixed and so there's nothing you can install to satisfy them. This makes them a bit simpler.

[kosmikus]

Yes, let's not make this ticket more complicated than it is. For language extensions, it's a simple yes/no check, which makes this a rather low hanging fruit.

[kosmikus]

I'm working on this now.

[phadej]

Should we formulate some guidelines for default-extensions and other-extensions fields. As they are soon used by solver. E.g. I use DefaultSignatures but the usage is often guarded by cpp, should I put it in other-extensions or not?

[hvr]

@phadej fwiw, other-extensions and default-extensions are already used right now, it's just that they're checked too late (after the solver ran) by Cabal. However, there's a ticket #1517 about documenting {other,default}-extensions. I usually mirror the CPP-conditional which guards language pragmas inside the .cabal file via Cabal conditionals.

[23Skidoo]

Fixed by #2873.