Prevent an assertion failure in the cstring checker when library
functions like memcpy are defined with non-default address spaces.
Adds a test for this case.
These are implicit vardecls which its type was never written in source
code. Don't create a TypeLoc and give it a fake source location.
The fake as-written type also didn't match the actual type, which after
fixing this gives some unrelated test churn on a CFG dump, since
statement printing prefers type source info if thats available.
Fixes https://github.com/llvm/llvm-project/issues/153649
This is a regression introduced in
https://github.com/llvm/llvm-project/pull/147835
This regression was never released, so no release notes are added.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
This patch improves MallocChecker to detect use-after-free bugs when
a freed structure's field is passed by address (e.g., `&ptr->field`).
Previously, MallocChecker would miss such cases, as it only checked the
top-level symbol of argument values.
This patch analyzes the base region of arguments and extracts the
symbolic region (if any), allowing UAF detection even for field address
expressions.
Fixes#152446
We sometimes don't know if the operand of [[assume]] is true/false, and
that's okay. We can just ignore the attribute in that case.
If we wanted something more fancy, we could bring the assumption to the
constraints, but dropping them should be just as fine for now.
Fixes#151854
This adds alpha.core.StoreToImmutable, a new alpha checker that detects
writes
to immutable memory regions, implementing part of SEI CERT Rule ENV30-C.
The
original proposal only handled global const variables, but this
implementation
extends it to also detect writes to:
- Local const variables
- String literals
- Const parameters and struct members
- Const arrays and pointers to const data
This checker is the continuation of the work started by zukatsinadze.
Discussion: https://reviews.llvm.org/D124244
This patch removes %T from clang lit tests. %T has been deprecated for
about seven years and is not reccomended as it is not unique to each
test, which can lead to races. This patch is intended to remove usage in
tree with the end goal of removing support for %T within lit.
The factory method `MemRegionManager::getElementRegion()` is the main
way of constructing `ElementRegion` objects, which are widespread in the
analysis and may represent array elements (as lvalues), pointer
arithmetic and type conversions.
This factory method used to strip all qualifiers from the type
associated with the element (after canonicalizing it), but the address
space qualifier can affect the size of a pointer type, so stripping it
caused an assertion failure (in `evalBinOpLL`):
clang: clang/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:785: void
assertEqualBitWidths(clang::ento::ProgramStateRef, clang::ento::Loc,
clang::ento::Loc): Assertion `RhsBitwidth == LhsBitwidth && "RhsLoc and
LhsLoc bitwidth must be same!"' failed.
---------
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
Fix false positive where warnings were asserted for placement new even
when no additional space is requested
The PlacementNewChecker incorrectly triggered warnings when the storage
provided matched or exceeded the allocated type size, causing false
positives. Now the warning triggers only when the provided storage is
strictly less than the required size.
Add test cases covering exact size, undersize, and oversize scenarios to
validate the fix.
Fixes#149240
This commit converts the class StackAddrEscapeChecker to the checker
family framework and slightly simplifies the implementation.
This commit is almost NFC, the only technically "functional" change is
that it removes the hidden modeling checker `core.StackAddrEscapeBase`
which was only relevant as an implementation detail of the old checker
registration procedure.
Changed the warning message:
- **From**: 'Attempt to free released memory'
**To**: 'Attempt to release already released memory'
- **From**: 'Attempt to free non-owned memory'
**To**: 'Attempt to release non-owned memory'
- **From**: 'Use of memory after it is freed'
**To**: 'Use of memory after it is released'
All connected tests and their expectations have been changed
accordingly.
Inspired by [this
PR](https://github.com/llvm/llvm-project/pull/147542#discussion_r2195197922)
This commit converts the class DereferenceChecker to the checker family
framework and simplifies some parts of the implementation.
This commit is almost NFC, the only technically "functional" change is
that it removes the hidden modeling checker `DereferenceModeling` which
was only relevant as an implementation detail of the old checker
registration procedure.
MallocChecker.cpp has a complex heuristic that supresses reports where
the memory release happens during the release of a reference-counted
object (to suppress a significant amount of false positives).
Previously this logic asserted that there is at most one release point
corresponding to a symbol, but it turns out that there is a rare corner
case where the symbol can be released, forgotten and then released
again. This commit removes that assertion to avoid the crash. (As this
issue just affects a bug suppression heuristic, I didn't want to dig
deeper and modify the way the state of the symbol is changed.)
Fixes#149754
The checks for the 'z' and 't' format specifiers added in the original
PR #143653 had some issues and were overly strict, causing some build
failures and were consequently reverted at
4c85bf2fe8.
In the latest commit
27c58629ec,
I relaxed the checks for the 'z' and 't' format specifiers, so warnings
are now only issued when they are used with mismatched types.
The original intent of these checks was to diagnose code that assumes
the underlying type of `size_t` is `unsigned` or `unsigned long`, for
example:
```c
printf("%zu", 1ul); // Not portable, but not an error when size_t is unsigned long
```
However, it produced a significant number of false positives. This was
partly because Clang does not treat the `typedef` `size_t` and
`__size_t` as having a common "sugar" type, and partly because a large
amount of existing code either assumes `unsigned` (or `unsigned long`)
is `size_t`, or they define the equivalent of size_t in their own way
(such as
sanitizer_internal_defs.h).2e67dcfdcd/compiler-rt/lib/sanitizer_common/sanitizer_internal_defs.h (L203)
This patch addresses the lack of support for parenthesized
initialization in the Clang Static Analyzer's `ExprEngine`. Previously,
initializations such as `V v(1, 2);` were not modeled properly, which
could lead to false negatives in analyses like `DivideZero`.
```cpp
struct A {
int x;
A(int v) : x(v) {}
};
int t() {
A a(42);
return 1 / (a.x - 42); // expected-warning {{Division by zero}}
}
```
Fixes#148875
Including the results of `sizeof`, `sizeof...`, `__datasizeof`,
`__alignof`, `_Alignof`, `alignof`, `_Countof`, `size_t` literals, and
signed `size_t` literals, the results of pointer-pointer subtraction and
checks for standard library functions (and their calls).
The goal is to enable clang and downstream tools such as clangd and
clang-tidy to provide more portable hints and diagnostics.
The previous discussion can be found at #136542.
This PR implements this feature by introducing a new subtype of `Type`
called `PredefinedSugarType`, which was considered appropriate in
discussions. I tried to keep `PredefinedSugarType` simple enough yet not
limited to `size_t` and `ptrdiff_t` so that it can be used for other
purposes. `PredefinedSugarType` wraps a canonical `Type` and provides a
name, conceptually similar to a compiler internal `TypedefType` but
without depending on a `TypedefDecl` or a source file.
Additionally, checks for the `z` and `t` format specifiers in format
strings for `scanf` and `printf` were added. It will precisely match
expressions using `typedef`s or built-in expressions.
The affected tests indicates that it works very well.
Several code require that `SizeType` is canonical, so I kept `SizeType`
to its canonical form.
The failed tests in CI are allowed to fail. See the
[comment](https://github.com/llvm/llvm-project/pull/135386#issuecomment-3049426611)
in another PR #135386.
Variables `stdin`, `stdout`, `stderr` are now added to internal memory space
instead of system memory space. The system memory space is invalidated
at calls to system-defined functions which is not the correct behavior for
the standard stream variables.
This patch introduces a new Python-based benchmarking tool for Clang's Lifetime Safety analysis. This script automates the process of generating targeted C++ test cases, measuring the performance of the analysis, and determining its empirical computational complexity.
The tool helps track and validate the performance of the dataflow analysis, ensuring that future optimizations have a measurable impact and that the analysis scales efficiently.
Components:
* **Generate**: Creates pathological C++ test cases with specific patterns (pointer cycles and CFG merges) designed to stress-test the analysis.
* **Compile & Trace**: Compiles the generated code using `-ftime-trace`.
* **Analyze & Report**: Performs a curve-fit on the timing data to determine the empirical complexity ( **O(n<sup>k</sup>)**) and outputs a markdown report.
---
**Usage**:
<details>
<summary>ninja benchmark_lifetime_safety_analysis</summary>
[12/13] Running Lifetime Analysis performance benchmarks...
Benchmark files will be saved in: <BUILD_DIR_REDACTED>/tools/clang/test/Analysis/LifetimeSafety/benchmark_results
Running performance benchmarks...
--- Running Test: Cycle with N=10 ---
Total: 10.11 ms | Analysis: 2.70 ms
--- Running Test: Cycle with N=25 ---
Total: 61.51 ms | Analysis: 53.05 ms
--- Running Test: Cycle with N=50 ---
Total: 688.56 ms | Analysis: 677.32 ms
--- Running Test: Cycle with N=75 ---
Total: 3.09 s | Analysis: 3.07 s
--- Running Test: Cycle with N=100 ---
Total: 9.31 s | Analysis: 9.30 s
--- Running Test: Cycle with N=150 ---
Total: 44.92 s | Analysis: 44.91 s
--- Running Test: Merge with N=10 ---
Total: 8.54 ms | Analysis: 0.00 ms
--- Running Test: Merge with N=50 ---
Total: 38.79 ms | Analysis: 27.13 ms
--- Running Test: Merge with N=100 ---
Total: 219.45 ms | Analysis: 205.20 ms
--- Running Test: Merge with N=200 ---
Total: 1.67 s | Analysis: 1.65 s
--- Running Test: Merge with N=400 ---
Total: 12.57 s | Analysis: 12.55 s
--- Running Test: Merge with N=800 ---
Total: 100.48 s | Analysis: 100.43 s
Generating Markdown Report...
</details>
<details>
<summary>Sample Report: </summary>
# Lifetime Analysis Performance Report
> Generated on: 2025-07-08 14:18:52
---
## Test Case: Pointer Cycle in Loop
| N | Analysis Time | Total Clang Time |
|:----|--------------:|-----------------:|
| 10 | 2.70 ms | 10.11 ms |
| 25 | 53.05 ms | 61.51 ms |
| 50 | 677.32 ms | 688.56 ms |
| 75 | 3.07 s | 3.09 s |
| 100 | 9.30 s | 9.31 s |
| 150 | 44.91 s | 44.92 s |
**Complexity Analysis:**
- The performance for this case scales approx. as **O(n<sup>3.88</sup>)**.
- **95% Confidence interval for exponent:** `[3.86, 3.90]`.
---
## Test Case: CFG Merges
| N | Analysis Time | Total Clang Time |
|:----|--------------:|-----------------:|
| 10 | 0.00 ms | 8.54 ms |
| 50 | 27.13 ms | 38.79 ms |
| 100 | 205.20 ms | 219.45 ms |
| 200 | 1.65 s | 1.67 s |
| 400 | 12.55 s | 12.57 s |
| 800 | 100.43 s | 100.48 s |
**Complexity Analysis:**
- The performance for this case scales approx. as **O(n<sup>3.00</sup>)**.
- **95% Confidence interval for exponent:** `[2.99, 3.01]`.
---
</details>
This commit removes the DoubleDelete bug type from `MallocChecker.cpp`
because it's completely redundant with the `DoubleFree` bug (which is
already used for all allocator families, including new/delete).
This simplifies the code of the checker and prevents the potential
confusion caused by two semantically equivalent and very similar, but
not identical bug report messages.
This commit removes the test file test-member-invalidation.cpp which was
recently introduced in 39bc0529b018a89b4b6a21aaabe240cd3a65c44d by
splitting off a test case from new.cpp.
In that commit I preserved that test in a slightly modified setting to
demonstrate that it wasn't broken by the change; but in this separate
commit I'm removing it because I don't think that it "deserves a place"
among our tests.
The primary issue is that this test examines the values of data members
of a deleted object -- which is irrelevant, because code that relies on
the value of these members should be reported as a use-after-free bug.
(In fact, cplusplus.NewDelete reports it as a use-after-free bug, and
the checker family `MallocChecker` sinks the execution path even if that
particular frontend is not enabled.)
Moreover, a comment claimed that this tests "Invalidate Region even in
case of default destructor" while in fact it tested a situaton where the
destructor is a plain declared-but-not-defined method. The invalidation
of `this` is done by the conservative evaluation, and we don't need this
overcomplicated test to validate that very basic behavior.
This commit converts MallocChecker to the new checker family framework
that was introduced in the recent commit
6833076a5d9f5719539a24e900037da5a3979289 -- and gets rid of some awkward
unintended interactions between the checker frontends.
Bounded string functions takes smallest of two values as it's copy size
(`amountCopied` variable in `evalStrcpyCommon`), and it's used to
decided whether this operation will cause out-of-bound access and
invalidate it's super region if it does.
for `strlcat`: `amountCopied = min (size - dstLen - 1 , srcLen)`
for others: `amountCopied = min (srcLen, size)`
Currently when one of two values is unknown or `SValBuilder` can't
decide which one is smaller, `amountCopied` will remain `UnknownVal`,
which will invalidate copy destination's super region unconditionally.
This patch add check to see if one of these two values is definitely
in-bound, if so `amountCopied` has to be in-bound too, because it‘s less
than or equal to them, we can avoid the invalidation of super region and
some related false positives in this situation.
Note: This patch uses `size` as an approximation of `size - dstLen - 1`
in `strlcat` case because currently analyzer doesn't handle complex
expressions like this very well.
Closes#143807.
PR145731 corrected the analyzer test runner to consider use of z3 when
used by testcases, which exposed problems in test cases PR37855.c and
crashes in z3-crosscheck.c This change fixes those crashes and
re-enables the test cases that were "XFAIL"'d out.
Co-authored-by: einvbri <vince.a.bridgers@ericsson.com>
For the following code in C mode: https://godbolt.org/z/3eo1MeGhe
(There is no warning in C++ mode though).
```c++
struct B {
int i : 2;
int : 30; // unnamed bit-field
};
extern void consume_B(struct B);
void bitfield_B_init(void) {
struct B b1;
b1.i = 1; // b1 is initialized
consume_B(b1); // FP: Passed-by-value struct argument contains uninitialized data (e.g., field: '') [core.CallAndMessage]
}
```
A large majority of the LIT tests of the clang static analyzer use RUN
lines with the placeholder `%clang_analyze_cc1` which expands to
`%clang_cc1 -analyze -setup-static-analyzer` where the only effect of
`-setup-static-analyzer` is that it ensures that the macro
`__clang_analyzer__` is defined. However, there were some tests that
used `%clang_cc1 -analyze` directly; this commit changes those to using
`%clang_analyze_cc1` for the sake of consistency.
Previously `%clang_analyze_cc1` did not work within the directory
`exploded-graph-rewriter` (because that directory has its own custom
`lit.local.cfg`) but this problem was eliminated by the recent commit
40cc4379cda6e0d6efe72c55d1968f9cf427a16a, so it was possible to resolve
and delete the FIXME comments asking for this change.
There are a few tests that use `%clang --analyze` or other command-line
flags (e.g. help flags), those are not affected by this change.
This cleanup was discussed in the discourse thread
https://discourse.llvm.org/t/taking-ownership-of-clang-test-analysis/84689/11
Build the Z3 mock module via CMake rather than compiling it directly in
tests. This ensures that the toolchain file is exported, and therefore
fixes testing for Gentoo multilib. Also, it ensures that the module is
compiled only once for the two tests using it.
While at it, remove the related Z3 include directory and host compiler
substitutions -- they are not used anymore, and the latter can't be
reliably used in tests.
The code is based on the existing bits for CTTestTidyModule.
See
https://github.com/llvm/llvm-project/pull/145731#issuecomment-3015197983
Fix running tests that require Z3 headers in standalone build. They were
wrongly relying on `Z3_INCLUDE_DIR` being passed through from LLVM,
which is not the case for a standalone build. Instead, perform
`find_package(Z3)` again to find Z3 development files and set
`Z3_INCLUDE_DIR`. While at it, handle the possibility that Z3
development package is no longer installed -- run the tests only if both
LLVM has been built against Z3, and the headers are still available.
https://github.com/llvm/llvm-project/pull/145731#issuecomment-3009487525
Signed-off-by: Michał Górny <mgorny@gentoo.org>
Before this commit the LIT test framework of the static analyzer had a
file called `analyzer_test.py` which implemented a tricky system for
selecting the constraint manager:
- (A) Test files without `REQUIRES: z3` were executed with the default
range-based constraint manager.
- (B) If clang was built with Z3 support _and_ `USE_Z3_SOLVER=1` was
passed to the test run, the test was executed with Z3 as the
constraint manager.
(There was support for executing the same RUN line twice if both
conditions were satisfied.)
Unfortunately, using Z3 as the constraint manager does not work in
practice (very slow and causes many crashes), so the (B) pathway became
unused (or was never truly used?) and became broken due to bit rot. (In
the CI bots the analyzer is built without Z3 support, so only the
pathway (A) is used.)
This commit removes `analyzer_test.py` (+ related logic in other build
files + the test `z3/enabled.c` which just tested that
`analyzer_test.py` is active), because it tries to implement a feature
that we don't need (only one constraint manager is functional) and its
code is so complicated and buggy that it isn't useful as a starting
point for future development.
The fact that this logic was broken implied that tests with `REQUIRES:
z3` were not executed during normal testing, so they were also affected
by bit rot. Unfortunately this also affected the tests of the
`z3-crosscheck` mode (aka Z3 refutation) which also depends on Z3 but
uses Z3 in a different way which is actually stable and functional.
In this commit I'm fixing most of the `REQUIRES: z3` tests that were
broken by straightforward issues. Two test files, `PR37855.c` and
`z3-crosscheck.c` were affected by more complex issues, so I marked them
as `XFAIL` for now. We're planning to fix them with follow-up commits in
the foreseeable future.
For additional background information see also the discourse thread
https://discourse.llvm.org/t/taking-ownership-of-clang-test-analysis/84689
For lambdas that are converted to C function pointers,
```
int (*ret_zero)() = []() { return 0; };
```
clang will generate conversion method like:
```
CXXConversionDecl implicit used constexpr operator int (*)() 'int (*() const noexcept)()' inline
-CompoundStmt
-ReturnStmt
-ImplicitCastExpr 'int (*)()' <FunctionToPointerDecay>
-DeclRefExpr 'int ()' lvalue CXXMethod 0x5ddb6fe35b18 '__invoke' 'int ()'
-CXXMethodDecl implicit used __invoke 'int ()' static inline
-CompoundStmt (empty)
```
Based on comment in Sema, `__invoke`'s function body is left empty
because it's will be filled in CodeGen, so in AST analysis phase we
should get lambda's `operator()` directly instead of calling `__invoke`
itself.
This patch corrects the state of the error node generated by the
core.DivideZero checker when it detects potential division by zero
involving a tainted denominator.
The checker split in
91ac5ed10a
started to introduce a conflicting assumption about the denominator into
the error node:
Node with the Bug Report "Division by a tainted value, possibly zero"
has an assumption "denominator != 0".
This has been done as a shortcut to continue analysis with the correct
assumption *after* the division - if we proceed, we can only assume the
denominator was not zero. However, this assumption is introduced
one-node too soon, leading to a self-contradictory error node.
In this patch, I make the error node with assumption of zero denominator
fatal, but allow analysis to continue on the second half of the state
split with the assumption of non-zero denominator.
---
CPP-6376
This commit converts NullabilityChecker to the new checker family
framework that was introduced in the recent commit
6833076a5d9f5719539a24e900037da5a3979289
This commit removes the dummy checker `nullability.NullabilityBase`
because it was hidden from the users and didn't have any useful role
except for helping the registration of the checker parts in the old
ad-hoc system (which is replaced by the new standardized framework).
Except for the removal of this dummy checker, no functional changes
intended.
Placement new does not allocate memory, so it should not be reported as
a memory leak. A recent MallocChecker refactor changed inlining of
placement-new calls with manual evaluation by MallocChecker.
339282d49f
This change avoids marking the value returned by placement new as
allocated and hence avoids the false leak reports.
Note that the there are two syntaxes to invoke placement new:
`new (p) int` and an explicit operator call `operator new(sizeof(int), p)`.
The first syntax was already properly handled by the engine.
This change corrects handling of the second syntax.
CPP-6375
Since _BitInt was added later, ASTContext did not comprehend getting a
type by bitwidth that's not a power of 2, and the SMT layer also did not
comprehend this. This led to unexpected crashes using Z3 refutation
during randomized testing. The assertion and redacted and summarized
crash stack is shown here.
clang:
../../clang/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h:103:
static llvm::SMTExprRef
clang::ento::SMTConv::fromBinOp(llvm::SMTSolverRef &,
const llvm::SMTExprRef &, const BinaryOperator::Opcode, const
llvm::SMTExprRef &, bool):
Assertion `*Solver->getSort(LHS) == *Solver->getSort(RHS) && "AST's must
have the same sort!"' failed.
...
<address>
clang::ento::SMTConv::fromBinOp(std::shared_ptr<llvm::SMTSolver>&,
llvm::SMTExpr const* const&, clang::BinaryOperatorKind, llvm::SMTExpr
const* const&,
bool) SMTConstraintManager.cpp
clang::ASTContext&, llvm::SMTExpr const* const&, clang::QualType,
clang::BinaryOperatorKind, llvm::SMTExpr const* const&, clang::QualType,
clang::QualType*) SMTConstraintManager.cpp
clang::ASTContext&, clang::ento::SymExpr const*, llvm::APSInt const&,
llvm::APSInt const&, bool) SMTConstraintManager.cpp
clang::ento::ExplodedNode const*, clang::ento::PathSensitiveBugReport&)
---------
Co-authored-by: Vince Bridgers <vince.a.bridgers@ericsson.com>
Allow @property of a raw pointer when NS_REQUIRES_PROPERTY_DEFINITIONS
is specified on the interface since such an interface does not
automatically synthesize raw pointer ivars.
Also emit a warning for @property(assign) and
@property(unsafe_unretained) under ARC as well as when explicitly
synthesizing a unsafe raw pointer property.
This PR adds the WebKit checker support for
[[clang::annotate_type("webkit.pointerconversion")]].
When this attribute is set on the return value of a function, the
function is treated as safe to call anywhere and the return value's
pointer origin is the argument.`
It's safe for a member function of a class or struct to call a function
or allocate a local variable with a pointer or a reference to a member
variable since "this" pointer, and therefore all its members, will be
kept alive by its caller so recognize as such.
This PR fixes the bug that the checker emits a warning when a function
takes T&& and passes it to another function using std::move. We should
treat std::move like any other pointer conversion and the origin of the
pointer to be that of the argument.
