[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