================
@@ -31,7 +31,7 @@ inline llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
LoanID ID) {
struct AccessPath {
const clang::ValueDecl *D;
- AccessPath(const clang::ValueDecl *D) : D(D) {}
+ AccessPath(const clang::ValueDecl *D = nullptr) : D(D) {}
----------------
usx95 wrote:
I also have another Loan kind in mind for the future: Opaque loans for which
access path is not known.
So I feel we are trying to different "kinds" of loan and they are better
represented as different classes very much like what we are doing for Facts.
Rough sketch of my suggestion:
- An abstract class for base type.
```
class Loan {
public:
enum class Kind {
Borrow,
Placeholder
// later Opaque
};
// getters...
// template<typename T>
// const T* getAs() { .. }
virtual void dump(...)
private:
LoanID ID;
Kind K;
}
```
- A concerte loan type to denote borrows. These would have AccessPath,
IssueExpr, can expire by destruction of the Path.
```
class BorrowLoan : Loan {
AccessPath Path;
const Expr *IssueExpr;
...
static bool classof(const Loan *L) {
return L->getKind() == Kind::Borrow;
}
};
```
- A concrete type for placeholder to denote placeholder loans held by
parameters on function entry. These do not have Issue Expr or AccessPath.
```
class ParameterLoan : Loan {
const ParmVarDecl *PVD;
static bool classof(const Loan *L) {
return L->getKind() == Kind::Placeholder;
}
};
```
I think this would best separate out the semantics.
The loan manager would need to have an allocator similar to `FactAllocator` to
store the loans.
https://github.com/llvm/llvm-project/pull/169767
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
