In D147062#4228403, @ccotter wrote:

If https://github.com/isocpp/CppCoreGuidelines/issues/2060 is accepted to only consider [=], then I assume we'd want to change the default value of IgnoreCaptureDefaultByReference to be true? Thanks by the way for this!

Fix typo in doc.

Clean up check suffix in test.

Move implementation to .cpp file.

LGTM, thanks!

In D145617#4221369, @PiotrZSL wrote:

@carlosgalvezp Do you want me to shorten documentation ? Or we leave it like it is ?

Reading through Github I found the associated ticket (it would be good if you could mention it in the commit message):
https://github.com/llvm/llvm-project/issues/61520

Also, regarding clang-analyzer-core checks, I have 2 tickets open:

I'm not sure I follow - if you enable warnings as error for all checks, then the expectation is that you indeed get an error if you violate one of the clang-analyzer checks. In what way is this not wanted?

I noticed the pre-merge checks are red, however, would be good to get them fixed.

LGTM thank you! Really useful check! I'm not very expert in the PP callbacks so I can't give much feedback, feel free to wait for other more expert reviewers if you want.

Looks really good, thank you! I have only very minor comments, mostly style nits and suggestions for improved readability.

Fix missing naming convention in the test.

Remove excessive newline

Update commit message

Add to release notes.

Rebase

Without this patch, the suggested fix in a C file by clang-tidy is iRevValid instead of rtRevValid.

Looks good, minor comments!

Looks good but I fail to understand what exactly the patch fixes, can you point me to an example in the tests? It would be easier to review if the NFC changes had been done in a separate patch.

In D145312#4187247, @PiotrZSL wrote:

In D145312#4187195, @carlosgalvezp wrote:

@PiotrZSL I believe you have landed some patches of this chain. Would you mind sharing how you do it? I'm not an expert in Phabricator and simply doing arc patch D145312 leads to cherry-pick conflicts, and when I solve them I don't end up having this patch as HEAD. With this knowledge I will be able to help out closing these patches!

arc patch --nobranch --skip-dependencies D145312
I will push them...

@mikecrowe I seems I cannot land this until it's rebased on top of main, would you be able to do that? Thanks!

@PiotrZSL I believe you have landed some patches of this chain. Would you mind sharing how you do it? I'm not an expert in Phabricator and simply doing arc patch D145312 leads to cherry-pick conflicts, and when I solve them I don't end up having this patch as HEAD. With this knowledge I will be able to help out closing these patches!

LGTM, thanks for the fix!

Looks good, just a small comment!

LGTM, clang_apply_replacements_binary is only used in a if args.fix block.

In D145304#4169810, @yeputons-gh wrote:

Absolutely, give we few minutes. Maybe it conflicts with the previous revision that has already landed?

It seems I'm having trouble to download the patch with arcanist, would you mind rebasing on top of the main branch? Thanks!

LGTM!

Could you upload the patch with full context? I believe you need to do something like git show HEAD -U999999 as per the guidelines. Otherwise arc diff should do the job automatically. Reason I ask is that I cannot see the new line numbers referred to by the note comments - Phab says "Context not available".

LGTM, would you mind rebasing to get the pre-merge jobs green?

In D144216#4169781, @mikecrowe wrote:

In D144216#4169772, @carlosgalvezp wrote:

In D144216#4169764, @mikecrowe wrote:

I will double check that this is true once my current build is complete.

Yes, it's true. I stuck a #error in clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/string.h and I saw the expected error from a file including <string>.

Awesome, thanks for checking, I wasn't aware we already had string.h. Then if we do have headers named the same as the standard headers, would it make sense to name this header cstring instead of string?

I think you mean rename string.h to cstring. (string clearly has to be just string if it's the standard C++ string header.)

A bit of searching in the existing checks shows that string.h is included by C checks (bugprone/signal-handler*.c) and also by checks that deliberately want string.h so they can suggest switching to cstring (modernize/deprecated-headers*) so it looks like it's necessary to keep string.h. If you wish, a cstring wrapper that just includes string.h could be created, but it really ought to put everything in namespace std too. (If so, I think this would probably be better done as a separate change.)

In D144216#4169764, @mikecrowe wrote:

I will double check that this is true once my current build is complete.

Yes, it's true. I stuck a #error in clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/string.h and I saw the expected error from a file including <string>.

Thanks for the fix!

Sounds good, should we land this? If you don't have commit rights, please let us know Github name and email for attribution.

Thanks for the fix! Can you land the patch or would need that we do it for you? If so please provide Github name and email for attribution.

LGTM, thanks!

Looks good, thanks! Please document change in the Release Notes.

Great improvement, thanks!

LGTM, minor comments. I'm not familiar with the implementation so I'm not very confident reviewing it, would be good to get some more expert eyes on it. Tests look solid!

LGTM, thanks for the contribution! Do you have commit rights or would you like that we land it for you? If so, please provide name and email for attribution.

In D142587#4152943, @Eugene.Zelenko wrote:

@carlosgalvezp: Sorry, there are too much Clang specifics in this patch, so I could not be reviewer.

Good catch, thanks for fixing!

Thanks for the fix! I have some suggestions for improved readability.

Thanks for the fix! Looks good, have a couple minor comments.