Add C++20-esque contains method for sets.
Details
- Reviewers
rjmccall dblaikie fhahn - Commits
- rG645bb8e2086c: [llvm] Add contains(KeyType) -> bool methods to StringSet
rG39000aad81ff: [llvm] Add contains(KeyType) -> bool methods to SparseSet
rGdd4426b9a66e: [llvm] Add contains(KeyType) -> bool methods to SmallSet
rGa0385bd7acd6: [llvm] Add contains(KeyType) -> bool methods to SmallPtrSet
rG1d8eef41f5af: [llvm] Add contains(KeyType) -> bool methods to SetVector
rGd3ce3dc4867b: [llvm] Add contains(KeyType) -> bool methods to DenseSet
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Prior art:
- C++20: https://en.cppreference.com/w/cpp/container/set/contains
- Rust: https://doc.rust-lang.org/std/collections/struct.HashSet.html#method.contains
- Swift: https://developer.apple.com/documentation/swift/set
Let's stop writing set.find(key) != set.end() over and over. It's 2020 already.
I don't understand the clang-tidy/clang-format complaints. I've formatted the code based on how the surrounding code is formatted.
Nice, IMO this makes a lot of sense and will help to get rid of a lot of more verbose find(x) != end() expressions.
For most ADT classes, there are unit tests in llvm/unittests/ADT/. It would be good to add additional tests there. Also ,it would be good to add a proper doc-comment in all classes, as well as including the prior art comment in the description and replacing [llvm] with [ADT].
IIRC, these come from arcanist. They should behave themselves if you have this utility on your PATH: https://github.com/llvm/llvm-project/blob/master/clang/tools/clang-format/git-clang-format#L15
+1 needs unit tests, might make sense to commit each one separately with its test (& maybe some cleanup commits afterwards, to help migrate the codebase/encourage future use in the new direction)
I've added some unit tests. Are these adequate/do you have any other suggestions on what I should test?
might make sense to commit each one separately with its test
I'm not sure what benefit this would bring. Could you elaborate? I would've understood if the combined change were large by itself, but that's not the case here.
maybe some cleanup commits afterwards, to help migrate the codebase/encourage future use in the new direction
I could do this in a separate revision, if desired.
Looks good to me, thanks!
might make sense to commit each one separately with its test
I'm not sure what benefit this would bring. Could you elaborate? I would've understood if the combined change were large by itself, but that's not the case here.
The usual sentiment that independent changes should be submitted independently - means if something goes wrong they can be reverted in isolation without reverting unrelated changes (eg: if there was a bug in one of these implementations - it got submitted, you committed a few more changes on top of it to start using these APIs more broadly - then someone identified/reported the bug, we rolled back the patch... now we'd have to rollback all the cleanups too - rather than only those cleanups that used the particular API that was buggy & leaving the rest intact)
maybe some cleanup commits afterwards, to help migrate the codebase/encourage future use in the new direction
I could do this in a separate revision, if desired.
I think that'd be nice, thanks!
@dblaikie could you land the patch for me? I do not have bot permissions/commit privileges.
Thanks! It seems a bit weird that this revision now only shows the one commit under Revision contents even though the 'Commits' above shows the six commits. 🤷
Yeah, I doubt there's much to be done about that. Imagine phab only has the concept of a review being closed by one commit.
Oh, and sorry I forgot to update the "author" field to appropriately credit you when I committed these :/ they all have the Phab link in them at least, which leads here for appropriate credit.
Oh, and sorry I forgot to update the "author" field to appropriately credit you when I committed these
Nbd, thanks for the review and merging. :)
clang-tidy: warning: invalid case style for parameter 'key' [readability-identifier-naming]
not useful