[cfe-dev] [clang-tidy] Some possible contributions
Piotr Dziwinski via cfe-dev
cfe-dev at lists.llvm.org
Thu Oct 15 12:56:04 PDT 2015
On 2015-10-13 22:33, Richard via cfe-dev wrote:
> [Please reply *only* to the list and do not include my email directly
> in the To: or Cc: of your reply; otherwise I will not see your reply.
> Thanks.]
As you wish.
>> I would like to hear, what you think about that. Should some of these
>> styles, e.g. relying on pointer to bool conversion in "if (pointer) {}",
>> be allowed? Maybe I should add config option to enable/disable my check
>> in such cases?
> I did some snooping of these situations in my simplify-bool-expr check.
>
> In my check, I simplified
>
> if (p) { return true; } else { return false; }
>
> to
>
> return p != nullptr;
>
> This turned the implicit cast to bool into an explicit comparison
> resulting in a bool.
>
> The only idioms that I think you need to allow for are:
>
> if (p) x; else y;
> if (!p) x; else y;
> p ? e : f;
> !p ? e : f;
>
> where p is some pointer. Maybe there are some other common idioms
> that exploit implicit conversion to bool, but that's all I could think
> of right now.
>
> That list is pretty small, so it shouldn't be hard to handle. I do
> recommend the idea of adding a configuration option to switch the
> behavior to warn even in these cases. Some people do prefer the more
> explicit check against nullptr.
Yes, I was thinking along the same lines. It seems that these are the
most common cases, where people rely on evaluating pointer as boolean.
I'll provide a config option and conditionally exclude these cases.
>> As regards old-style function check, or more broadly: localizing
>> variables, (http://reviews.llvm.org/D12473), it turned out to be more
>> difficult than I thought at first, and still have not made much
>> progress.
> Totally agree. If I could think of an easy way to implement it, I
> would have tried it by now :).
I'm working on it now and I think I see how to approach this. I decided
on writing something like a context-sensitive RecursiveASTVisitor, where
I can keep track of variable declarations and their uses in different
scopes. At the end, I just go over the collected data, and propose
replacements as necessary. Sound complicated but it should do the job.
>> However, in the meantime, working on other pieces of code, I
>> have become more familiar with Clang codebase, so I think it will be
>> easier for me now. This is what I'll focus on from now on.
> The implicit-conversion-to-bool check might be a good stepping stone
> in working with the clang-tidy infrastructure. I would like to see
> this check. Although it's easier for you to code, I'll be honest and
> say that I'd get more value out of the localizing variables check. If
> that one could be highly reliable, I'd even have an automated process
> that applied this on nightly builds every time the code changed.
Thanks, it's nice to hear that my work is being appreciated. I think I
will be able to make that check reliable enough for production use. Once
I finish it, I'll test it myself by running it on Colobot codebase
(100k+ LOC). This should prove to be a suitable field test for it.
Best regards,
Piotr Dziwinski
More information about the cfe-dev
mailing list