[clang-format] Incorrectly merged empty records with default config

[itzexpoexpo]

During PR #154580 we noticed that empty records (struct,union,class) get incorrectly merged by clang-format running on default config:

struct foo {};
struct bar {
  int i;
};

This happens even with BreakBeforeBraces: Custom and BraceWrapping.SplitEmptyRecord: true.
Expected output in both cases is:

struct foo {
};
struct bar {
  int i;
};

Behavior is correct if BraceWrapping.AfterStruct: true:

struct foo
{
};
struct bar
{
  int i;
};

Occurs at least since version 12.0.0 and is likely an issue in LineJoiner::tryFitMultipleLinesInOne or it's callees.

[owenca]

struct foo {};
struct bar {
int i;
};

This is an undocumented behavior.

This happens even with BreakBeforeBraces: Custom and BraceWrapping.SplitEmptyRecord: true. Expected output in both cases is:

struct foo {
};
struct bar {
int i;
};

This is the documented behavior as SplitEmptyRecord has no effect unless AfterStruct is set to true.

[itzexpoexpo]

Since the default configuration has SplitEmptyRecord: true and AfterStruct: false too, would the solution be to just document this under Attach and Stroustrup for BreakBeforeBraces? Maybe even adding an example for each preset how they handle empty records?
Or would it be viable to change the behavior, and make SplitEmptyRecord independent of AfterStruct? Probably not worth the breaking change since it's documented, but the behavior is a bit surprising

[owenca]

Since the default configuration has SplitEmptyRecord: true and AfterStruct: false too, would the solution be to just document this under Attach and Stroustrup for BreakBeforeBraces? Maybe even adding an example for each preset how they handle empty records?

Like I said, it's already documented under SplitEmptyRecord, which "is used only if the opening brace of the record has already been wrapped, i.e. the AfterClass (for classes) brace wrapping mode is set."

Or would it be viable to change the behavior, and make SplitEmptyRecord independent of AfterStruct? Probably not worth the breaking change since it's documented, but the behavior is a bit surprising

No, we don't want change the existing behavior.

[itzexpoexpo]

What I meant is, that it's not necessarily obvious that Attach and Stroustrup have this behavior, but if you consider the existing documentation sufficient I will close as solved.