This adds a checker which suggests replacing string.find(...) == npos with absl::StrContains.
asserts are not used.
Please use static instead of anonymous namespace for functions.
This belongs to isLanguageVersionSupported().
STL containers are not used in header.
storeOptions() is missing.
Please separate with empty line.
Please synchronize with first statement in documentation.
Unrelated and incorrect changes.
Eugene, thank you for the comments, I'll address them soon. For the moment I'm trying to figure out what's up with the list.rst changes.
Agreed, these were generated by "clang-tidy/add_new_check.py abseil string-find-str-contains", still trying to figure out why.
Did you invoke the python script from the clang-tidy folder or the clang-tools-extra folder. The script is sensitive to the working directory it was executed from, it must be executed from the clang-tidy folder otherwise it fails when trying to detect auto fixes.
Don't need the C++ specifier in a cpp file.
//===--- StringFindStrContainsCheck.cpp - clang-tidy ----------------------===//
This is dangerous, it will match on std::string::npos == std::string::npos and (more importantly) strA.find(...) == strB.find(...). See D80054.
Same as above.
Thanks, all for the comments. I believe I've addressed all comments. Note that TransformerClangTidyCheck interacts awkwardly with StoreOptions; I have a FIXME to clean that up.
Just to be safe, I added a test case that confirms that it doesn't match on those constructs.
Possibly. I re-ran it on a clean cloned repo from the clang-tidy folder and it still created some unrelated list.rst changes (though fewer than before). So for now I just added the one line
I don't know if you have rebased recently, but TransformerClangTidyCheck now has a storeOptions method that needs calling from derived classes that override storeOptions. For now can you add a call to that in here TransformerClangTidyCheck::storeOptions(Opts); I Agree that we need to rework how options are handled but for now, make it work correctly.
Looks good, just some nits!
nit: just use assignment? Options.get() returns a string, so = seems a clearer way to initialize.
Would hasOperands replace these two separate calls to hasEitherOperand? Same below lines 79-80 (I think it's a new matcher, fwiw).
nit: use double back ticks (like below)
Same for absl::StrContains.
I'm not sure what's standard practice, but consider whether its worth adding another test file that tests the check options. It wouldn't have to be comprehensive like this one, just some basic tests that the options are being honored.
Just added, I added it to remove calls of multiple hasEitherOperand calls for the reason of preventing the matchers matching the same operand. I just got a little lost in my previous comment
nit: as abseil requires c++11, should this check also require c++11 support
Thanks, all, for the additional comments. I addressed them all except for the suggestion to add an options-specific test. I'm not against it, but (as I mention in the comment) I'm also unsure how to meaningfully test the include-inserting-related options.
Switched to hasOperands. I agree that expresses the intent better than two independent calls of hasEitherOperand.
Note that it was working fine before--the test cases confirmed that it wasn't matching string::npos == string::npos or s.find(a) == s.find(a). I'm guessing that's because the matchers inside hasEitherOperand have bindings, and if the matcher matched but one of the bindings was missing, the rewriterule suppressed itself? Is this a plausible theory?
(The question moot since hasOperands is better overall, but I'd like to understand why it was working before.)
Done, though I note that none of the other checkers in the abseil directory are checking for CplusCplus11. (That's not an argument against doing it, just a question of whether or not they should also get this change at some point.)
I'm open to it, but note that two of the three options (IncludeStyle, inherited from TransformerClangTidy) and AbseilStringsMatchHeader, only manifest in the header-inclusion.
So if I had a separate test it would be easy to confirm that StringLikeClasses was being honored. But I'm not sure how I'd confirm that IncludeStyle or AbseilStringsMatchHeader are being honored. Suggestions?
LGTM, but leaving for one of the other reviewers to give you the official "Accept Revision".
I was wondering the same when I noticed this. I think its something like this: one of the arguments falls into bucket 1, one of the arguments falls into bucket 2. Since a single argument cannot simultaneously fall into two buckets (the predicates are mutually exlusive), it must be the case that the arguments are different.
We see this broke the build for shared-lib config http://lab.llvm.org:8011/builders/llvm-avr-linux/builds/1879
Looking now (and I look forward to determining what I should have done to avoid this).