================
@@ -131,6 +131,20 @@ class OriginNode {
return nullptr;
}
+ /// To reach the record, peels the base's outer origin when the
+ /// base is a glvalue (`IsGLValue`) and one more level for an arrow access
+ /// (`IsArrow`), then looks up `FD`. Returns null if `FD` is not reachable.
+ OriginNode *resolveMemberField(const FieldDecl *FD, bool IsGLValue,
----------------
aeft wrote:
> I think in that case the responsibilities here might not be correct. The
> caller should know exactly if this is the arrow or the dot accessor, so
> maybe we should have either a bool argument to tell which one or two separate
> methods and that would enable the caller to be always precise. What do you
> think?
I get your point. We can pass two bool values to explicitly peel the origins:
one `IsGLValue` peels the outermost origin, one `IsArrow` peels the pointer
indirection. The reason it's two and not just the accessor: the accessor only
fixes the indirection jump, while the outermost jump depends on the base's
value category, e.g. `p->v` is 2 hops but `getP()->v` is 1 hop with the same
arrow. This way we handle both cases in one method and the caller can be
precise about what to peel and locate the field.
> I am not sure I follow the second point. Is this about differentiating
> between p.s and *p.s?
Here I mean differentiating two cases:
1. `p->v` pointer indirection (this adds a pointee edge, FD=nullptr)
2. lvalue storage wrap (this also adds a pointee edge for now, FD=nullptr):
These can be two EdgeKind: `Pointee` and `StorageWrap`. But actually we may
have a third one: `ReferenceWrap` (now it belongs to pointee edge, e.g., `rs.v`
where `rs` is a reference). As an alternative to the two-bool approach above:
if we attach EdgeKind to the edges, `StorageWrap`/`ReferenceWrap` become
self-identifying, so we always peel those first and use `IsArrow` only for the
pointer indirection, no `IsGLValue` needed. (We may ignore this for now if the
first method looks reasonable to you)
cc @Xazax-hun
https://github.com/llvm/llvm-project/pull/195603
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
