aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Frontend/CompilerInvocation.cpp
diff options
context:
space:
mode:
authorValeriy Savchenko <vsavchenko@apple.com>2021-04-16 21:10:05 +0300
committerValeriy Savchenko <vsavchenko@apple.com>2021-04-28 18:37:37 +0300
commit61ae2db2d7a97af5206afe609a303071711f9e6e (patch)
tree127ce1f2bcb9d45cf5eb083064f2025f30cc7e5a /clang/lib/Frontend/CompilerInvocation.cpp
parent1dad8c5036bc912078f7859d89e3ea571616fc4a (diff)
downloadllvm-61ae2db2d7a97af5206afe609a303071711f9e6e.zip
llvm-61ae2db2d7a97af5206afe609a303071711f9e6e.tar.gz
llvm-61ae2db2d7a97af5206afe609a303071711f9e6e.tar.bz2
[analyzer] Adjust the reported variable name in retain count checker
When reporting leaks, we try to attach the leaking object to some variable, so it's easier to understand. Before the patch, we always tried to use the first variable that stored the object in question. This can get very confusing for the user, if that variable doesn't contain that object at the moment of the actual leak. In many cases, the warning is dismissed as false positive and it is effectively a false positive when we fail to properly explain the warning to the user. This patch addresses the bigest issue in cases like this. Now we check if the variable still contains the leaking symbolic object. If not, we look for the last variable to actually hold it and use that variable instead. rdar://76645710 Differential Revision: https://reviews.llvm.org/D100839
Diffstat (limited to 'clang/lib/Frontend/CompilerInvocation.cpp')
0 files changed, 0 insertions, 0 deletions