RESOLVED FIXED 223229
clang-format config file generate changes not compatible with expected webkit style.
https://bugs.webkit.org/show_bug.cgi?id=223229
Summary clang-format config file generate changes not compatible with expected webkit...
Jean-Yves Avenard [:jya]
Reported 2021-03-15 17:56:16 PDT
Running clang-tidy will produce a style that is incompatible with what webkit-patch requires. Examples: --- MediaSessionPlaybackState m_playbackState { MediaSessionPlaybackState::None }; becomes: MediaSessionPlaybackState m_playbackState{ MediaSessionPlaybackState::None }; --- template<class Encoder> void encode(Encoder&) const; becomes: template <class Encoder> void encode(Encoder&) const; --- String src; if (!decoder.decode(src)) return { }; becomes: String src; if (!decoder.decode(src)) return {};
Attachments
Patch (1.04 KB, patch)
2021-03-21 16:39 PDT, Cameron McCormack (:heycam)
no flags
Patch (1.92 KB, patch)
2021-03-21 19:31 PDT, Cameron McCormack (:heycam)
no flags
Radar WebKit Bug Importer
Comment 1 2021-03-15 17:56:36 PDT
Alexey Proskuryakov
Comment 2 2021-03-16 08:36:18 PDT
Is there any way for us to fix this? Or does this bug track the need to file a bug against clang?
Cameron McCormack (:heycam)
Comment 3 2021-03-21 16:28:10 PDT
Looking at https://clang.llvm.org/docs/ClangFormatStyleOptions.html, we need to set SpaceBeforeCpp11BracedList to true. And I guess update upstream clang's WebKit defaults as well.
Cameron McCormack (:heycam)
Comment 4 2021-03-21 16:39:37 PDT
Cameron McCormack (:heycam)
Comment 5 2021-03-21 16:54:12 PDT
Well that patch addresses the first issue but not the latter two. For the last issue, it's not clear to me whether Cpp11BracedListStyle = false implies that a space should be inserted into empty braces.
Cameron McCormack (:heycam)
Comment 6 2021-03-21 17:00:36 PDT
For line breaking after template <...>, I don't see any rules in https://webkit.org/code-style-guidelines/#line-breaking about it. The .clang-format option we're currently setting that governs this is AlwaysBreakTemplateDeclarations = false, which will break if the line is too long or something. It looks like there's a real mix in the codebase: $ rg 'template ?<.*>$' | wc -l 2076 $ rg 'template ?<.*> [a-z]' | wc -l 2899 but tending towards not breaking.
Cameron McCormack (:heycam)
Comment 7 2021-03-21 17:04:58 PDT
AlwaysBreakTemplateDeclarations = false will take PenaltyBreakTemplateDeclaration into consideration but even if I make that very high, clang-format wants to break there. So that might be a clang-format problem.
Cameron McCormack (:heycam)
Comment 8 2021-03-21 17:37:58 PDT
So AlwaysBreakTemplateDeclarations = false is not a valid value, really, according to https://clang.llvm.org/docs/ClangFormatStyleOptions.html. It should be No, MultiLine, or Yes. Choosing No gives different behavior from false. Because .clang-format contains ColumnLimit = 0, this means that existing line breaking choices will be preserved unless they violate the rules. If we set AlwaysBreakTemplateDeclarations = No, this will cause template <typename T> void f(); template <typename T> void g(); to be unchanged. But if we change ColumnLimit to something very high, then the result will be: template <typename T> void f(); template <typename T> void g(); Changing ColumnLimit will probably cause a bunch of other undesirable changes, so I suggest we set AlwaysBreakTemplateDeclarations = No, and then at least we can write single line template declarations and not have clang-format change that.
Cameron McCormack (:heycam)
Comment 9 2021-03-21 19:31:07 PDT
Jean-Yves Avenard [:jya]
Comment 10 2021-03-22 13:30:04 PDT
The fix for:. String src; if (!decoder.decode(src)) return { }; Seems to be missibg
Cameron McCormack (:heycam)
Comment 11 2021-03-22 13:36:55 PDT
I don't know that there's a solution for that with the current set of .clang-format options.
EWS
Comment 12 2021-03-22 17:44:04 PDT
EWS
Comment 13 2021-03-22 18:16:52 PDT
commit-queue failed to commit attachment 423845 [details] to WebKit repository. To retry, please set cq+ flag again.
EWS
Comment 14 2021-03-23 14:24:04 PDT
Committed r274901: <https://commits.webkit.org/r274901> All reviewed patches have been landed. Closing bug and clearing flags on attachment 423845 [details].
Simon Fraser (smfr)
Comment 15 2021-03-23 14:54:50 PDT
Comment on attachment 423845 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=423845&action=review > .clang-format:20 > -AlwaysBreakTemplateDeclarations: false > +AlwaysBreakTemplateDeclarations: No Are 'false' and 'No' different? AlwaysBreakBeforeMultilineStrings is false. > ChangeLog:17 > + Reviewed by NOBODY (OOPS!). This should go below the bug URL (with a blank line in between).
Cameron McCormack (:heycam)
Comment 16 2021-03-23 15:01:49 PDT
(In reply to Simon Fraser (smfr) from comment #15) > > -AlwaysBreakTemplateDeclarations: false > > +AlwaysBreakTemplateDeclarations: No > > Are 'false' and 'No' different? AlwaysBreakBeforeMultilineStrings is false. They are definitely different for AlwaysBreakTemplateDeclarations. And as mentioned above, false isn't documented to be a valid value for that setting anyway. AlwaysBreakBeforeMultilineStrings is defined to take true/false.
Ross Kirsling
Comment 17 2021-03-24 17:06:43 PDT
(In reply to Cameron McCormack (:heycam) from comment #3) > Looking at https://clang.llvm.org/docs/ClangFormatStyleOptions.html, we need > to set SpaceBeforeCpp11BracedList to true. And I guess update upstream > clang's WebKit defaults as well. Upstream clang's WebKit defaults are already correct -- I added SpaceBeforeCpp11BracedList a few years ago for the purpose of supporting WebKit style. :) https://github.com/llvm/llvm-project/blob/main/clang/lib/Format/Format.cpp#L1314
Cameron McCormack (:heycam)
Comment 18 2021-03-24 17:23:53 PDT
(In reply to Ross Kirsling from comment #17) > Upstream clang's WebKit defaults are already correct -- I added > SpaceBeforeCpp11BracedList a few years ago for the purpose of supporting > WebKit style. :) > https://github.com/llvm/llvm-project/blob/main/clang/lib/Format/Format. > cpp#L1314 Oh, thank you! I should probably go through that to see if there's anything else we're incorrectly overriding.
Note You need to log in before you can comment on or make changes to this bug.