================
@@ -0,0 +1,39 @@
+//===- AssignmentQuery.cpp - C++ Lifetime Safety Checker --------*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// This file implements the LifetimeChecker, which detects use-after-free
+// errors by checking if live origins hold loans that have expired.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef LLVM_CLANG_ANALYSIS_ANALYSES_ASSIGNMENTQUERY_H
+#define LLVM_CLANG_ANALYSIS_ANALYSES_ASSIGNMENTQUERY_H
+
+#include "clang/Analysis/Analyses/LifetimeSafety/Facts.h"
+#include "clang/Analysis/Analyses/LifetimeSafety/LoanPropagation.h"
+
+namespace clang::lifetimes::internal {
+using AssignmentPair = std::pair<DestOriginEntity, SrcOriginEntity>;
----------------
suoyuan666 wrote:
Do you mean maintaining LHS and RHS as a single flat list because the LHS of
one expression often becomes the RHS of the next?
I considered that, but it seems insufficient for retrieving the correct
`LHS->ExprLoc` mapping when generating `Sema` diagnostics later.
Take the following case as an example:
```c
int *s;
{
int tgt = 2;
int *a = &tgt;
int *e = a;
s = e;
}
(void)s;
```
During the reverse search, we can identify the `DeclRefExpr` for `e` in `s = e`.
However, we cannot ignore the `ValueDecl` corresponding to `int *a`. If we
don't track them as explicit pairs, it becomes difficult to precisely pinpoint
and report the `ExprLoc` of `e` in the subsequent diagnostic notes.
https://github.com/llvm/llvm-project/pull/196075
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
