After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev 57b193d8dd
result/bin/apply-formatting $NIXPKGS_PATH
Since we now have a versioned configuration-ghc-*.nix file for GHC HEAD,
we don't need to add a super special case to the package set logic in
test-configurations.nix anymore. We can just create a versioned
attribute for the ghcHEAD package set (which is not exposed) and keep
using the normal discovery logic.
The only tricky bit is that GHC HEAD's configuration file is named after
the GHC release that will be branched off from it, so a little bit of
arithmetic is involved.
configuration-nix.nix uses builtins.intersectAttrs to not any overrides
for packages not present in `super` (presumably for use outside of
nixpkgs?). To accomodate it, we pass an attribute set with every
attribute of haskellPackages, but set to `null` as `super`, and — while
we're at it — a fix point as `self`.
While being able to test them is neat (on x86_64-linux they work very
well, actually), we usually don't want to do this, since the set is
only (recommended to be) used to bootstrap GHC. Consequently there is
almost no binary cache and testing them mostly leads to unenlightening
and seemingly endless compilation.
The added nix expression allows maintainers to check for regressions in
the configuration overlays employed by haskellPackages and friends. The
reasoning behind this is that, if we add an override for something, it
should also build. To test this fact, we extract all attributes touched
by a configuration and obtain all relevant derivations corresponding to
it which can then be thrown into nix-build --keep-going.
I've been using this expression to verify configuration-ghc-9.2.x.nix
for a week or so which works quite well. The amount of stale overrides
in other configuration makes it a bit more painful for other use cases
at the moment.
