[clang-tidy] Add comment format configuration to `bugprone-argument-comment`

[Jacobfaib]

TL;DR: Add bugprone-argument-comment.CommentTemplate: <regex> configuration option.

It would be nice if users could have more control over the comment format that clang-tidy considers to be an argument comment. Common use-cases seen in the wild include:

• /* parameter_name */ arg
• arg /* parameter_name */
• /* parameter_name = */ arg

Currently only (exactly) /*paramter_name=*/ works, so the above are not checked for correctness.

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Jacob Faibussowitsch (Jacobfaib)

TL;DR: Add `bugprone-argument-comment.CommentTemplate: <string>` configuration option.

It would be nice if users could have more control over the comment format that clang-tidy considers to be an argument comment. Common use-cases seen in the wild include:

• /* parameter_name */ arg
• arg /* parameter_name */
• /* parameter_name = */ arg

Currently only (exactly) /*paramter_name=*/ works, so the above are not checked for correctness.

[EugeneZelenko]

Aren't formatting details left to Clang-Format? Even if not so, it's good idea to reuse Clang-Format configuration (bunch of comment-related issues were created recently) than create duplicated settings in Clang-Tidy. Obviously such duplication may lead to conflicting formatting in different tools.

[Jacobfaib]

It's not a formatting request. I don't want clang-tidy to format, I want clang-tidy to fire the checks on differently formatted code. Let me give an example:

void foo(int param);

foo(/*not_param=*/1); // clang-tidy will warn

foo(/* not_param = */ 1); // clang-tidy will NOT warn
foo(/* not_param */ 1); // clang-tidy will NOT warn
foo(1 /* not_param */); // clang-tidy will NOT warn

I want clang-tidy to warn on all such cases. To do that, I want the ability to tell clang-tidy what patterns of inline comments to look for.

[Jacobfaib]

Ah I suppose your point about formatting would apply to the fix-its that clang-tidy might generate. I guess in that case, it can either arbitrarily pick a format, or reuse the given regex format to generate the inline comment?

[vbvictor]

reuse the given regex format to generate the inline comment

Thin could be tricky to do because regex can accept a lot of different comment layouts (e.g. with = or without =) but what fixit should be generated for this case?

I guess we can do this task in 2 steps: first create regex for CommentTemplate, then think and implement better fixits. Having incorrectly formatted fixits may be even OK for us because maybe clang-format would format them in the future or user will manually adjust.

[LegalizeAdulthood]

A regex feels like overkill here. Just extend the check to recognize comments before or after the argument containing the parameter name.