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.
- Allow par-spacing for single-operator 1+n-line layout
- Tweak when to flatten operators, i.e. when to allow a flat one-line-each
layout for the operator sequence "$ $ $ + +".
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