Kristóf Umann

One thing to add: diagtool will be broken if you * build diagtool at least once * build with shared libraries * build some dependencies of diagtool on a different...

I see you made some changes to the profiles as well, is that intentional?

Please note that the Sarif output still needs a great amount of maturing, for example, it can't handle checkers loaded from plugins, which is a particularly great weakness for our...

> Apologies for confusion, but it seems to me that #4011 added support for parsing SARIF into the CodeChecker, while i (and i suspect many others) was fully expecting that...

I totally support this patch -- the default output is still let a little loose on verbosity. With that said, metadata.json isn't very human readable without formatting, so we should...

https://github.com/Ericsson/codechecker/pull/4113

Hi! Sorry for the late response, we definitely appreciate all the help we can get! We already have an option to pass clang static analyzer flags through CodeChecker via the...

This is kind of a dealbreaker for gcc support. It is in our best interest that the community has at least a somewhat convenient way to make CodeChecker accept gcc-13.

Some examples for `CodeChecker analyzers`: gcc-13 is available: ```bash $ CodeChecker analyzers -o table --------------------------------------------------------------------------------------- Name | Path | Version --------------------------------------------------------------------------------------- clangsa | (my absolute path)/llvm-project/releaseBuild/bin/clang-17 | 16.0.4 clang-tidy |...

I don't intend to die on this hill, but I'm not yet convinced that a soft warning is the way to go. Breaking existing functionality is never a step to...