Conversation
Release generation fails on MacOS 11 due to #804.
Brittany cannot format itself, but we can format it with Ormolu. It is a good idea to add it to our tests.
We have stopped doing that and I think it is nice for readability.
| | x == 6 = | ||
| foo x | ||
| + foo 20 | ||
| foo x | ||
| + foo 20 |
There was a problem hiding this comment.
This is due to an Ormolu fix that doesn't look good with 2-space indentation (it also didn't look good with Fourmolu's 2-space indentation). A later PR should probably edit the logic to say "if indentation is <= 2, add an indentation, otherwise, don't"
There was a problem hiding this comment.
Agreed on the fix. Perhaps we should tackle it in this PR if it's that simple? Otherwise we can open an issue, but we'll have to make sure we mark it high-priority and fix it before the next release.
There was a problem hiding this comment.
If you're ok with it, I'd rather merge this PR asap and open a high priority issue after
There was a problem hiding this comment.
We definitely need to fix this before making a release. My inclination is to fix it before merging, rather than letting the regression hit master. Why do you feel differently?
Same goes for the stray newlines in import lists.
(I was about to push a commit reverting the outputs to what we'd hope to see, and suggest that we then fix the tests properly in this PR. But I realised that would be rude without getting your opinion first.)
There was a problem hiding this comment.
I was about to push a commit reverting the outputs to what we'd hope to see, and suggest that we then fix the tests properly in this PR.
See #140 instead for said changes.
There was a problem hiding this comment.
Why do you feel differently?
Personally, I would prefer merging ormolu PRs to only resolve merge conflicts because of the sheer amount of changes that are being merged in. If I were to fix the stuff now, the PR diff would include both merge conflict changes (i.e. changes that are needed to merge anything at all) and "feature work" changes. Having the "feature work"/regression fixes commits be separate helps a bit, but in a PR where 20/30 commits are from upstream, the fourmolu-specific commits can get lost in the weeds.
But I don't feel too strongly. I can continue working on this branhc
There was a problem hiding this comment.
Well, the separation is still visible as long as we don't squash-merge. I'd prefer that to breaking the main branch.
src/Ormolu/Parser.hs
Outdated
| (mkT dropBlankTypeHaddocks) | ||
| hsmod | ||
| { hsmodImports = | ||
| concat $ normalizeImports True (hsmodImports hsmod), |
There was a problem hiding this comment.
This function is new; Ormolu now automatically normalizes a module immediately after parsing. I'm forcing the parameter to normalizeImports here to True so that we can sort the imports, but not get rid of the raw grouping information so we can (optionally) print the groups separately later on depending on poRespectful
There was a problem hiding this comment.
Could it be some error here which is leading to the unwanted blank lines in e.g. data/examples/import/sorted-four-out.hs?
There was a problem hiding this comment.
Yeah, that makes sense to me
| <> fmap getLoc con_ex_tvs | ||
| <> maybeToList (fmap getLoc con_mb_cxt) | ||
| [RealSrcSpan real Nothing | AddEpAnn AnnForall (EpaSpan real) <- epAnnAnns con_ext] | ||
| <> fmap getLocA con_ex_tvs |
There was a problem hiding this comment.
the deindent here looks weird. Ormolu has it correctly indented, but running fourmolu deindents it back. A latter PR should investigate and fix
ab8a7c7 to
e4d0a8a
Compare
e4d0a8a to
6116f83
Compare
|
FYI @georgefst you'll need to go to Settings > Protected branches and edit the protection to remove 8.8 and add 9.2 |
|
@georgefst this is blocking the aeson-2 upgrade in stackage, do you think you can review this by January? |
|
Thanks for letting me know! This has been near the top of my to-do list for a while, but that's probably the kick I needed. Fortunately I've just finished work for the holidays, so I should get to this in the next few days. |
Time flies. Got terribly sidetracked by the inability to build this on GHC 8.10 (digital-asset/ghc-lib#344). I promise that barring any serious emergency I'll have this reviewed within 24 hours. I have been using this heavily via a fork of the |
data/examples/declaration/type-families/closed-type-family/multi-line-four-out.hs
Show resolved
Hide resolved
| If there are any options you'd like to see, let us know. If it's not too complicated to implement (and especially if you implement it yourself!) then we'll probably add it. | ||
|
|
||
| Run `cabal test` and `./format.sh` before submitting any pull requests. | ||
| See `DEVELOPER.md` for documentation. |
There was a problem hiding this comment.
I agree that this is no longer the right place for this.
But perhaps we should point out the option of running scripts/run-fourmolu.sh manually in DEVELOPER.md. Some people don't like pre-commit hooks.
There was a problem hiding this comment.
Sure, will do
| 5 -> True | ||
| _ -> False | ||
| 5 -> True | ||
| _ -> False |
There was a problem hiding this comment.
FYI reverting the change to multiple-guard-statements-four-out.hs also reverts this change. This is correct and matches Ormolu's behavior
There was a problem hiding this comment.
Wow, ok, looks weird to me but this is definitely not to place to change it then.
|
Fixed |
|
Done. Should be ready to merge |
|
Nice! I'm happy to merge. Any idea what's holding up CI? Do you want to handle the release? Otherwise I can do it this evening (GMT). |
Feel free to handle the release |
Adds GHC 9.2 support to fourmolu (for free!)
Needs fixing (either in this PR or in a followup PR):
Fix indentation after guardFix import newline regression