Audit config options

[nrc]

Are there options which we should not bother to support? Options which could be combined? Of those we should keep, which are certain enough of (both that they should exist and of their behaviour) that we should consider them stable?

[topecongiro]

A list of config options, in a bit of organized fashion (ran out of gas).

Catch-all

• control_style -> indent_style
• where_style -> indent_style

Brace

I think we can combine these into a single brace_style.

• control_brace_style
• fn_brace_style -> brace_style
• item_brace_style -> brace_style

Comment

• normalize_comments
• wrap_comments

Indent

I think we should make these names consistent (.._indent).
Also I am wondering if we can combine them into more 'general' config option, like expr_indent or item_indent. We do not want to combine block-style indent and visual-style indent together, so having separate config options for each ExprKind seems unnecessary IMO.

• array_layout -> array_indent -> indent_style
• chain_indent -> indent_style
• fn_args_layout -> fn_args_indent -> indent_style
• fn_call_style -> fn_call_indent -> indent_style
• generics_indent -> indent_style
• imports_indent
• struct_lit_style -> struct_lit_indent -> indent_style

Match arm

• indent_match_arms
• match_block_trailing_comma
• match_pattern_separator_break_point
• wrap_match_arms

Space

It feels to me that these are too narrow to support except space_around_ranges.

• space_after_bound_colon
• space_after_struct_lit_field_colon
• space_after_type_annotation_colon
• spaces_around_ranges
• space_before_bound
• space_before_struct_lit_field_colon
• space_before_type_annotation
• spaces_within_angle_brackets
• spaces_within_parens
• spaces_within_square_brackets
• type_punctuation_density

String

• format_strings
• force_format_strings

Vertical alignement

• struct_field_align_threshold

Width

Again, we should name these consistently (chain_one_line_max to chain_width and tab_spaces to tab_width).

• array_width
• chain_one_line_max -> chain_width
• comment_width
• fn_call_width
• max_width
• single_line_if_else_max_width
• struct_lit_width
• struct_variant_width
• tab_spaces

Horizontal v.s. Vertical v.s. Mixed

• array_horizontal_layout_threshold
• fn_args_density
• imports_layout
• where_density

Sort items

• reorder_extern_crates
• reorder_extern_crates_in_group
• reorder_imported_names
• reorder_imports
• reorder_imports_group

What to do with empty block body

We can combine these into empty_block_body_single_line.

• fn_empty_single_line
• impl_empty_single_line

Allow single line

• fn_single_line
• struct_lit_multiline_style -> struct_lit_single_line

Legacy

These options do not take effect or work well with the RFC style. I think it is safe to deprecate these options.

• closure_block_indent_threshold
• fn_return_indent
• fn_args_paren_newline
• take_source_hints
• where_layout
• where_pred_indent

Not exposed to users

• file_lines
• verbose

Others

report_todo and report_fixme are nice to have, but not a typical job for a format tool IMO.

• attributes_on_same_line_as_field
• attributes_on_same_line_as_variant
• binop_separator
• chain_split_single_child
• combine_control_expr
• condense_wildcard_suffixes
• disable_all_formatting
• error_on_line_overflow
• error_on_line_overflow_comments
• force_explicit_abi
• hard_tabs
• merge_derives
• multiline_closure_forces_block
• multiline_match_arm_forces_block
• newline_style
• remove_blank_lines_at_start_or_end_of_block
• report_fixme
• report_todo
• required_version
• skip_children
• trailing_comma
• trailing_semicolon
• use_try_shorthand
• write_mode

[nrc]

We should also think about which options should be stable (vs unstable). I think we can start conservatively and only make max_width and tab_spaces stable. I think I would prefer to leave all the other formatting options unstable until 1.0 (the only one I can think of considering is hard_tabs).

That leaves the non-formatting options such as write_mode and skip_children. I think we can also be conservative here and leave them all till post-1.0.

[nrc]

So, a big question for me is what style of options we want to permit. Currently we have very fine-grained options, which makes Rustfmt very customisable, but:

• the chance of any set of options working together is low
• it is fiddly in the common case
• the set of options is huge and confusing

An alternative would be to support a small set of coarse grained styles. E.g., a compressed style would enable all the 'one line' options plus set wider values for the width heuristics, etc. We might support a style which always puts opening braces on a newline, but not any way to mix that with the 'braces on the same line' style.

We would aim to support each of these larger styles on their own, but combining them is at the user's own risk (and we would explicitly not test combinations).

If we don't do this, I think we probably need to combine options into groups in the documentation or something in order to make them less confusing.

Thoughts?

[nrc]

Some replies to @topecongiro's big list (thanks for doing that!):

• Brace: yes, agree
• Indent: yes to _indent for all of them. And I think 'yes' to just having block vs visual indent. However, I wonder if we should combine that with same line vs next line braces (e.g., not offer visual indent at all if you have next line braces)
• Match: I would remove indent_match_arm and I'm not sure about the last two either.
• Space: other than space_around_ranges I would combine these all into one option. (We might also come back and remove that one option later, we'll see) I'm not sure about type_punctuation_density, that could probably be removed.
• String: we should combine these two, I think
• Width: agree
• Sort items: I think we can have a single option - either we sort all the imports/extern crates in our chosen way or leave them as is.
• Legacy: let's just kill them, no need to deprecate
• Others: write_mode should probably not be user-visible. The motivation for report_* is that I wanted rustfmt to replace the make tidy checks in the Rust repo. I'm not sure whether or not we should try and do this kind of linting. In any case, they could be a single option.

[topecongiro]

control_style and where_style exists to support legacy style, so can we remove them as well?

[nrc]

control_style and where_style exists to support legacy style, so can we remove them as well?

Hmm, I'm not sure (and now I'm rethinking what to do about the legacy category). We might have a single overriding indent_style, which is either block or visual where block is the default and visual is a combination of the 'legacy' style options which works vaguely well.

OTOH, given the overwhelming support for the new style, I wonder if there is any need to provide a 'visual' style at all? Perhaps we do it as a first step and maybe remove later.