[ESD-2180] Improved clang-tidy module

[woodfell]

There is a bit going on in here.

First there is a new module ListTargets.cmake which can enumerate all targets in a source tree based on certain criteria

Second there is a new property defined on targets SWIFT_TYPE which is filled in by all the swift_add_* functions. This property is one of the criteria which ListTargets can filter on.

There is a new function swift_validate_targets which combines the above two items to make sure that all compilable targets defined in a project were added with swift_add_* rather than the native cmake add_*. In the future this function can be expanded to provide extra validation of targets.

Finally there is a completely rewritten ClangTidy module. Rather than having to pass a git GLOB pattern to swift_setup_clang_tidy a replacement function swift_create_clang_tidy_targets uses ListTargets and the new property to be far more smart about building up the list of source files to pass to clang-tidy

All targets defined within a repository have their own clang tidy targets, eg clang-tidy-starling, clang-tidy-pvt-engine. Fixes are exported to fixes-<target>.yaml

clang-tidy-all still exists and lints all "core" parts of starling, anything defined with swift_add_executable or swift_add_library

clang-tidy-world lints absolutely everything defined in a repository, all core targets, tools, tests, test libraries and so on.

Each clang-tidy-* target has a corrosponding clang-tidy-<target>-check target which returns an error code should any errors be generated.

The old "diff" clang-tidy targets no longer exist.

All clang-tidy targets are run in parallel using a script from the LLVM project.

.clang-tidy is now autogenerated during swift_setup_clang_tidy, as this module is updated in other repositories all versions of .clang-tidy can be removed and we can finally have proper standardisation across key projects. In recognition that some other projects really do want their own configs this behaviour is controllable and can be disabled if required.

[woodfell]

This file taken almost verbatim from LLVM.
The only change is to not write an empty fixes file if no errors were generated

[RReichert]

Really awesome work. Minor nits and comments, but looks good to me.

[RReichert]

were these intentional changes?

[woodfell]

No, I made the mistake of running cmake-format before committing everything. It cocked up the entire file. I'll revert this header block but won't bother with the rest of the file even though it looks like garbage

[RReichert]

nice, like the idea. I'd probably ask on slack if anyone relies on the .clang-tidy on their repo. I personally dont, but I know that CLion does have some nice integration with clang-tidy and reports these errors in realtime in the IDE.

[woodfell]

Yeah I use something similar. It's pretty important to keep .clang-tidy in the repo root thanks to the braindead way clang-tidy looks for its config. It would be so much easier if you could pass the path to a config file as a command line argument, but for whatever reason they didn't implement it like that.

[jungleraptor]

LGTM.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
4 Code Smells

No Coverage information
0.0% Duplication

[woodfell]

I've had to add the original ClangTidy.cmake back in to this PR (as OldClangTidy.cmake) due to a problem in some higher level repositories that haven't been converted over to use the swift_add_* functions yet. It was going to be too much effort to convert all of them as well (and probably cause a fair amount of annoyance due to stricter compile options) so they can keep the old module for the moment.