llvm-project.git/clang/test/Analysis/analyzeOneFunction.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. [clang][test] Fix test issue under LLVM_REVERSE_ITERATION (#167394) 2025-11-11T19:29:52+00:00 Paul Kirth paulkirth@google.com 2025-11-11T19:29:52+00:00 f5e2c5ddcec758ffdaff027a239a163331a73292 The order of these items may not be the same if reverse iteration is enabled. From what I can tell this is related to visitation order, and I don't see an easy way to handle that using the typical solutions, like MapVector, etc. For now, just use CHECK-DAG to get the test into a passing state. Fixes #167057 
The order of these items may not be the same if reverse iteration is
enabled. From what I can tell this is related to visitation order, and I
don't see an easy way to handle that using the typical solutions, like
MapVector, etc. For now, just use CHECK-DAG to get the test into a
passing state.

Fixes #167057
 [analyzer] Teach -analyze-function about USRs, extend documentation (#161666) 2025-10-03T14:24:03+00:00 Balazs Benics benicsbalazs@gmail.com 2025-10-03T14:24:03+00:00 ef4471edfa6d72e13c8f8e90bef521caee6f4b1f This flag is really convinient in most cases. It's easy to figure out what value to pass for most cases. However, it can sometimes match too many times, like for template functions that has non-decuded (aka. explicitly specified) template parameters - because they don't appear in the parameter list, thus they are not accounted for in the current logic. It would be nice to improve `getFunctionName` but I'd say to just settle on using USRs. So this PR enables passing USRs to the flag, while keeping previous behavior. 
This flag is really convinient in most cases.
It's easy to figure out what value to pass for most cases. However, it
can sometimes match too many times, like for template functions that has
non-decuded (aka. explicitly specified) template parameters - because
they don't appear in the parameter list, thus they are not accounted for
in the current logic.

It would be nice to improve `getFunctionName` but I'd say to just settle
on using USRs. So this PR enables passing USRs to the flag, while
keeping previous behavior.