Enhance formatting for ConstBlock expressions

[calebcartwright]

#4478 included some initial support for the new ConstBlock expression kind variant, but there's opportunities to enhance and improve the formatting.

The relevant section of the codebase can be found in formatting/expr.rs

rustfmt/src/formatting/expr.rs

Lines 127 to 129 in cbe01e4

	ast::ExprKind::ConstBlock(ref anon_const) => {
	Some(format!("const {}", anon_const.rewrite(context, shape)?))
	}

There are 3 core activities to completing this issue:

1. Honor the brace_style configuration option
2. Account for any comments between the const keyword and the block
3. Add test cases

1. brace_style

This should be relatively easy. When brace_style is set to AlwaysNextLine (can be checked with context.config.brace_style()) then we'll want to insert a newline and start the block on the next line (the correct newline and indentation can be achieved via shape.to_string_with_newline(context.config)), otherwise there should just be a space between the keyword and block

2. comments

First step will be to determine the span between the end of the const keyword and the start of the block. Consider using context.snippet.span_after to figure out the lo for this "between" span, and for the hi you will want to use the lo of the block (anon_const.value.span.lo())

Once you have that span there are a few different options and comment utility functions for formatting the expression and ensuring comments are properly formatted. You may want to take a look at one or more of them:

• contains_comment
• combine_strs_with_missing_comments
• rewrite_missing_comment
• recover_missing_comment_in_span

3. tests

Below are a few (nonexhaustive) set of tests to cover some top of mind scenarios.

You will probably want to add a const_block_always_next_line.rs file under the configs/brace_style directory (https://github.com/rust-lang/rustfmt/tree/master/tests/source/configs/brace_style) for both tests/source and tests/target

fn foo() -> i32 {
    const {
        let x = 5 + 10;
        x / 3
    }
}

fn bar() -> i32 {
    const { 4 }
}

fn foo() -> i32 {
    const
{
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const // baz
{
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const /*qux */ {
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const
// baz
{
        let x = 5 + 10;
        x / 3
    }
}

[frbimo]

@calebcartwright any mentoring available? just want to confirm if i'm facing a wall later.

[calebcartwright]

Sure! You can reach us here and/or in the wg-rustfmt channel on Discord to discuss things, ask questions, etc.

[frbimo]

@calebcartwright ok. btw, may i know the test file you post is source's or target's?

[calebcartwright]

@frbimo

@calebcartwright ok. btw, may i know the test file you post is source's or target's?

Not sure I understand your question. Are you referring to the snippets I included above in the issue description? If so, those are just some ideas for using with the various test source files and configurations. They were all intended to be used as pre-formatting, as several of those are definitely not formatted correctly.

Disclaimer that this is eyeball formatted with GitHub's inline editor, but the correct/formatted (target) output for those with default configuration would be

fn foo() -> i32 {
    const {
        let x = 5 + 10;
        x / 3
    }
}

fn bar() -> i32 {
    const { 4 }
}

fn foo() -> i32 {
    const {
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const // baz
    {
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const /*qux */ {
        let x = 5 + 10;
        x / 3
    }
}

fn foo() -> i32 {
    const
    // baz
    {
        let x = 5 + 10;
        x / 3
    }
}

[ytmimi]

This can likely be closed when we backport #5289

[calebcartwright]

This can likely be closed when we backport #5289

Perhaps, but likely depends on the outcome of outstanding discussion in #3376

We were originally carrying on with applying the existing options in additional contexts on the 2.x branch, but after some reflection I really don't think that's the right way to go. We will support a brace style option on the const block expressions, but how/under which config option(s) remains an open question

[ytmimi]

Got it. Thanks for giving me some more context on this