Preserve user-added newlines with the following normalizations:
* No newlines below where
* Consecutive newlines are compressed into a single newline
* Always surround documented declarations with blank lines
Previously we hanged record constructors but not record updates. It looks
like unlike other hanging constructions (lambdas, case expressions, and
do-blocks), record constructors and updates should rather be placed
normally. Indeed, when we stop hanging them, many constructions start to
look more reasonable and predictable (see the updated test cases).
Yet the change is not enough to fix the problem in general case: it is
enough to replace the record with a e.g. do-block to get the same failure.
To correct that we adjust what should fit in one line for hanging placement
to fire: now we consider the span between beginning of function and the
start of potentially-hanging construction.
The order in which language pragmas are put in the input sometimes matters.
This is because some language extensions can enable other extensions, yet
the extensions coming later in the list have the ability to change it. So
here we classify all extensions by assigning one of the four groups to them.
Then we only sort inside of the groups.
I originally thought it's a good idea to prevent this, but it looks like it
makes things arguably worse in certain cases even though the Haddocks end up
not associated with their declarations (but they are not associated with
them in the input either, so it's OK).
While migrating to ‘ghc-lib-parser’ we accidentally stopped taking into
account the ‘--ghc-opt’ options. This commit fixes that and makes sure we do
not ignore unrecognized GHC options.
