Stencils maybeDeref and maybeAddressOf are designed to handle nodes that may
be pointers. Currently, they only handle native pointers. This patch extends the
support to recognize smart pointers and handle them as well.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/unittests/Tooling/StencilTest.cpp | ||
---|---|---|
273 | You're only testing the "QuacksLike" case. I suspect you should have tests that validate the "KnownSmartPointers". Admittedly, it's a bit redundant since the known smart pointers also QuackLike pointers. Which, I guess, raises the question of why you have the hard-coded list of KnownSmartPointers if they are covered by the QuacksLike behavior and thus can't be meaningfully tested independently. What do you think? |
Thanks for the review!
clang/unittests/Tooling/StencilTest.cpp | ||
---|---|---|
273 | You're right -- there isn't really a meaningful test specific to the known cases. I added a comment explaining that hard-coding them is an optimization. WDYT? |
Ah, if it's just an optimization that makes sense. I still think it's worth having a test case to confirm that one of the specially-handled cases works.
Sure. I added one for unique pointer. but, just one -- i didn't add one per case. My logic is that since it's not part of the contract/API, we're really just using the (single) test to test the internal function isSmartPointerType, so one test is enough. That said, if you disagree, I'm fine with adding more tests. Its easy.
You're only testing the "QuacksLike" case. I suspect you should have tests that validate the "KnownSmartPointers".
Admittedly, it's a bit redundant since the known smart pointers also QuackLike pointers. Which, I guess, raises the question of why you have the hard-coded list of KnownSmartPointers if they are covered by the QuacksLike behavior and thus can't be meaningfully tested independently.
What do you think?