zpc: Add analyzers support

[rzr]

• Coverity can run on public repos
• sonar cloud can be considered, if not trivial we can fallback to gcc (static analyser options are not enabled ATM)
• Valgrind for unit tests will help too
• gcc -fanalizer
• CodeQL (enabled in my fork, will turn it in on upstream once fixes are merged, see related commit)
  Any more suggestions welcome

[bperry-silabs]

We are also interested in running some static analysis. Recently, over the weekend, I started building ZPC with GCC-14 and the C++ static analysis. It works well but it is very resource intensive. Make sure you have G++-14 and compile with the -fanalyzer argument. I edited helper.mk to enable the build.

https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html

[rzr]

We are also interested in running some static analysis. Recently, over the weekend, I started building ZPC with GCC-14 and the C++ static analysis. It works well but it is very resource intensive.

May we enable this as part of the release process.

Also based on the work on recent investigation, I decided to use the opportunity to have a preventive strategy
so I have enabled CodeQL on a fork of zpc (and results worth discussing if any interest)

[bperry-silabs]

Sreejana and I are going to dig into G++-14 static analysis more. We will reach out soon with results and how we can possibly begin using thresholds during the release process. Certainly just running -fanalyzer in any way and doing something with the results will be sufficient for SSMF. Building it into the release process would be icing on the cake.

[rzr]

So far I didnt consider updating compiler, I thought gcc-12 or 13 would be enough see:
https://developers.redhat.com/articles/2023/05/31/improvements-static-analysis-gcc-13-compiler#trying_it_out

But that change would be desirable when we bump to next debian stable (expected this summer 2015, we might also realign RUST to use the distro one and no more rustup)

[bperry-silabs]

You should use whatever compiler you feel meets your production needs. I don't mind dealing with experimental or bleeding-edge features and we aren't trying to maintain long-lived build cycles on our side. Different versions may yield different bugs or false positive rates, so it may be a good idea to rely on more than one GCC version in any case.

[rzr]

IMHO, well from maintainance perspective supporting debian stable is the least we can do based on our capacity, adding clang would be something nice.

ATM, Supporting more would be only a best effort or used when needed/justified.

Ticket to track on the release quality check:

• zpc: next release #63 (comment)