[PATCH] D121214: [clang-tidy][docs][NFC] Add alias cert-mem51-cpp to bugprone-shared-ptr-array-mismatch

[Balázs Benics via Phabricator via cfe-commits]

steakhal planned changes to this revision.
steakhal added a comment.

In D121214#3372091 <https://reviews.llvm.org/D121214#3372091>, @whisperity wrote:

> In D121214#3369871 <https://reviews.llvm.org/D121214#3369871>, @steakhal wrote:
>
>> Drop the alias-related changes and preserve the note in the `bugprone-shared-ptr-array-mismatch.rst` stating this relationship with the cert rule?
>> If we do it like that, then this will be again NFC.
>
> I would suggest definitely doing that. Perhaps with a bit more emphasis on this one catching the `shared_ptr` case only.

Okay, I'll pick this direction.

> If you could create the check for the `unique_ptr` case, that would also be great.

We will put it on the roadmap, but no promises :D

> I think some of MEM51-CPP is covered by the Static Analyser, right? (Things like `free()`ing a `new`-created pointer.)

Exactly. CSA checkers `unix.MismatchedDeallocator`,`cplusplus.NewDelete`,`cplusplus.NewDeleteLeaks` together can catch all but the last two cases.

> In D121214#3369871 <https://reviews.llvm.org/D121214#3369871>, @steakhal wrote:
>
>> How shall I proceed?
>
> Let's ask @aaron.ballman or @njames93 with regards to that. The long-term solution would be implementing the `1-to-N` check aliasing in the infrastructure, but I understand it might be an out-of-scope work right now.

This is definitely out of scope for me ATM.

> However, I am also in favour of creating a mapping of "partially implemented guidelines" in the documentation somewhere... maybe in the `list.rst`, maybe on a separate page. There, we could start documenting cases like this one... It's less direct than an alias, but more accessible to users who wish to cover as many rules of thumb as possible than having to iterate through hundreds of distinct documentation pages for the checks and trying to deduce //"Hey, so this one makes me catch some of that guideline!"//.

We should also consider the documentation hell, and carefully design a solution that mitigates the already existing burden.
It's already hard to keep everything in sync.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121214/new/

https://reviews.llvm.org/D121214