[PATCH] D52905: CSA: fix accessing GDM data from shared libraries

[Joe Ranieri via Phabricator via cfe-commits]

jranieri-grammatech added a comment.

In https://reviews.llvm.org/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.


My current goal is to examine all of the information the analyzer has available at callsites and extract the portions that the project I'm working on might be interested in. I wouldn't disagree with your assessment in general, but it's definitely not something I have time allocated towards doing.

> Also, i guess that's what they meant when they were saying that REGISTER_TRAIT_WITH_PROGRAMSTATE [and similar] macros shouldn't be used in headers (https://reviews.llvm.org/D51388?id=162968#inline-455495).

Yeah, I think so.

> Did you use any sort of tool to find those? I.e., are there more such bugs, and can we prevent this from regressing and breaking your workflow later?

I wrote a very quick and dirty clang plugin that has this AST matcher:

  returnStmt(hasReturnValue(ignoringImplicit(unaryOperator(
                 hasOperatorName("&"),
                 hasUnaryOperand(declRefExpr(
                     to(varDecl(isStaticLocal()))))))),
             isExpansionInFileMatching("/include/.*\\.h"))

where `isStaticLocal` is defined as:

  AST_MATCHER(VarDecl, isStaticLocal) {
    return Node.isStaticLocal();
  }

I've since adapted it to a clang-tidy checker under the llvm 'module', which I'll aim at getting approval to open source as well. Do you know if there's a way to run clang-tidy over all of clang+llvm automatically? My plugin approach had the advantage of just needing to fiddle with CMAKE_CXX_FLAGS to run against the whole codebase...

> You didn't add reviewers. Does it mean that you are still planning to work on this patch further, or do you want this patch to be committed in its current shape? Static Analyzer patches are usually prefixed with [analyzer] (a few people auto-subscribe to those) and please feel free to add me and @george.karpenkov as reviewers, and the code owner is @dcoughlin.

This is just my inexperience with the Phabricator patch submission process showing through; I've traditionally emailed patches to the various -dev lists.


Repository:
  rC Clang

https://reviews.llvm.org/D52905