[llvm] [workflows] Add post-commit job that periodically runs the clang static analyzer (PR #94106)

[Balazs Benics via llvm-commits]

steakhal wrote:

> > Even if it's noisy, just having it run once a day post commit so that people who are interested can look at the results seems like a decent idea.
> 
> This is really only for informational purposes at this point. I was going to watch it for a while to see which of the checks are helpful and which ones are prone to false positives. I'm open to changing the set of checks and also using clang-tidy if someone has a good recommendation for which checks to run.

Usually, clang-tidy is good for context insensitive rules, basically for the cases that can be easily detected by looking at the AST.
CSA is usually better if some state-machine describes a bug condition, which is attached to some value. For example, if we have a pointer to some resource, use it and then close/release it. And this is tracked across different statements and conditions.

W.r.t the FP TP rate of the checks, the default enabled checkers is usually a fairly conservative selection, which should produce low FP rate in practice. There are useful checkers and combinations that are not enabled by default, but considered to be fairly mature otherwise. At Sonar, we use CSA as our symbolic execution engine backend for our rules where it's relevant, I'll ask if we can publish what subset of checkers we use in production. ([SonarCloud](https://www.sonarsource.com/products/sonarcloud/) is free for open-source projects, [example](https://github.com/sonarsource-cfamily-examples/linux-cmake-gh-actions-sc)).
I can also see the benefit of having something from directly in-house, like scan-build.

Besides the scan-build, there is also [CodeChecker](https://github.com/Ericsson/codechecke) which serves as a frontend for static analyzer invocations. They already maintain checker ["profiles"](https://github.com/Ericsson/codechecker/blob/master/config/labels/analyzers/clangsa.json) that categorizes the checkers. /cc @NagyDonat representing them. He could probably propose some refined list for us about what checkers work for them in practice.

For now, I think even the most basic setup is better than having nothing. So I'm all for having this PR.

---

FYI I also considered contributing something like this, but I found no policies around introducing CI workflows, and I'm aware that even if this is an open-source and well-known project, at the end of the day we probably only have limited CI time and/or some companies pay for that time - like build bots.

BTW don't we already have some nightly for scan-build? https://llvm.org/reports/scan-build/
Do you plan to replace that?

https://github.com/llvm/llvm-project/pull/94106