The 92 indicates that this version is based on ghc-9.2.*.
Given that we support a single GHC version at a time
(and avoid any CPP mess) I thought this might be appropriate.
This also allows bug-fix releases to different "branches",
i.e. publishing 92.x.x.(n+1) together with 94.y.y.(n+1) to
address some bug that affects both the ghc-9.2.* branch
and the ghc-9.4 branch. From a PVP perspective it might not
be ideal that we regularly bump major versions when the
API does not actually change much, if at all, but given that
brittany primarily is an executable and will probably have
a small set of reverse-dependencies this seems acceptable.
Closes#370.
Up to GHC 8.10,
foo @ 'Bar
was a valid type application. In GHC 9 it's not, which means brittany
needs to allow
foo @'Bar
which it now does.
The reason the space was needed was to allow a promoted type variable at
the head of a type-level list. That is,
'['Foo]
is invalid syntax, because it initially parses as the character `'['`.
So the promoted type variable was always given a separator at the
beginning, and we'd get
'[ 'Foo]
which was valid. Now we handle this case by specifically examining the
head of a type-level list; if it's promoted we introduce spaces, so
'[ 'Foo ]
'[Foo]
I've added tests for this and some related cases. In doing so I noticed
that unnecessary spaces get added in front of commas in these lists; I
believe that's a separate bug, and I've written a comment explaining why
it happens, but I haven't tried to fix it.
I'm not sure when the first alternates in the `FirstLastSingleton`
and `FirstLast` branches would ever be hit, so I'm not entirely sure if
the separators are necessary there. But since `docSeparator` disappears
at the end of a line and merges with adjacent separators, they should be
harmless.
I assume this makes inlining impossible, but it enables
parallel compilation of all these modules. In my tests
this reduce wall clock time to 92%, and with more cores
the benefit should be higher.
Lennart Spitzner
Phil Hazelden
Taylor Fausak