Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve function body braces #2223

Merged

Conversation

anmonteiro
Copy link
Member

This is an alternative to #1826 implementing just the brace preservation
code, to make it easier to be reviewed.

I think this is now in a better place to get into the codebase given
that we have Reason_attributes outside of Reason_pprint_ast and that
we now remove our own attributes before printing to OCaml.

I think we can probably refactor this code further in future PRs, as
well as add other stylistic preservation changes.

This is an alternative to reasonml#1826 implementing just the brace preservation
code, to make it easier to be reviewed.

I think this is now in a better place to get into the codebase given
that we have `Reason_attributes` outside of `Reason_pprint_ast` and that
we now remove our own attributes before printing to OCaml.

I think we can probably refactor this code further in future PRs, as
well as add other stylistic preservation changes.
@anmonteiro anmonteiro force-pushed the anmonteiro/preserve-requested-braces branch from 0c5c67c to c7182e4 Compare October 9, 2018 20:04
_
)},
_
) -> Printf.eprintf "YEP\n%!";true *)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can be removed.

let semiTerminated term = makeList [term; atom ";"]

let makeBreakableBlock ?(inline=false) letItems =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a huge fan of abstractions on top of makeList. The exact behaviour of makeBreakableBlock is very hard to predict without inspecting its implementation.
makeBreakableBlock seems to be used only once too. Is there a reason why you didn't use makeList with all named args in the letList printing? Just using makeList with all named args makes it very clear what is going to happen.

@jaredly
Copy link
Contributor

jaredly commented Oct 10, 2018

yayyyyyyy

@@ -38,6 +38,9 @@ let rec partitionAttributes ?(partDoc=false) ?(allowUncurry=true) attrs : attrib
| (({txt="reason.raw_literal"}, _) as attr) :: atTl ->
let partition = partitionAttributes ~partDoc ~allowUncurry atTl in
{partition with literalAttrs=attr::partition.literalAttrs}
| (({txt="reason.preserve_braces"}, _) as attr) :: atTl ->
let partition = partitionAttributes ~partDoc ~allowUncurry atTl in
{partition with literalAttrs=attr::partition.literalAttrs}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

literalAttrs was originally intended to represent string literals. It seems you're repurposing them here? The name should probably be changed accordingly.

@jordwalke
Copy link
Member

Is it currently the case that these (and other stylistic attributes such as string "literal" attributes) are removed when the --print is binary? I believe that should be the case and would fix the other issues we've had with ppx plugins complaining.

@anmonteiro
Copy link
Member Author

anmonteiro commented Oct 12, 2018

@jordwalke yes, we remove literalAttrs from printing (even to binary).

I agree with your comment that the name should probably be changed.

pub push = hd => {
v = [hd, ...v];
};
initializer {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the rational behind printing braces here, while the original had parens?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -515,24 +516,42 @@ module M = {

module N = {
open M;
let z = M.(34);
let z = {
M.(34);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this local open sugar have braces?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is how the original input file looked.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah indeed, my bad, was confused between braces and open sugar.

@chenglou chenglou merged commit c16a926 into reasonml:master Nov 13, 2018
@anmonteiro anmonteiro deleted the anmonteiro/preserve-requested-braces branch November 13, 2018 21:08
anmonteiro added a commit to anmonteiro/reason that referenced this pull request Dec 11, 2018
This is an alternative to reasonml#2289 that also renames `literalAttrs` to
`stylisticAttrs` as request in reasonml#2223's code review
anmonteiro added a commit to anmonteiro/reason that referenced this pull request Dec 11, 2018
This is an alternative to reasonml#2289 that also renames `literalAttrs` to
`stylisticAttrs` as request in reasonml#2223's code review
chenglou pushed a commit that referenced this pull request Dec 12, 2018
This is an alternative to #2289 that also renames `literalAttrs` to
`stylisticAttrs` as request in #2223's code review
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants