[all-commits] [llvm/llvm-project] 07a7fd: [analyzer] Print the offending function at EndAnal...

[Balazs Benics via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 07a7fd314a118393e6ca5e4dbcc9c3d91ff96172
      https://github.com/llvm/llvm-project/commit/07a7fd314a118393e6ca5e4dbcc9c3d91ff96172
  Author: Balazs Benics <balazs.benics at sigmatechnology.se>
  Date:   2022-06-10 (Fri, 10 Jun 2022)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
    M clang/lib/StaticAnalyzer/Core/ExprEngine.cpp

  Log Message:
  -----------
  [analyzer] Print the offending function at EndAnalysis crash

I've faced crashes in the past multiple times when some
`check::EndAnalysis` callback caused some crash.
It's really anoying that it doesn't tell which function triggered this
callback.

This patch adds the well-known trace for that situation as well.
Example:
  1.      <eof> parser at end of file
  2.      While analyzing stack:
          #0 Calling test11

Note that this does not have tests.
I've considered `unittests` for this purpose, by using the
`ASSERT_DEATH()` similarly how we check double eval called functions in
`ConflictingEvalCallsTest.cpp`, however, that the testsuite won't invoke
the custom handlers. Only the message of the `llvm_unreachable()` will
be printed. Consequently, it's not applicable for us testing this
feature.

I've also considered using an end-to-end LIT test for this.
For that, we would need to somehow overload the `clang_analyzer_crash()`
`ExprInspection` handler, to get triggered by other events than the
`EvalCall`. I'm not saying that we could not come up with a generic way
of causing crash in a specific checker callback, but I'm not sure if
that would worth the effort.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D127389