[PATCH] D79773: [clang-format] Improve clang-formats handling of concepts

Manuel Klimek via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 9 04:32:42 PDT 2020


klimek added inline comments.


================
Comment at: clang/lib/Format/UnwrappedLineParser.cpp:631-636
+  else if (FormatTok->is(tok::arrow)) {
+    // Following the } we can find a trailing return type arrow
+    // as part of an implicit conversion constraint.
+    nextToken();
+    parseStructuralElement();
+  }
----------------
I'd have expected this to be just in front of line 629 (if... tok::semi) - does that break something? Don't we want to munch the semi after this?


================
Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2314
+      nextToken();
+      if (FormatTok->Tok.is(tok::less)) {
+        while (!FormatTok->Tok.is(tok::greater)) {
----------------
MyDeveloperDay wrote:
> miscco wrote:
> > miscco wrote:
> > > I guess you could use `parseBracedList(/*ContinueOnSemicolons=*/false, /*IsEnum=*/false,/*ClosingBraceKind=*/tok::greater);` here?
> > To be more specific, I am concerned what happens if you have multiple template arguments where a linebreak should occur. Is this still happening here?
> > 
> > 
> > ```
> > template <typename someLongTypename1, typename someLongTypename2>
> > concept someVeryLongConceptName = someVeryLongConstraintName1<someLongTypename1 && someLongTypename2>;
> > ```
> This is formatted as
> 
> ```
> template <typename someLongTypename1, typename someLongTypename2>
> concept someVeryLongConceptName =
>     someVeryLongConstraintName1<someLongTypename1 && someLongTypename2>;
> ```
This seems like a very detailed way to parse them; generally, we try to only parse rough structure here.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79773/new/

https://reviews.llvm.org/D79773





More information about the cfe-commits mailing list