This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] Adds 'friend' to QualifierOrder.
ClosedPublic

Authored by red1bluelost on Dec 11 2022, 2:35 PM.

Details

Summary

For cases of defining friend functions, qualifier ordering can allow multiple
positions for the 'friend' token.

c++
struct S {
  int i;

  friend constexpr auto operator<=>(const S&, const S&) noexcept = default;
};
    1. Changes
  • Adds friend to getTokenFromQualifier
  • Updates documentation in Format.h and ClangFormatStyleOptions.rst
  • Adds tests to QualifierFixerTest.cpp

Testing

Ran FormatTest with no errors.

GitHub Issue

https://github.com/llvm/llvm-project/issues/59450

Diff Detail

Event Timeline

red1bluelost created this revision.Dec 11 2022, 2:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 11 2022, 2:35 PM
red1bluelost requested review of this revision.Dec 11 2022, 2:35 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 11 2022, 2:35 PM
MyDeveloperDay added a project: Restricted Project.

I guess in principle this looks ok, but lets see what the others think @owenpan , @HazardyKnusperkeks

I'm normally way more lenient than the most to add features, but here I have to ask do you want it so that you can get friend always as first, or do you really want to be able to put friend anywhere in the sequence? If only the first, I'd say we do that without adding this option.

I had actually to look up that you can put friend basically anywhere, all examples, tutorials, etc. put it in front. I would discourage that clang-format puts it anywhere else, even though it is valid C++.

Technically: Do we need/want a config parse test for friend?

I would always want it first. I agree that friend would always go first. Had I not accidentally typed in the wrong order I probably wouldn't have know friend could be in any position.

In the case of putting friend always first, would we want a user facing option to enable/disable moving it to first, do it always without an user option, or something else?

If only the first, I'd say we do that without adding this option.

I'll work on doing this without adding the option. (Just reread and noticed you had answered what I asked in my previous comment.)

If only the first, I'd say we do that without adding this option.

I'll work on doing this without adding the option. (Just reread and noticed you had answered what I asked in my previous comment.)

It should be part of the qualifieralignmentfixer, we don't want to move the tokens when someone doesn't have it turned on. My idea would be hardcoded friend as first entry, regardless of the chosen sequence.
But others may have a different opinion on that.

My idea would be hardcoded friend as first entry, regardless of the chosen sequence.
But others may have a different opinion on that.

It would be confusing with QAS_Right and inconsistent with QAS_Custom which allows e.g. inline, static, and volatile to be placed after the type. IMO we should just add friend to QualifierOrder as this patch currently intends to do.

I know I have situations where I like inline and static to be in a certain order to avoid them getting constantly swapped around, they are never going to be after the type but I still want them the same way, I'd be ok with allow friend for the same reason.

I'm just pleased people find this feature useful, despite the original concern raised and the hairiness of the implementation. I also appreciate the concessions made by others to allow clang-format to alter code as this has opened the doors in my view to 1 or 2 other great code modification changes.

MyDeveloperDay accepted this revision.Dec 13 2022, 12:28 AM
This revision is now accepted and ready to land.Dec 13 2022, 12:28 AM

In that case, when someone has free time, could you commit on my behalf (name: Micah Weston, email: micahsweston@gmail.com).

Thank you all for the reviews!

I also appreciate the concessions made by others to allow clang-format to alter code as this has opened the doors in my view to 1 or 2 other great code modification changes.

+1.

owenpan accepted this revision.Dec 22 2022, 1:52 AM
This revision was landed with ongoing or failed builds.Dec 22 2022, 2:04 AM
This revision was automatically updated to reflect the committed changes.