Whole thing is ugly. Exactprint decided to not include a proper
delta for that one comment, so needed a special workaround that
then needs special exceptions too.
The whole thing is a mess at this point and needs a re-think.
At least we now have a proper test-suite for these kinds of
problems.
comments between top-level decls should be considered
for inline-config. But despite being placed between
top-level decls, occasionally they get connected
somewhere nested inside the AST of the first decl.
We fix this by extracting such comments in a
pre-processing step. The control flow was significantly
altered to allow for this;
before:
parsing -> extract inline configs
-> compute final config(s)
-> split module into head/decls/comments/whitespace
-> ... bridoc -> transformations -> printing
after:
parsing -> split module into head/decl/comments/whitespace
-> extract inline configs respecting comments that
got extracted from decls in the previous step
-> compute final config(s)
-> ... bridoc -> transformations -> printing
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.
- 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 "$ $ $ + +".
Lennart Spitzner
Phil Hazelden