njames93 added inline comments.
================
Comment at:
clang-tools-extra/test/clang-tidy/checkers/performance-prefer-pre-increment-disable-cpp-opcalls.cpp:44
+};
+
+void foo() {
----------------
njames93 wrote:
> JonasToth wrote:
> > Test-cases that I would like to see:
> >
> > - only the post-fix operator is overloaded for the class --> best-case this
> > is detected and a fix is not provided
> > - iterator-inheritance: the base-class provides the operator-overloads -->
> > does matching work? There might be an implicit cast for example
> > - the iterator-type is type-dependent --> maybe fixing should not be done
> > or even the warning should not be emitted, because there might be only a
> > post-fix available in some instantiations (see point 1). I do mean
> > something like this `template <typename T> void f() { T::iterator it; it++;
> > }`
> There are test cases for only post fix operator overloading. basically it
> doesn't warn or provided a fix it as that isn't valid. I feel like there
> could be a seperate check that detects classes that overload operator++(int)
> but not operator++() but thats not what this check is for.
> I'll take a look at the other cases tomorrow
Currently the base class provided operator overloads match normally.
For template dependent code it gets a little hazy. Basically if the type isn't
known the operator will always appear as a `UnaryOperator`, maybe its safest to
proceed by disabling fixes if the type isn't known, and maybe add an option to
override that behaviour, WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D72553/new/
https://reviews.llvm.org/D72553
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits