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
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