Disable "respectsExistingLineBreaks" in .swift-format for more consistent styling

[czechboy0]

Disable "respectsExistingLineBreaks" in .swift-format for more consistent styling.

Today, respectsExistingLineBreaks is enabled, which means that it depends on how you write the code before running the formatter, and it affects the output. That's not ideal, and is different than the setting we have for formatted code, so affects #40.

This should be done as a single PR, as it'll cause some churn.

[glbrntt]

Would disabling this rule remove all unnecessary line breaks?

E.g. would

func foo() {
  let bar = try makeBar()
  
  let baz = process(bar)
  baz.doSomething()
}

become the following?

func foo() {
  let bar = try makeBar()
  let baz = process(bar)
  baz.doSomething()
}

[czechboy0]

No, it leaves those alone. It only reformats line breaks around source code, it seems: #231

[glbrntt]

Oh that seems reasonable then. Saying that, from the diff I'm not convinced this makes the code any easier to read. In fact some places it worsens readability. Perhaps other rules need tweaking when enabling this as well.

A few examples:

} catch {
        XCTFail(error.localizedDescription, file: file, line: line)
}

changed to

} catch { XCTFail(error.localizedDescription, file: file, line: line) }

and

    public static func error(
        message: String,
        location: Location? = nil,
        context: [String: String] = [:]
    ) -> Diagnostic {
        .init(severity: .error, message: message, location: location, context: context)
    }

changed to

    public static func error(message: String, location: Location? = nil, context: [String: String] = [:]) -> Diagnostic
    { .init(severity: .error, message: message, location: location, context: context) }

[czechboy0]

Yeah I don't love the bias towards single line scopes either. I'll take a look at the rules if we can't opt out of that.

[PARAIPAN9]

Hello, I would be interested in working on this issue if it's available

[czechboy0]

Sure @PARAIPAN9, although it might result in a big diff, so maybe you could look into landing this one first? #188

[PARAIPAN9]

Sure, thanks!!