This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Handle builtins in constraint expression
ClosedPublic

Authored by HazardyKnusperkeks on Mar 1 2022, 2:19 PM.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2022, 2:19 PM
HazardyKnusperkeks requested review of this revision.Mar 1 2022, 2:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 1 2022, 2:19 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
curdeius requested changes to this revision.Mar 1 2022, 11:46 PM
curdeius added inline comments.
clang/unittests/Format/FormatTest.cpp
23814

How about other kinds?
This doesn't seem to work for at least ARRAY_TYPE_TRAIT (e.g. concept OneDimensionalArray = __array_rank(T) == 1; and EXPRESSION_TRAIT.

Is there a way to be more generic and treat all identifier-like entities like identifiers?

23814

I'd like to see a test for ALIASes as well, e.g. __is_same_as.

This revision now requires changes to proceed.Mar 1 2022, 11:46 PM

More failing cases: __alignof, alignof (two different categories)

clang/unittests/Format/FormatTest.cpp
23814

How about other kinds?
This doesn't seem to work for at least ARRAY_TYPE_TRAIT (e.g. concept OneDimensionalArray = __array_rank(T) == 1; and EXPRESSION_TRAIT.

I was conservative, since I don't know what these kind of traits are. But sure can add.

Is there a way to be more generic and treat all identifier-like entities like identifiers?

Not that I know of. There is no such function in TokenKind.h.

HazardyKnusperkeks marked an inline comment as done.Mar 3 2022, 3:46 AM
HazardyKnusperkeks added inline comments.
clang/unittests/Format/FormatTest.cpp
23814

I have no idea how to handle the aliases, since there are many, and most are no traits, not correct here. We could add __is_same_as, as it seems to be the only trait alias, directly.

curdeius accepted this revision.Mar 3 2022, 3:56 AM

Thanks for handling other traits! LGTM % alias test.

clang/unittests/Format/FormatTest.cpp
23814

I don't think you need to treat them specially, they should behave as their aliased entity actually. But please test at least one.

This revision is now accepted and ready to land.Mar 3 2022, 3:56 AM
owenpan added inline comments.Mar 3 2022, 4:48 AM
clang/lib/Format/UnwrappedLineParser.cpp
3137–3140

Instead, you can fold case tok::identifier: below into default: like this:

default:
  if (!FormatTok->Tok.getIdentifierInfo())
    return;

  // We need to differentiate identifiers for a template deduction guide,
  ...
HazardyKnusperkeks marked 3 inline comments as done.
HazardyKnusperkeks added inline comments.
clang/lib/Format/UnwrappedLineParser.cpp
3137–3140

Thanks.

owenpan accepted this revision.Mar 7 2022, 12:53 PM
owenpan added inline comments.
clang/lib/Format/UnwrappedLineParser.cpp
3210

Do we still need this line?

3234
cjdb accepted this revision.Mar 7 2022, 1:15 PM

Thanks for working on this!

clang/lib/Format/UnwrappedLineParser.cpp
3210

I'd prefer to get rid of default if we can.

owenpan added inline comments.Mar 7 2022, 1:32 PM
clang/lib/Format/UnwrappedLineParser.cpp
3210

We can't. It's the whole point of the fix.

HazardyKnusperkeks marked 2 inline comments as done.Mar 8 2022, 11:59 AM
HazardyKnusperkeks added inline comments.
clang/lib/Format/UnwrappedLineParser.cpp
3210

Do we still need this line?

No we don't. But I'd like to make it explicit that we handle identifiers here.

3210

I'd prefer to get rid of default if we can.

3234

Can do, but this is how it is used anywhere else in the code.

owenpan added inline comments.Mar 9 2022, 1:22 AM
clang/lib/Format/UnwrappedLineParser.cpp
3210

Can we use a comment instead?

3234

Yeah. Please keep the comment then.

HazardyKnusperkeks marked 4 inline comments as done.Mar 12 2022, 12:48 PM