Conversation
|
👋 @brandonchinn178 Reviewer: Please verify the following things have been done, if applicable.
|
|
cc @3kyro |
|
@brandonchinn178 There seems to be a regression on multi line arguments with interleaved comments. You can test the following: withComments
-- Comment
:: Int
-- Comment
-> Int
-- Comment
-> Intwhich gets formatted as: withComments
:: -- Comment
Int
-> -- Comment
Int
-> -- Comment
Int |
|
@3kyro thanks! The situation isn't much better on foo
:: -- asdf
Int
-- bar
-> BoolBut I'll take a look! |
Indeed it's not 😞 Apart from this, the fixes look like a big improvement and I didn't notice any other formatting change regarding leading function arrows. |
The "::" for SPECIALIZE should be aligned with the commas, not the function arrows. Technically speaking, we should respect 'comma-style' here, but that can be done separately. For now, just revert this code to before the function-arrows work.
|
@3kyro just pushed 3 new commits! should have the comments fixed, and i also found an issue with leading arrows + explicit type signatures for expressions |
This adds some simple sorting of constraints. There are a few potential deficiencies: 1. It doesn't sort nested constraint tuples. We could solve this by carrying around some information about whether we are in a constraint context in `p_hsType`, but that seeemed moderately disruptive. 2. It doesn't handle constraint tuple synonyms. I think this is unavoidable since we can't know they're constraint tuples without type information. 3. The sorting is very crude, just sorting on the `Outputable` representation of the type. I think this will more-or-less doe what people expect, but perhaps it's too expensive? Fixes fourmolu#247
This adds some simple sorting of constraints. There are a few potential deficiencies: 1. It doesn't sort nested constraint tuples. We could solve this by carrying around some information about whether we are in a constraint context in `p_hsType`, but that seeemed moderately disruptive. 2. It doesn't handle constraint tuple synonyms. I think this is unavoidable since we can't know they're constraint tuples without type information. 3. The sorting is very crude, just sorting on the `Outputable` representation of the type. I think this will more-or-less doe what people expect, but perhaps it's too expensive? Fixes fourmolu#247
This adds some simple sorting of constraints. There are a few potential deficiencies: 1. It doesn't sort nested constraint tuples. We could solve this by carrying around some information about whether we are in a constraint context in `p_hsType`, but that seeemed moderately disruptive. 2. It doesn't handle constraint tuple synonyms. I think this is unavoidable since we can't know they're constraint tuples without type information. 3. The sorting is very crude, just sorting on the `Outputable` representation of the type. I think this will more-or-less doe what people expect, but perhaps it's too expensive? Fixes fourmolu#247
This adds some simple sorting of constraints. There are a few potential deficiencies: 1. It doesn't sort nested constraint tuples. We could solve this by carrying around some information about whether we are in a constraint context in `p_hsType`, but that seeemed moderately disruptive. 2. It doesn't handle constraint tuple synonyms. I think this is unavoidable since we can't know they're constraint tuples without type information. 3. The sorting is very crude, just sorting on the `Outputable` representation of the type. I think this will more-or-less doe what people expect, but perhaps it's too expensive? Fixes fourmolu#247
This adds some simple sorting of constraints. There are a few potential deficiencies: 1. It doesn't sort nested constraint tuples. We could solve this by carrying around some information about whether we are in a constraint context in `p_hsType`, but that seeemed moderately disruptive. 2. It doesn't handle constraint tuple synonyms. I think this is unavoidable since we can't know they're constraint tuples without type information. 3. The sorting is very crude, just sorting on the `Outputable` representation of the type. I think this will more-or-less doe what people expect, but perhaps it's too expensive? Fixes #247
Found some edge cases for function arrows, and was able to simplify the code without the
PrevTypeCtxmachinery.Some of the changes I made seem to still pass tests (e.g. moving things in/out of a
locatedblock). If we find a regression or issue later, we can fix it later with an added test