This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f() {}
Differential D33447
clang-format: add option to merge empty function body Typz on May 23 2017, 9:39 AM. Authored by
Details This option supplements the AllowShortFunctionsOnASingleLine flag, to int f() {}
Diff Detail
Event Timeline
Comment Actions Fix SFS_Empty & SFS_Inline merging of empty function when BraceWrapping.AfterFunction, and add missing test Comment Actions Does anything speak against making this behavior happen with AllowShortFunctionsOnASingleLine = SFS_Empty and MergeEmptyOnly.BraceWrapping.AfterFunction = true? I mean without the extra style option?
Comment Actions That is fine with me (with AllowShortFunctionsOnASingleLine >= SFS_Empty condition), but I see two things:
Comment Actions As it currently stands, I am really not happy with the configuration space that this opens up. If we can't make the configuration of existing flags, what's the coding style encourages this behavior? Comment Actions Facebook's HHVM seems to use this for empty constructors: https://github.com/facebook/hhvm/blob/master/hphp/doc/coding-conventions.md Personally, I don't care if this is an option or not; but I fear it would break existing styles. Comment Actions But that style specifically says that it is only done if the initializer list is wrapped: I.e. we would do the right thing for that style if we would set BraceWrapping.AfterFunction to true and AllowShortFunctionsOnASingleLine to SFS_Empty and it would then format: Constructor() {} Constructor() // : initializer(..) {} Comment Actions I am fine with "removing" the options: I only fear it would incorrectly affect existing users/styles, which would possibly end up in the patch being reverted... void foo() { } So if you tell me it's fine I will go ahead and replace the option with the BraceWrapping.AfterFunction && AllowShortFunctionsOnASingleLine >= SFS_Empty condition. Comment Actions No, I don't think it should be done this way and neither Facebook nor Mozilla coding styles say you should. Mozilla style has an explicit example: int TinyFunction() { return mVar; } Facebook style has an explicit example: MyClass::MyClass(uint64_t idx) : m_idx(idx) {} Moving the "{}" to the next line is only ok if the complete function/constructor definition (up to and including the "}") does not fit on one line. Comment Actions Right, I was not clear enough: this is indeed done only if everything does not fit on one line. There is an exemple in facebook's coding style: MyClass::MyClass(const Class* cls, const Func* func, const Class* ctx) : m_cls(cls) , m_func(func) , m_ctx(ctx) , m_isMyConditionMet(false) {} And this happens (with the extra space) in the same kind of situation in Mozilla's code: nsSameProcessAsyncMessageBase::nsSameProcessAsyncMessageBase(JS::RootingContext* aRootingCx, JS::Handle<JSObject*> aCpows) : mRootingCx(aRootingCx) , mCpows(aRootingCx, aCpows) { } Comment Actions Merging empty blocks is not allowed in webkit style: https://webkit.org/code-style-guidelines/#punctuation-member-init So it seems changing the behavior would actually fix mozilla style and break webkit style (as integrated in clang-format). Comment Actions I don't understand. WebKit style would not set AllowShortFunctionsOnASingleLine and so the behavior there wouldn't change, I presume? Comment Actions Webkit inherits AllowShortFunctionsOnASingleLine = FormatStyle::SFS_All from LLVM style, so merging the options would introduce these explicitely-forbidden empty blocks. Comment Actions I think it's just wrong that WebKit inherits this. The style guide explicitly says that this is wrong: MyOtherClass::MyOtherClass() : MySuperClass() {} So I still think we can make this work with the existing options without regressing a behavior that anyone is relying on. Comment Actions I think this exemple applies to constructors only (and it works even with inlining, since this style has BreakConstructorInitializersBeforeComma = true and ConstructorInitializerAllOnOneLineOrOnePerLine = false, so there is already a line break before the colon)
Looking at webkit code, there are many short functions which are indeed formatted on a single line (at least 22097 occurences, actually), so removing AllowShortFunctionsOnASingleLine from webkit style does not seem appropriate. Comment Actions Lets try this the other way around. I am not ok with introducing an additional top-level option for this. It simply isn't important enough. So find a way for the existing style flags to support what you need and not regress existing users. If that can't be done, I am also ok with adding another value into BraceWrapping (which you suggested at some point, I think). |
maybe this should be a nested option inside BraceWrapping?
or this should be donc implicit when breaking after function (BraceWrapping.AfterFunction = true) and AllowShortFunctionOnASingleLine (hence no option added) ? Or even AllowShortBlocksOnASingleLine (though the doc limits this option to statements...)