This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Checker for inefficient use of algorithms on associative containers
ClosedPublic

Authored by xazax.hun on Jan 29 2015, 3:48 AM.

Details

Summary

Associative containers implements some of the algorithms as methods which
should be preferred to the algorithms in the algorithm header. The methods
can take advantage of the order of the elements.

Diff Detail

Event Timeline

xazax.hun updated this revision to Diff 18949.Jan 29 2015, 3:48 AM
xazax.hun retitled this revision from to [clang-tidy] Checker for inefficient use of algorithms on associative containers.
xazax.hun updated this object.
xazax.hun edited the test plan for this revision. (Show Details)
xazax.hun added a reviewer: alexfh.
xazax.hun added a subscriber: Unknown Object (MLST).
alexfh added inline comments.Feb 3 2015, 2:38 AM
clang-tidy/misc/InefficientAlgorithmCheck.cpp
25

What about unordered_(multi)?(set|map)?

38

Maybe something along the lines of on(equalsBoundNode("IneffContObj"))?

69

I'm not a native speaker, but the message seems a bit unclear. How about "different comparers used in the algorithm and the container"?

Also, please remove the trailing period.

83

A Twine can be used here instead.

97

Please remove the trailing period.

xazax.hun updated this revision to Diff 19224.Feb 3 2015, 7:46 AM

Thanks for the review.

  • I have added support for unordered containers. There is no comparator check for the unordered containers and there is no lower or upper bound member functions. Code to deal with these cases was added.
  • I made the matcher more strict with equalBoundNodes as you suggested.
  • The warning messages was modified as you requested. Unfortunately I do not have a native speaker coworker to check these messages.
  • Replaced the string concatenations with twine operations.
alexfh edited edge metadata.Feb 4 2015, 11:46 AM

One nit, otherwise looks good. Please address the issue and I can commit the patch for you.

BTW, I think that it makes sense for you to apply for a commit access (http://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access).

Also, could you run the check on LLVM/Clang to see whether it finds something?

clang-tidy/misc/InefficientAlgorithmCheck.cpp
43

Do you need to check this in addition to the equalsBoundNode above?

xazax.hun updated this revision to Diff 19467.Feb 6 2015, 2:58 AM
xazax.hun edited edge metadata.

Hi Alex,

Thank you for the review.I have removed the redundant checks you mentioned. I did run it on the LLVM code base and did not found any match. I think there is two reason: the code has exceptional quality and LLVM has it's own set of data structures. I will apply for commit access :)

alexfh accepted this revision.Feb 6 2015, 5:19 AM
alexfh edited edge metadata.

Looks good!

Thank you for the contribution!

This revision is now accepted and ready to land.Feb 6 2015, 5:19 AM
xazax.hun closed this revision.Feb 7 2015, 11:56 AM
alexfh added inline comments.Feb 12 2015, 6:57 AM
clang-tidy/misc/InefficientAlgorithmCheck.cpp
22

This turns out to match std::count_if/std::find_if as well. Could you surround the regex with ^$ and add a test? Same applies to the ContainerMatcher below.

Thank you for pointing this issue out. It should be fixed in r228945.

I found two more issues with this check:

  1. the fixes for map-like containers are wrong. The .begin() and .end() allow to iterate over values of the map, and .find() accepts a key. I don't know if there is a good fix for all cases where std::find-like algorithms are used on a map. Maybe just leave a warning without a fix?
  2. the check can produce incompilable fixes if an algorithm receives a value of a different type than the type of the container's elements. See http://pastebin.com/5pkMLrZb for an example.

Would be nice if you could fix the issues.

Thanks!

Thank you for the feedback. I think I should have seen the first problem in advance. I find the second one more subtle. Both should be fixed in r229552. I am not absolutely happy with the solution: checking for type equality modulo references. It would be better to check if appropriate type conversions exists, but I did not find a nice way to do it. What is your opinion?

Thank you for the feedback. I think I should have seen the first problem in advance. I find the second one more subtle. Both should be fixed in r229552. I am not absolutely happy with the solution: checking for type equality modulo references. It would be better to check if appropriate type conversions exists, but I did not find a nice way to do it. What is your opinion?

I don't know if a better solution exists. The fix looks fine. Thanks!