[clang][dataflow] Expose simple access to child StorageLocation presence.

[bazuzi]

getChild does not offer this knowledge, and a map lookup is significantly cheaper than iteration over children().

[llvmbot]

@llvm/pr-subscribers-clang-analysis

@llvm/pr-subscribers-clang

Author: Samira Bakon (bazuzi)

Changes

getChild does not offer this knowledge, and a map lookup is significantly cheaper than iteration over children().

---

Full diff: https://github.com/llvm/llvm-project/pull/145520.diff

1 Files Affected:

• (modified) clang/include/clang/Analysis/FlowSensitive/StorageLocation.h (+2)

diff --git a/clang/include/clang/Analysis/FlowSensitive/StorageLocation.h b/clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
index 8fcc6a44027a0..8b263b16d5b1e 100644
--- a/clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
+++ b/clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
@@ -168,6 +168,8 @@ class RecordStorageLocation final : public StorageLocation {
     return {Children.begin(), Children.end()};
   }
 
+  bool hasChild(const ValueDecl &D) const { return Children.contains(&D); }
+
 private:
   FieldToLoc Children;
   SyntheticFieldMap SyntheticFields;

[martinboehme]

Can you explain what this is intended to be used for? I'd like to make sure we don't have an XY problem here.

Whether a RecordStorageLocation has a given child or not should always be very predictable, as we enforce the constraint that a RecordStorageLocation should always have exactly the fields returned by getModeledFields(). There shouldn't, therefore, ever really be a need to check whether a RecordStorageLocation has a given child -- and I'm worried that maybe you've run into a bug that you're using getChild() to work around, when in fact it would be better to fix the underlying bug.

[bazuzi]

No underlying bug, but I was able to simplify my approach out-of-tree and avoid exposing this function that doesn't capture the intended semantics.

I'll revert this.