================
@@ -521,19 +529,96 @@ class LifetimeChecker {
}
}
+ std::optional<LifetimeBoundParamInfo>
+ getLifetimeBoundParamInfo(const FunctionDecl *FD, unsigned I) {
+ const ParmVarDecl *PVD = nullptr;
+ if (const auto *Method = dyn_cast<CXXMethodDecl>(FD);
+ Method && Method->isInstance() && !isa<CXXConstructorDecl>(FD)) {
+ if (I == 0)
+ return implicitObjectParamIsLifetimeBound(Method)
+ ? std::optional<LifetimeBoundParamInfo>(
+ LifetimeBoundParamInfo(Method))
+ : std::nullopt;
+ if ((I - 1) < Method->getNumParams())
+ PVD = Method->getParamDecl(I - 1);
+ } else if (I < FD->getNumParams()) {
+ PVD = FD->getParamDecl(I);
+ }
+
+ if (PVD && PVD->hasAttr<clang::LifetimeBoundAttr>())
+ return LifetimeBoundParamInfo(PVD);
+ return std::nullopt;
+ }
+
+ std::optional<LifetimeBoundParamInfo>
+ getLifetimeBoundParamInfo(const Expr *Call, OriginID SrcOriginID) {
----------------
iitianpushkar wrote:
I agree with your concern. The re-derive approach duplicates some of the
call/argument-to-parameter mapping logic from FactsGenerator.
One possible approach I can think of is to factor the shared “argument index ->
lifetimebound parameter/implicit object” mapping into a helper so both
FactsGenerator and Checker use the same logic. But, the call-expr-to-arg-list
part may need a bit more care because FactsGenerator has special handling for
some call forms.
But, since this is more of a design tradeoff, I will wait for input from
someone more experienced as you also said.
@Xazax-hun If you get time, please look into this.
https://github.com/llvm/llvm-project/pull/206337
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits