[PATCH] D92155: Load plugins when creating a CompilerInvocation.

Thu Nov 26 08:00:59 PST 2020

psionic12 added a comment.

In D92155#2418617 <https://reviews.llvm.org/D92155#2418617>, @sammccall wrote:

> - what are the plugins you want to use with clangd? (i.e what kinds of plugins are most important, what are they useful for)

Any plugins which will report diagnostics, especially customized attribute plugins, you can check `clang/examples/` for details. Examples like `AnnotationFunctions`, `Attribute` and `CallSuperAttribute`(which is wrote by me) all defined a customized attribute and apply some rules on it, if the code do not followed the rule, diagnostics are reported.

> - are plugins always threadsafe?

Could you give an example about what kind of thread-safety problem you are imagining? As long as I wrote clang specific plugins, only callbacks are needed to implement, no thread functionalities are used, and as far as I know, clang use single thread to deal with lex, parser, and sema.  So I think thread safety won't be a problem here.

> - are there any meaningful restrictions from a security perspective (e.g. can it load arbitrary .sos from disk, given control over compile args)

Sorry I can't tell, but I think this patch is some sort of NFC patch, what you concern will or will not exist with or without this patch.

> - how robust are plugins when the main frontendaction is nonstandard (e.g. uses preambles, skips function bodies)

Different plugins have different callbacks, these callbacks will only get called if the compile work flow goes there, that is to say if the frontendcation skip the bodies somehow(sorry I don't know how could it be done, could you help to explain more?), the callback will not triggered.

> - the filesystem access to the libraries isn't virtualized (vfs) and I don't know if it really can be.

Sorry I don't quite understand, as long as I know the plugin is no more than a shared library, and the driver is no more than a executable, the load procedure seems no different with other `dlopen` cases.

> - consequences of bad behavior/crash are worse, because clangd is long-running

Does clangd shares the same process with an `FrontendAction`? Because in clang, if a plugin carshes, the whole process does terminated, clang didn't handle this yet(just a core dump).

> - if a plugin works with clang but not clangd, it's unclear whether/where there's a bug

I think that depends. Since clangd use `syntax-only`, plugins other than `frontendAction` seems won't get called. As to `frontendActions`, if it works with clang, it should works with clangd, because `frontendActions` is more about syntax check before generate IR code, clang or clangd or chang-check makes no difference from an `frontendAction`s perspective.

Anyway, some of your concerns seems out of my scope, since clangd have never worked with plugins before, do you think it's better to add some one who knows these? (I just don't know who to add...)

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92155/new/

https://reviews.llvm.org/D92155