Run Clang-Tidy on taskcluster

[strseb]

This PR adds taskcluster jobs to run clang-tidy. Given we have diffrent c++ source files for each plattform i did create Tasks covering Android,Windows,Macos which should cover most users.

iOS and Linux should be easy to add, but given this pr is already 27 commit's this will be a Followup.

I also touched the clang-tidy file, adding a few checks, however only clang-analyzer-security.* will produce errors, therefore can block merging, for now :)

[brizental]

This PR adds taskcluster jobs to run clang-tidy. Given we have diffrent c++ source files for each plattform i did create Tasks covering Android,Windows,Macos which should cover most users.

Does clang-tidy need to build the files or is it just a static analyzer?

[strseb]

Does clang-tidy need to build the files or is it just a static analyzer?

Yes,ish? It is invoking clang to get the AST so it's only skipping generating bitcode from that AST, so Compilation would need to work to get a proper ast, so we can't just drop it any file.

[brizental]

Yes,ish? It is invoking clang to get the AST so it's only skipping generating bitcode from that AST, so Compilation would need to work to get a proper ast, so we can't just drop it any file.

I know I am being annoying about this but... It seems excessive to run a static analyzer multiple times in different platforms just to analyze all files when it can be done by any of them only once. For local development I am still not a big fan, but I get that attempting to figure out what is built for each platform is a pain and something locally we might need more.

Idea: what about running cland-tidy only filed touched since commit X? Or only on staged files if no commit is provided?

[strseb]

analyze all files when it can be done by any of them only once.

for a few files that might be true but consider i.e controller.cpp, it's used in all builds

#if defined(MZ_FLATPAK)
#  include "platforms/linux/networkmanagercontroller.h"
#elif defined(MZ_LINUX)
#  include "platforms/linux/linuxcontroller.h"
#elif defined(MZ_MACOS) || defined(MZ_WINDOWS)
#  include "localsocketcontroller.h"
#elif defined(MZ_IOS)
#  include "platforms/ios/ioscontroller.h"
#elif defined(MZ_ANDROID)
#  include "platforms/android/androidcontroller.h"
#else
#  include "platforms/dummy/dummycontroller.h"
#endif

On each platform we have completely different shapes of the input object (even 2 different for linux), depending on the compiler arguments. Even on "cross-plattform" sources.
On excessiveness, i really do not think that ~10 minutes per target is excessive when it covers the whole codebase, that's roughly 1,5 functional test suites :)

Idea: what about running cland-tidy only filed touched since commit X? Or only on staged files if no commit is provided?

Sure i like that, for local development, on ci this would hide existing errors.

[brizental]

Ok, I think I misunderstood your first answer i.e. clang-tidy is not just a static analyzer 🤦‍♀️

[brizental]

r+wc

[brizental]

Why is this condition required here?

[strseb]

We do not generate that target i.e if there is no clang-tidy binary found, so the target may or may not exist.

[brizental]

Sure but the dependencies are being added into this target, so if we don't build this the add_depencies also doesn't do anything.

[brizental]

AH nvm, we don't even create the target.

[brizental]

FWIW, if you don't even create it the TARGET keyword is prob unnecessary. It's a nit though.