The PR changes the body layouting to use a span that includes the last point in
the name/pattern part of a match. This forces the layout to be multiline iff the
body starts on a newline.
I'm not sure it's perfect, but it fixes the original issue and all the tests
pass.
The problem was in entering with locate (or some version of it) the same
span twice. So the algorithm saw an element with identical enclosing element
and the ‘commentFollowsElt’ function got confused.
The solution is two first augment registration of enclosing spans to allow
us to keep more than one item there. Then we can filter out spans which are
just copies of current reference span to get to the “real” enclosing span.
It seems to make sense to attach comments to child element if it starts
exactly at the same position of parent element, hence the distance between
start of enclosing/reference span and start of comment is the same, thus
changing ‘>’ to ‘>=’ in ‘commentFollowsElt’.
This pull request implements half of #49. Specifically, it deals with pretty printing instance declarations and most structures needed to support that. This includes pretty printing of associated types (and therefore also type family instances.) However, this _does not_ include pretty printing of associated data types.
Pretty printing of type class declarations is to be dealt with at a later time.
Instances are formatted such that indentation hangs after the `instance`. Namely,
```haskell
instance Eq a
=> Eq [a] where
```
To support pretty printing associated types, the function `p_tyFamInstEqn` was exported from the appropriate module. This was done to avoid redundant code duplication.
This formatting scheme is more appropriate if you think of chaining multiple
infix expressions and combining it with do-blocks. The operator should hang
on previous line instead going first on the next line, e.g.:
foo +
bar
instead of
foo
+ bar
The main point of this commit is perhaps that certain constructions are rare
and unnatural in multi-line form, so we could print them always in
single-line form however putting parentheses still in multi-line fashion so
the properly of idempotency is satisfied.
This pull request implements most of currently missing types of expressions,
with the exception of:
* Do notation
* List comprehensions (list comprehensions are considered a kind of do
notation in GHC)
* Arrow notation
* Template Haskell
Most expressions are pretty printed in an uncontroversial manner, preferably
similar to existing syntax.
It was decided that we're going to make the project compatible with just one
GHC version at a time. Right now this version is going to be 8.6.4.
A small refactoring included, plus support for the “deriving via” feature.
‘ghc-exactprint’ (or perhaps lexer of GHC itself) does a fairly poor job at
associating comments with elements of AST. In many cases the result is not
what you'd expect. We ran into insuperable problems with that to the effect
that correct comment placement were impossible.
The new approach is to exploit the raw position information provided by the
GHC lexer, that is, spans attached to AST elements and comments. This
allowed us to place comments in output in a very precise and satisfactory
fashion.
