In D54222#2295374, @JonasToth wrote:

Do you have data for other projects? As this is not a very common thing and probably different for code-bases with plugins and so on, the "chattiness" of the check would be interesting to know.

In D54222#1290789, @JonasToth wrote:

I agree with @Eugene.Zelenko that this check should rather live in bugprone- as the issue its diagnosing is not LLVM specific. It is ok to add an alias into the llvm module.

@JonasToth It looks like there are some outstanding review comments that need to be addressed. I've gotten some time allocated to work on this next week.

Ping? It sounds like the consensus is to commit this as-is and, if there's a negative fallout for users of clang-tidy, either split out the functions or pare the list down later?

Removing std::move.

Adding context.

Addressed review comments.

In D65212#1599841, @aaron.ballman wrote:

LGTM! Do you need someone to commit on your behalf?

Update an additional place that used -z.

rC345628 makes Clang depend on llvm::json, so this is no longer relevant for my purposes but I think it is a bit nicer to go this approach than always using -undefined suppress. I'd be okay with abandoning this revision if you'd prefer to keep things as-is.

Specify -bundle_loader when giving a PLUGIN_TOOL to add_llvm_loadable_module. This doesn't limit what executables can load the resulting shared library and just informs the static linker what functions will be present when the library is loaded.

In D53778#1277902, @beanz wrote:

I'm not really sure this is the best solution. This will result in bloating the clang binary substantially. An alternative approach would be to use linker order precedence, and pass the LLVM executable first, then LLVM static archives later on the link line. That would allow minimal tool binaries, and link the LLVM bits into your plugin.

I do.

Added more context.

In D52905#1257040, @NoQ wrote:

Hmmm, interesting. A checker doesn't usually need to access these specific static locals, at least not directly. These are usually accessed through functions in .cpp files that are supposed to be compiled with a pointer to the correct instance of the static local, and it doesn't seem to be necessary to expose them to plugins, simply because i don't immediately see why would a plugin want to use them. In this sense, i believe that the entire definition of these traits should be moved to .cpp files and be made private, accessed only via public methods of respective classes. But i guess it's more difficult and it's a separate chunk of work, so i totally approve this patch.