[PATCH] D48728: [clang-format] Do not format raw string literals inside a recognized function with a non-recognized delimiter

krasimir created this revision. Herald added a subscriber: cfe-commits. This stops clang-format from touching raw string contents with unrecognized delimiters inside recognized functions. Unrecognized delimiters signal that the string might be special. Repository: rC Clang https://reviews.ll

[PATCH] D48728: [clang-format] Do not format raw string literals inside a recognized function with a non-recognized delimiter

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rL335876: [clang-format] Do not format raw string literals inside a recognized function… (authored by krasimir, committed by

[PATCH] D48760: [clang-format] Support additional common functions for text proto formatting

krasimir created this revision. Herald added a subscriber: cfe-commits. This adds a few more common function names expecting a text proto argument. Repository: rC Clang https://reviews.llvm.org/D48760 Files: lib/Format/Format.cpp Index: lib/Format/Format.cpp =

[PATCH] D48098: clang-format-diff: Switch to python3 by default, support python 2.7

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Checked with both python 2 and python 3 as suggested. Works like a charm! Thank you! https://reviews.llvm.org/D48098 ___ cfe-commits mailing

[PATCH] D48760: [clang-format] Support additional common functions for text proto formatting

This revision was automatically updated to reflect the committed changes. Closed by commit rC335978: [clang-format] Support additional common functions for text proto formatting (authored by krasimir, committed by ). Changed prior to commit: https://reviews.llvm.org/D48760?vs=153459&id=153491#t

[PATCH] D48827: [clang-format ]Extend IncludeCategories regex documentation

krasimir requested changes to this revision. krasimir added a comment. This revision now requires changes to proceed. This file is automatically generated from `Format.h` using `clang/docs/tools/dump_format_style.py`. Please update. Repository: rC Clang https://reviews.llvm.org/D48827 ___

[PATCH] D48827: [clang-format ]Extend IncludeCategories regex documentation

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Repository: rC Clang https://reviews.llvm.org/D48827 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.

[PATCH] D68695: [clang-format] Update noexcept reference qualifiers detection

krasimir created this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. krasimir added reviewers: AndWass, MyDeveloperDay. r373165 fixed an issue where a templated noexcept member function with a reference qualifier would be indented more than expected: // Formatt

[PATCH] D68695: [clang-format] Update noexcept reference qualifiers detection

krasimir marked an inline comment as done. krasimir added inline comments. Comment at: unittests/Format/FormatTest.cpp:7093 " template \n" - " int& foo(const std::string& str) const & noexcept {}\n" + " int& foo(const std::string& st

[PATCH] D68695: [clang-format] Update noexcept reference qualifiers detection

krasimir marked 3 inline comments as done. krasimir added inline comments. Comment at: lib/Format/TokenAnnotator.cpp:1499 +} else if (Current.isOneOf(tok::identifier, tok::kw_const, + tok::kw_noexcept) && Current.Previous && -

[PATCH] D68695: [clang-format] Update noexcept reference qualifiers detection

This revision was automatically updated to reflect the committed changes. krasimir marked an inline comment as done. Closed by commit rGae1b7859cbd6: [clang-format] Update noexcept reference qualifiers detection (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D68695?vs

[PATCH] D69164: [clang-format] fix regression recognizing casts in Obj-C calls

krasimir created this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. krasimir edited the summary of this revision. krasimir added a reviewer: MyDeveloperDay. r373922 added checks for a few tokens that, following an `)` make it unlikely that the `)` is the closing

[PATCH] D69164: [clang-format] fix regression recognizing casts in Obj-C calls

This revision was automatically updated to reflect the committed changes. Closed by commit rGeff2a2ab2b51: [clang-format] fix regression recognizing casts in Obj-C calls (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D69164?vs=225604&id=225635#toc Repository: rG LL

[PATCH] D69164: [clang-format] fix regression recognizing casts in Obj-C calls

krasimir marked an inline comment as done. krasimir added inline comments. Comment at: lib/Format/TokenAnnotator.cpp:1612 + Keywords.kw_final) || +isCpp11AttributeSpecifier(*Tok.Next)) return false; rdwampler wrote: > I thi

[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

krasimir added a comment. Just some thoughts. I agree that `Style.isJavaScript()` is nicer than `Style.Language == FormatStyle::LK_JavaScript`, but overall the tradeoffs about adding convenience methods are not clear to me. C++/ObjC/ObjC++ is special -- because ObjC++ exists I think it is usef

[PATCH] D50078: clang-format: support aligned nested conditionals formatting

krasimir added a comment. I'm happy with this patch! We found a couple of rough edges: - alignment after `?:` and - new formatting of `_ ? _ ? _ : _ : _` patterns is bad These are illustrated as examples D and E below (A, B and C look good to me). `test.cc` is how I'd expect clang-format to be

[PATCH] D80144: [clang-format] @lefticus just taught the world how to use [[unlikely]] but we forgot to teach clang-format

krasimir added a comment. Unfortunately this introduced a bad regression with ObjC method expressions in `if` bodies: if (argc > 5) [obj func:arg]; is now formatted as: if (argc > 5)[obj func:arg] ; It seems that at this stage of processing it would be non-trivial to distinguish betw

[PATCH] D80144: [clang-format] @lefticus just taught the world how to use [[unlikely]] but we forgot to teach clang-format

krasimir added a comment. In D80144#2053543 , @MyDeveloperDay wrote: > maybe for now we just do > > if (FormatTok->is(tok::l_square) && !Style.isObjC()) > parseSquare(); > I tried this, however FormatTest.cpp's verifyFormat is picky and explicit

[PATCH] D80144: [clang-format] @lefticus just taught the world how to use [[unlikely]] but we forgot to teach clang-format

krasimir added a comment. In D80144#2054451 , @MyDeveloperDay wrote: > Will this help? D80547: [clang-format] Fix an ObjC regression introduced with > new [[likely]][[unlikely]] support in if/else clauses > This is aw

[PATCH] D80547: [clang-format] Fix an ObjC regression introduced with new [[likely]][[unlikely]] support in if/else clauses

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2348 +// its not then rewind to the original position +bool UnwrappedLineParser::tryToParseAttribute() { + unsigned StoredPosition = Tokens->getPosition(); MyDeveloperDay wrote:

[PATCH] D80547: [clang-format] Fix an ObjC regression introduced with new [[likely]][[unlikely]] support in if/else clauses

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2349 +// ahead in the token source. +class AutoTokenPosition { + unsigned StoredPosition; nit: I've seen similar RAII idioms in lib/Format use names like [[ https://github.com/

[PATCH] D80547: [clang-format] Fix an ObjC regression introduced with new [[likely]][[unlikely]] support in if/else clauses

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. This is nice! Thank you! Ran this through a mix of C++ and Objective-C sources and didn't spot any regressions from pre-D80144. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D8054

[PATCH] D50078: clang-format: support aligned nested conditionals formatting

krasimir added a comment. In D50078#2053324 , @krasimir wrote: > I'm happy with this patch! > > We found a couple of rough edges: > > - alignment after `?:` and > - new formatting of `_ ? _ ? _ : _ : _` patterns is bad > > These are illustrated as exampl

[PATCH] D84090: [clang-format] Add SpaceAroundBitFieldColon option

krasimir added a comment. @wanders, thank you for digging through code to get a feeling of the usage! I agree with others to have an enum option. +1 to `None` over `Neither`. I'd prefer `Before` / `After` instead of `Left` / `Right`; those seem more prevalent in names and values of existing opti

[PATCH] D77311: clang-format: [JS] detect C++ keywords.

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77311/new/ https://reviews.llvm.org/D77311 _

[PATCH] D77311: clang-format: [JS] detect C++ keywords.

krasimir added inline comments. Comment at: clang/lib/Format/FormatToken.h:913 bool IsJavaScriptIdentifier(const FormatToken &Tok) const { -return Tok.is(tok::identifier) && - JsExtraKeywords.find(Tok.Tok.getIdentifierInfo()) == - JsExtraKeywords.en

[PATCH] D75364: [clang-format] Handle macros in function params and return value

krasimir added a comment. I think situations where we infer M(x) to expand to a "type" without const/volatile close-by are too ambiguous an we will have the opposite problem: formatting certain binary expressions as type pointer/references. Some sort of a list of macros that clang-format assume

[PATCH] D75364: [clang-format] Handle macros in function params and return value

krasimir added a comment. A sample of snippets that this misformats: - inside other macro: EXPECT_EQ(Calc()* bar, baz); - in member function call: BENCHMARK(BM_Foo)->ThreadRange(1, NumCPUs()* 2); - this causes javascript diffs: - const foo = (bar == 'rtl' ? -1 : 1) * (blah || blah || 0

[PATCH] D77548: clang-format: [JS] handle pseudo-keywords.

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Looks good! The linter suggests a few formatting fixes. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D77548/new/ https://reviews.llvm.org/D7

[PATCH] D80950: [clang-format] [PR44542,38872] String << String always get a forced newline.

krasimir added a comment. Another //weak// argument about why the current rule makes sense (break before `<<` between two string literals) is: suppose you don't want such a break. Then you can //change your code// to concatenate the two string literals into a single one, avoiding the problem al

[PATCH] D81394: [clang-format] Brace breaking for C# lambdas

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81394/new/ https://reviews.llvm.org/D81394 ___ cfe-commits mailing list cfe

[PATCH] D81467: [clang-format] Microsoft style fixes for C# properties

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81467/new/ https://reviews.llvm.org/D81467 _

[PATCH] D82181: [clang-format] indent in chained conditionals when AlignOperands:DontAlign

krasimir created this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. TODO Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D82181 Files: clang/lib/Format/ContinuationIndenter.cpp Index: clang/lib/Format/ContinuationIndenter.cpp ==

[PATCH] D82181: [clang-format] indent in chained conditionals when AlignOperands:DontAlign

krasimir updated this revision to Diff 272084. krasimir added a comment. - add a regression test Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82181/new/ https://reviews.llvm.org/D82181 Files: clang/unittests/Format/FormatTest.cpp Index: clang

[PATCH] D82199: [clang-format] restore indent in conditionals AlignOperands is DontAlign

krasimir created this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. krasimir edited the summary of this revision. After D50078 , we're experiencing unexpected un-indent using a style combining `AlignOperands: DontAlign` with `Br

[PATCH] D82199: [clang-format] restore indent in conditionals when AlignOperands is DontAlign

krasimir updated this revision to Diff 272957. krasimir marked an inline comment as done. krasimir added a comment. - add a FIXME Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82199/new/ https://reviews.llvm.org/D82199 Files: clang/unittests/For

[PATCH] D82199: [clang-format] restore indent in conditionals when AlignOperands is DontAlign

krasimir updated this revision to Diff 272964. krasimir added a comment. - refresh Phabricator diff Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82199/new/ https://reviews.llvm.org/D82199 Files: clang/unittests/Format/FormatTest.cpp Index: cl

[PATCH] D82199: [clang-format] restore indent in conditionals when AlignOperands is DontAlign

krasimir updated this revision to Diff 272966. krasimir added a comment. - try to update Phabricator diff Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82199/new/ https://reviews.llvm.org/D82199 Files: clang/lib/Format/ContinuationIndenter.cpp

[PATCH] D82199: [clang-format] restore indent in conditionals when AlignOperands is DontAlign

This revision was automatically updated to reflect the committed changes. Closed by commit rG0fad648b65b9: [clang-format] restore indent in conditionals when AlignOperands is DontAlign (authored by krasimir). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.

[PATCH] D82199: [clang-format] restore indent in conditionals when AlignOperands is DontAlign

krasimir marked an inline comment as done. krasimir added inline comments. Comment at: clang/unittests/Format/FormatTest.cpp:6287 + Style.BreakBeforeTernaryOperators = false; + verifyFormat("int x = aaa ? aa :\n" + "

[PATCH] D78295: [clang-format] Do not interpret C# deconstruction in a foreach as a cast

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Nice! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78295/new/ https://reviews.llvm.org/D78295 __

[PATCH] D78642: [clang-format] Handle C# property accessors when parsing lines

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78642/new/ https://reviews.llvm.org/D78642 ___ cfe-commits mailing list cfe

[PATCH] D78694: [clang-format] Fix lambda with ellipsis in return type

krasimir added a comment. Could you please update the patch with full context: https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface This helps out when reviewing. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78694/new/

[PATCH] D78915: [clang-format] Improved parser for C# properties

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:1508 bool HasGetOrSet = false; + bool IsTrivialPropertyAccessor = true; while (!eof()) { Add a comment illustrating is what is a trivial property accessor. CHANGES SINCE

[PATCH] D78694: [clang-format] Fix lambda with ellipsis in return type

krasimir added a comment. Thank you! I think this is OK as-is. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78694/new/ https://reviews.llvm.org/D78694 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/

[PATCH] D78915: [clang-format] Improved parser for C# properties

krasimir accepted this revision. krasimir added a comment. Thank you! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78915/new/ https://reviews.llvm.org/D78915 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cg

[PATCH] D79000: [clang-format] C# property formatting can be controlled by config options

krasimir added a comment. I'm curious why we don't go the opposite direction -- why are even those two styles needed separately? public int Style1 { get; set } // vs. public int Style2 { get; set } I'm sure there is a good reason; part of this is to make sure we document it so we may c

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

krasimir added a comment. Awesome! Thank you! Now that we've got "clang/phabricator/lint/git" robots that leave comments on patches, we may want to think about a way to have this automatically enforced in the future. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://re

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

krasimir added a comment. In D79095#2010271 , @MyDeveloperDay wrote: > In D79095#2010250 , @krasimir wrote: > > > Awesome! Thank you! > > Now that we've got "clang/phabricator/lint/git" robots that leave comments

[PATCH] D79172: [clang-format] [PR45626] SpacesInAngles does not insert or preserve leading space before :: operator

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Comment at: clang/unittests/Format/FormatTest.cpp:8486 + FormatStyle SpaceBetweenBraces = getLLVMStyle(); nit: I suppose this newline was

[PATCH] D85016: [clang-format] Add space between method modifier and a tuple return type in C#

krasimir accepted this revision. krasimir added a comment. Thank you! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85016/new/ https://reviews.llvm.org/D85016 ___ cfe-commits mailing list cfe-commits@lis

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2401 // The actual identifier can be a nested name specifier, and in macros // it is often token-pasted. while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::hashhash, --

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

krasimir added a comment. I have an example where this goes wrong in ObjC (modulo indentation): struct Stuff stuff[] = {

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

krasimir added a comment. I'm not familiar with ObjC, but hope this helps: % cat ~/example.mm # left as-is by clang-format without D79354 (int)f : (int)arg { struct A as[] = {{a11, a12}, // {a21, a22}, // {nil, 0}}; retur

[PATCH] D79000: [clang-format] C# property formatting can be controlled by config options

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. I think this is OK as-is. @MyDeveloperDay's suggestion of adding AfterProperty to the BraceWrapping style makes sense. However I think in this case it is natural to use the same style for

[PATCH] D79293: [clang-format] [PR45218] Fix an issue where < and > and >> in a for loop gets incorrectly interpreted at a TemplateOpener/Closer

krasimir added a comment. I think these examples are too ambiguous for clang-format to try and format correctly. Sadly for C++, correctly distinguishing between `>>`, the binary operator, and `>>`, the sequence of two closing template brackets, requires semantic analysis, I believe. Such heuris

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2405 tok::kw___attribute, tok::kw___declspec, -tok::kw_alignas) || +tok::kw_alignas, tok::l_square) ||

[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

krasimir marked an inline comment as done. krasimir added inline comments. Comment at: clang/lib/Format/Format.cpp:691 +/*SplitEmptyRecord=*/true, +/*SplitEmptyNamespace=*/true}; switch (Style.BreakBeforeBraces) { ---

[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

krasimir added a comment. I think we should never break apart the two `[[` and `]]` of attributes. Running that example with `-debug` shows that we consider breaking between the two `[` tokens a valid possibility. - `C=1` means breaking before the token is OK, which is probably computed by `Tok

[PATCH] D79401: [clang-format] [PR45639] clang-format splits up the brackets of C++17 attribute [[ ]] when used with the first parameter

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79401/new/ https://reviews.llvm.org/D79401 ___ cfe-commits mailing list cfe

[PATCH] D79354: [clang-format] [PR34574] Handle [[nodiscard]] attribute in class declaration

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Looks good with a couple of nits. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2402 // it is often token-pasted. + // An [[attribute]] can be befor

[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2170 parseBlock(/*MustBeDeclaration=*/false); -if (Style.BraceWrapping.IndentBraces) +if (Style.BraceWrapping.IndentBraces || Style.BraceWrapping.BeforeWhile) addUnwrappedLine

[PATCH] D79715: [clang-format] Update GoogleStyle for C# code to match Google's internal C# style guide

krasimir added a comment. In D79715#2029390 , @jbcoe wrote: > I expect that accepting this patch will need require an update to be made to > https://github.com/google/styleguide. I agree; it would be useful to leave a comment somewhere in this code with

[PATCH] D79935: [clang-format] [PR44345] Long namespace closing comment is duplicated endlessly

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Awesome! Thank you! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79935/new/ https://reviews.llvm.org/D79935

[PATCH] D79990: [clang-format] [PR45614] Incorrectly indents [[nodiscard]] attribute funtions after a macro without semicolon

krasimir added inline comments. Comment at: clang/lib/Format/UnwrappedLineParser.cpp:906 // trailing semicolons from other constructs split to several lines. -static bool tokenCanStartNewLine(const clang::Token &Tok) { +static bool tokenCanStartNewLine(const FormatToken *Tok) {

[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79325/new/ https://reviews.llvm.org/D79325 ___ cfe-commits mailing list cfe

[PATCH] D40310: Restructure how we break tokens.

krasimir added inline comments. Comment at: lib/Format/BreakableToken.cpp:198 + "Getting the length of a part of the string literal indicates that " + "the code tries to reflow it."); + return UnbreakableTailLength + Postfix.size() + klimek wrote

[PATCH] D40310: Restructure how we break tokens.

krasimir added a comment. Started the review. It would take a few cycles 💃 Comment at: lib/Format/ContinuationIndenter.cpp:1518 + unsigned RemainingTokenColumns = 0; + // The column number we're currently at. + unsigned ContentStartColumn = 0; Could you plea

[PATCH] D40288: [clang-format] Add option to group multiple #include blocks when sorting includes

krasimir removed a reviewer: krasimir. krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! Do you have commit access? Repository: rL LLVM https://reviews.llvm.org/D40288 ___ cfe-c

[PATCH] D40435: [clang-format] Deduplicate using declarations

krasimir updated this revision to Diff 124215. krasimir added a comment. - Address review comments https://reviews.llvm.org/D40435 Files: lib/Format/UsingDeclarationsSorter.cpp unittests/Format/UsingDeclarationsSorterTest.cpp Index: unittests/Format/UsingDeclarationsSorterTest.cpp ===

[PATCH] D40435: [clang-format] Deduplicate using declarations

This revision was automatically updated to reflect the committed changes. Closed by commit rL318960: [clang-format] Deduplicate using declarations (authored by krasimir). Repository: rL LLVM https://reviews.llvm.org/D40435 Files: cfe/trunk/lib/Format/UsingDeclarationsSorter.cpp cfe/trunk/

[PATCH] D40288: [clang-format] Add option to group multiple #include blocks when sorting includes

This revision was automatically updated to reflect the committed changes. Closed by commit rL319024: [clang-format] Add option to group multiple #include blocks when sorting… (authored by krasimir). Changed prior to commit: https://reviews.llvm.org/D40288?vs=123924&id=124361#toc Repository:

[PATCH] D40310: Restructure how we break tokens.

krasimir added inline comments. Comment at: lib/Format/ContinuationIndenter.cpp:1525 + if (!DryRun) +Token->adaptStartOfLine(0, Whitespaces); + If we indent here, shouldn't that also change ContentStartColumn? Comment at: lib/Format/Contin

[PATCH] D40310: Restructure how we break tokens.

krasimir added inline comments. Comment at: lib/Format/BreakableToken.cpp:178 Split Split) const { // Example: consider the content // lala lala Offtopic: Should add a FIXME that this doesn't really work in th

[PATCH] D40310: Restructure how we break tokens.

krasimir added a comment. Re: "I tried to write a test for this, and convinced myself that while +1 is correct, it is currently impossible to change behavior based on the missing +1.": In order to have different outcome based on the start column, you could use tabs. Consider the content `"aaa\t

[PATCH] D40310: Restructure how we break tokens.

krasimir added inline comments. Comment at: lib/Format/ContinuationIndenter.cpp:1749 + } + if (!Reflow) { +// If we didn't reflow into the next line, the only space to consider is nit: Maybe change this to `if (Reflow)` and switch the if-else b

[PATCH] D40310: Restructure how we break tokens.

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. LGTM https://reviews.llvm.org/D40310 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/c

[PATCH] D40605: Better trade-off for excess characters vs. staying within the column limits.

krasimir added a subscriber: djasper. krasimir added inline comments. Comment at: lib/Format/ContinuationIndenter.cpp:1422 + Strict); +} } The problem here is that we're calling breakProtrudingToken 3 times more than we used to.

[PATCH] D40605: Better trade-off for excess characters vs. staying within the column limits.

krasimir added inline comments. Comment at: unittests/Format/FormatTest.cpp:10007 +format("// foo foo foo foo foo foo foo foo foo foo foo foo\n", + Style)); } Could you also add a test with line comments surrounded by stuff,

[PATCH] D40832: [clang-format] Adds canonical raw string delimiters support

krasimir created this revision. Herald added subscribers: cfe-commits, klimek. A canonical raw string delimiter for a given language is the preferred raw string delimiter to use for that language. For example, both 'pb' and 'proto' could serve to indentify a raw string literal as a proto string,

[PATCH] D40832: [clang-format] Adds canonical raw string delimiters support

krasimir updated this revision to Diff 125501. krasimir added a comment. - Update documentation Repository: rC Clang https://reviews.llvm.org/D40832 Files: docs/ClangFormatStyleOptions.rst include/clang/Format/Format.h lib/Format/ContinuationIndenter.cpp lib/Format/Format.cpp unitt

[PATCH] D40832: [clang-format] Adds canonical raw string delimiters support

krasimir updated this revision to Diff 125557. krasimir added a comment. - Make 'textproto' the canonical text proto delimiter for google style Repository: rC Clang https://reviews.llvm.org/D40832 Files: docs/ClangFormatStyleOptions.rst include/clang/Format/Format.h lib/Format/Continua

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir created this revision. Herald added subscribers: cfe-commits, klimek. Repository: rC Clang https://reviews.llvm.org/D40909 Files: include/clang/Format/Format.h lib/Format/ContinuationIndenter.cpp lib/Format/ContinuationIndenter.h lib/Format/Format.cpp unittests/Format/Format

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir updated this revision to Diff 125915. krasimir added a comment. - Added unsafe canonical delimiter update handling Repository: rC Clang https://reviews.llvm.org/D40909 Files: include/clang/Format/Format.h lib/Format/ContinuationIndenter.cpp lib/Format/ContinuationIndenter.h

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir updated this revision to Diff 125921. krasimir added a comment. - Added support for enclosing function names Repository: rC Clang https://reviews.llvm.org/D40909 Files: include/clang/Format/Format.h lib/Format/ContinuationIndenter.cpp lib/Format/ContinuationIndenter.h lib/Fo

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir updated this revision to Diff 125927. krasimir added a comment. - Updated documentation Repository: rC Clang https://reviews.llvm.org/D40909 Files: docs/ClangFormatStyleOptions.rst include/clang/Format/Format.h lib/Format/ContinuationIndenter.cpp lib/Format/ContinuationInden

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir added inline comments. Comment at: include/clang/Format/Format.h:1375 +std::vector EnclosingFunctionNames; +/// \brief The canonical delimiter for this language. +std::string CanonicalDelimiter; djasper wrote: > Can you pull apart this patch?

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir added inline comments. Comment at: lib/Format/Format.cpp:920 + if (LanguageFound) { +for (int i = Styles.size() - 1; i >= 0; --i) { + if (Styles[i].Language == FormatStyle::LK_None) { djasper wrote: > I think this is getting a bit convoluted an

[PATCH] D40909: [clang-format] Reorganize raw string delimiters

krasimir updated this revision to Diff 125939. krasimir edited the summary of this revision. krasimir added a comment. - Address review comments Repository: rC Clang https://reviews.llvm.org/D40909 Files: docs/ClangFormatStyleOptions.rst include/clang/Format/Format.h lib/Format/Continu

[PATCH] D41108: [clang-format] Improve ObjC headers detection.

krasimir accepted this revision. krasimir added a comment. This revision is now accepted and ready to land. Thank you! I'll go ahead and commit this for you! Repository: rC Clang https://reviews.llvm.org/D41108 ___ cfe-commits mailing list cfe-co

[PATCH] D121584: [clang-format] Correctly recognize arrays in template parameter list.

krasimir added a comment. > It appears that this regressed some ObjC patterns: @curdeius any progress on this? If not, could we revert this for now? Internally we've got enough of these regressing ObjC patterns that we can't release clang-format with this. Repository: rG LLVM Github Monorep

[PATCH] D121758: [clang-format] Add support for formatting Verilog code

krasimir added inline comments. Comment at: clang/lib/Format/Format.cpp:3451 +for (auto Suffix : Lang.second) + if (FileName.endswith(Suffix)) +return Lang.first; I kinda prefer the old style of handling this I find it simpler to read. I'd be OK

[PATCH] D121451: [clang-format] Add space to comments starting with '#'.

krasimir added a comment. This appears to have broken a relatively common pattern we see in text proto comments where sections use a style like this: # Big section name ##

[PATCH] D121451: [clang-format] Add space to comments starting with '#'.

krasimir added a comment. In D121451#3395611 , @curdeius wrote: > In D121451#3395578 , @krasimir > wrote: > >> This appears to have broken a relatively common pattern we see in text proto >> comments where secti

[PATCH] D121451: [clang-format] Add space to comments starting with '#'.

krasimir added a comment. This is getting more fun: the reason why `///` isn't broken up is because the first character `/` after the comment leader `//` is considered punctuation per isPunctuation's CHAR_RAWDEL, which includes all these `{}[]#<>%:;?*+-/^&|~!=,"'`: - https://github.com/llvm/l

[PATCH] D121584: [clang-format] Correctly recognize arrays in template parameter list.

krasimir added a comment. It appears that this regressed some ObjC patterns: % cat test.m # before: good void f() { // BOOL a = [b.c count] > 1; int b = a; } % clang-format -style=google test.m # after: bad, statements joined on the same line void f() { // BOOL a

[PATCH] D121451: [clang-format] Add space to comments starting with '#'.

krasimir added a comment. > So I'd rather keep the old behaviour for # in Proto but not in C-like > languages. Is that acceptable? Sounds good. I'll work on a patch doing that. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121451/new/ https://rev

[PATCH] D122230: [clang-format] don't break up #-style comment sections

krasimir created this revision. Herald added a project: All. krasimir requested review of this revision. Herald added a project: clang. Herald added a subscriber: cfe-commits. Follow-up from https://github.com/llvm/llvm-project/commit/36d13d3f8adb3d1a6bae71370afa23d11a94dc78. Restore the old beh

[PATCH] D122230: [clang-format] don't break up #-style comment sections

This revision was landed with ongoing or failed builds. This revision was automatically updated to reflect the committed changes. Closed by commit rGeb35e0ecbe0a: [clang-format] don't break up #-style comment sections (authored by krasimir). Repository: rG LLVM Github Monorepo CHANGES SINCE LA

[PATCH] D121370: [clang-format] SortIncludes should support "@import" lines in Objective-C

krasimir added a comment. It appears that this regressed include sorting in the following case, where the contents of `test.h` show the expected include order and the `clang-format` behavior before this patch: % cat test.h #include #include "util/bar.h" #include "util/foo/foo.h" //

<    1   2   3   4   5   6   7   8   9   10   >