[PATCH] D59103: [clang-tidy] New checker bugprone-incomplete-comparison-operator

Kalle Huttunen via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Mar 28 08:09:12 PDT 2019


kallehuttunen added a comment.

In D59103#1423307 <https://reviews.llvm.org/D59103#1423307>, @aaron.ballman wrote:

> In D59103#1422775 <https://reviews.llvm.org/D59103#1422775>, @kallehuttunen wrote:
>
> > Another idea that came to my mind would be to enable this check only for annotated types. So warning for missing field access would be only given for types that have for example `[[clang::annotate("value type")]]` annotation. Possibly other kinds of checks could be also developed for types that have the given annotation.
>
>
> I don't think `annotate` would be a good choice because the primary purpose of that one is to pass that attribute information down to the backend and using it for this purpose feels a bit hackish. However, we could always add a new attribute if needed, but I'm not convinced an attribute is the right approach either (but then again, I'm also lacking information I'm sure).
>
> What other kinds of checks do you have in mind and what are the semantics of the attribute you're thinking of?


I was thinking about something along the lines of having an attribute to mark types to be a "value type" as defined in Herb's metaclasses proposal (chapter 3.5 in https://herbsutter.files.wordpress.com/2017/07/p0707r1.pdf). There could be then checks for having default ctor, no virtual functions etc in addition to this check for those types. But then again now that I think about it, a "string" class is an counterexample for this: it can be a value (regular) type, but when comparing instances you don't want to access the "capacity" member.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D59103





More information about the cfe-commits mailing list