[analyzer][clang] Remove external plugin support

[gamesh411]

Shipping plugins as external dynamic libraries for Clang Static Analyzer is generally frowned upon, and not supported. This patch removes the existing support for using external ClangSA analyzer plugins.

[whisperity]

Agreed, using the plugins is not supported. Moreover, if someone is enough of a power-user (one example I know of is https://github.com/GrammaTech/swap-detector) to use plugins, they can achieve the same by adding the flags explicitly to analyse --saargs or something.

[bruntib]

I agree that the plugins could be provided by --saargs, so I approve this patch. But what do you mean by "not supported"? Clang 17 still has a -load flag for loading plugins.

[whisperity]

But what do you mean by "not supported"? Clang 17 still has a -load flag for loading plugins.

There is also -fplugin=, which provides a higher-level interface.

It is not supported in the sense that you will get no help ("support") in using that feature, including help about crappy results, crashes, complete and utter corruption of your filesystem, exploits, etc. The official stance of CSA (but not necessarily Clang as a whole!), is that if you use plugins and anything goes wrong, you're — for the lack of a better phrase — SOL. (It's like reporting a kernel panic of a tainted kernel (a kernel that had proprietary kos (drivers) loaded into it), the number one reply you'll get on the mailing list is that your crash report is disregarded.) It is your own and absolute responsibility to deal with every consequence that stems from having a plugin.

And because it is unsupported, there are no guarantees that whatever code you create and potentially distribute as a plugin will work with any arbitrary Clang version. They don't care about API or ABI compatibility.

[whisperity]

@gamesh411 I'll summarise what I discussed with @bruntib prior because it looks like they hadn't gotten around to publishing their comments so far.

[whisperity]

Basically, there is one significant issue with this change where --saargs <file where -Xclang stuff is> is not equivalent to the plugin features, and that is the loading of the checker list. To the best of our understanding, while CodeChecker analyze does pass through the "saargs" parameter, the facilities for generating the checker list (and the engine options, likely, as well) do not**.

There is a question of what "support" means. I tried to find an official answer about the plugins, but to no avail. Technically, Clang offers the feature, but the --load flag is, AFAIK, not documented. Now we can decide we don't want to expose this through CodeChecker (power users who create plugins could just as well create downstream forks...), but maybe we should circle back to this after looking into what -fplugin= does, perhaps it's a documented (albeit not suggested, but nevertheless official) way of injecting customised checkers.