Allow "vertical" behavior for function calls

[aclysma]

(Closest issue to this I could find was #65)

Currently, fn_args_layout = "Vertical" will force all arguments on the function definition to be on their own line. I would like to have a way to get the same "vertical" behavior applied at callsites.

I'm not proposing that this be a default behavior, I'd just like to be able to opt-in to it.

Current Behavior

draw_circle(radius, position, color);

LogicalPosition::new(p0.x - p1.x, p0.y - p1.y)

Desired Behavior

draw_circle
    radius,
    position,
    color
);

LogicalPosition::new(
    p0.x - p1.x,
    p0.y - p1.y
);

Rationale

• It's not uncommon to insert new parameters, or change parameters, being passed into a function. Allowing vertical behavior makes for clean diffs and potentially avoids some merge conflicts. (Guiding principle 3 "Specifics")
• In some cases there is symmetry that is helpful to see. When the the symmetry is broken, it's more conspicuous. This can make bugs easier to spot, or if it's not a bug, help the reader to see this. (Guiding principle 1 and 2 "Readability" and "Aesthetics")
• In my opinion, this would be consistent with current fn_args_layout behavior (Guiding Principle 4 "Application")

Implementation

I think allowing the same Tall/Compressed/Vertical choice for function calls as already exists for function definitions would be a consistent, intuitive approach.

1. A simple, low impact solution would be to add a new config variable like fn_call_args_layout. This would make this change strictly opt-in.
2. Another possibility would be to add fn_definition_args_layout and fn_call_args_layout and have them both default to whatever value is set for fn_args_layout. I think this would make the change only impact those who already opted into customized fn_args_layout behavior. It's probably a matter of opinion if this is a good thing or not.

[calebcartwright]

I think this is a fair ask so long as the default still complies with style guide prescriptions, but it would probably be better suited to the rustfmt repo where the implementation could be discussed in more detail (I think I can transfer it if you'd like)

I realize it's often unclear which issues should be opened in which repo, but in general I think a request for a specific new feature in rustfmt is probably a better fit for that repo.

Let me know if you're still interested in this option and if you'd like me to attempt the transfer, otherwise I'll close it here

[joshtriplett]

Working on triaging issues on the style team repo (formerly fmt-rfcs).

Agreed with @calebcartwright that this seems to be a request for an option enabling a non-default style, rather than a request for a change to the default style. Given that, I'm going to close this, and recommend filing an issue on the rustfmt repo if you want to ask for an option.