This allows to build ormolu for another system as the machine's,
combined with Nix remote builders. It is also useful in a context of a
pure evaluation (like Flakes).
This resolves a class of idempotence issues when the equality sign happens
to be inserted between an element and its comment that follows on the same
line. I had to special-case equality sign for this, because all alternative
approaches (changing comment association logic or trying to find a more
general rule) did not work or fixed this issue yet made other things worse.
There is nothing special about the equality sign per se, but it (always?)
starts definitions which have their own ‘Located’ wrappers and it is those
spans interfere with the logic of comment association (they are detected as
AST elements between the “host” element and its comment) on subsequent
passes. This results in non-idempotent formatting.
The solution is OKish in that it fixes 99% of problems that one will
encounter in practice, but I see how an input can be crafted to show that
there is still an issue with idempotence.
GHC 8.10.1 comes with some changes to the AST, which works great for
Ormolu, but causes this commit to be a bit large:
* Trees That Grow extension points for new constructors are now statically
proven to be uninhabited, via noExtCon :: NoExtCon -> a. Thanks to this
change I got rid of many notImplemented calls.
* LPat constructor is now a lot more usable, so we don't need to use
the locatedPat combinator and can remove some boilerplate code.
Also it comes with ImportQualifiedPost and StandaloneKindSignatures
we should support. I did not implement them in this commit, they'll
be merged in later on.
It causes one behaviour change, where the ordering of qualified and
non-qualified imports of the same module is changed. This is due to
our usage of gcompare resulting a different ordering because of the
AST change caused by the ImportQualifiedPost extension. I think this is
acceptable and we shouldn't try to keep backwards compatibility there.
Another behaviour change is that previously HsExpr had a few extra
constructors for arrows and patterns used in expression context. Those
programs were syntactically incorrect, but refused on a later stage. But
we nonetheless formatted those constructs so Ormolu didn't fail there
while keeping the source code intact. However, now those constructors
are removed, so Ormolu fails with a parse error in this case (same as
GHC). I also removed some tests exhibiting this behaviour.
The commit changes how type signatures are printed. The new style looks like
this:
foo ::
Int ->
Char ->
String
This works better with foralls and other features of the type system that
will be added in the near future, like linear arrows.
In order to print Haddocks nicely (this seems to be the only acceptable
placement):
foo ::
-- | First argument
Int ->
-- | Second argument
Char ->
-- | Result
String
It is often necessary to re-arrange them completely and use the “pipe style”
instead of “caret style”. It proved to be a very hard task with our older
comment-handling system, if not impossible.
Here we start parsing Haddocks so that they are treated as components of AST
and we now render them as part of rendering of those components. The
existing framework for handling comments only prints non-Haddock comments
now.
The change caused a fair number of new problems and failures which I added
new tests for.
I implemented a custom logic where we assign a score to every occurance of
an operator based on their location, and the average of that score determine
the fixity of the operator.
As you can imagine, the solution is a bit brittle; and it is easy to mislead
it if you knowingly craft an input, but it gave acceptable results for every
code snippet I found online. And since it returns the same AST no matter how
we infer the fixities, it is not the end of the world if we infer something
incorrectly.
The code is not really optimised, and I think it has quadratic time
complexity. Notably, we use opTreeLoc function quite often and it traverses
the whole tree every time. Memoizing that on the OpBranch constructor would
make formatting files with reeeally long operator chains a lot faster. We
can do this once we decide to optimize for speed.
This removes (or rather puts it to a lower level) logic around “modifying
newline” because it was very hard to reason about and almost blocked my work
on fixing issue #337.
I also dropped debugging output because it's too verbose and I'm not using
it anyway.
As part of these changes I also changed now the ‘newline’ combinator works.
Now, similar to ‘space’, the second ‘newline’ in a row just tells the
rendering engine to prefix next thing with a newline, using the ‘newline’
combinator more than twice in a row has no effect.
To take full advantage of the new feature I also went through the code and
simplified some logic around outputting exact amount of newlines because now
it's harder to get things wrong, so we can be less careful with counting
newlines.
* Point to more recent nixpkgs commit. This fixes build issue with python
3.7.3 (only on darwin?).
* Separate shell.nix and default.nix. This is so that lorri can be used for
development.
* Add nix output to .gitignore.
* Format *.nix using nixfmt.
* Use gitignore for filtering files in nix derivation.
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.
