3

I am building an ASTMatcher-based tool that I would like to run over my sources:

int main(int argc, const char** argv) {
    CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
    ClangTool Tool(OptionsParser.getCompilations(),
                   OptionsParser.getSourcePathList());
    MatchFinder Finder;

    // Repeated calls to Finder.addMatcher(...);

    Tool.run(newFrontendActionFactory(&Finder).get());

    // Handle the results of the matching.
}

Running this over a source file that depends on other headers yields the following error:

~$ /path/to/my/tool /path/to/my/file.cpp --
/path/to/my/file.cpp:8:10: fatal error: 'string' file not found
#include <string>
         ^~~~~~~~
1 error generated.
Error while processing /path/to/my/file.cpp.

I do not want to include any other headers in this processing, lest my matchers find content in those headers that I do not want to handle.

I tried passing -fsyntax_only to the tool, but I get the same result as above:

 ~$ /path/to/my/tool /path/to/my/file.cpp -- -fsyntax-only

I noticed in the ASTMatcher tutorial that there is a clang::SyntaxOnlyAction. However, I have been unable to figure out how MatchFinder and SyntaxOnlyAction can be used in conjunction with one another. Likewise, I have been able to do an AST dump from the command line of the same file, no problem, so I know it's possible.

Is it possible to configure a MatchFinder-based tool to honor the syntax-only behavior?

fbrereto
  • 35,429
  • 19
  • 126
  • 178
  • Wouldn't syntax-checking still involve processing `#include`? (The meaning of something like `foo bar;` is completely different if the header says `typedef int foo;` vs. if the header says `#define foo 3 +`.) – ruakh Sep 29 '18 at 00:05
  • @ruakh I would be okay with the output using `foo` without knowing what its underlying type is. That's the point of the `syntax-only` check, as far as I know: it's able to validate the syntax even if the header includes types the parser has not seen before. – fbrereto Sep 29 '18 at 00:18
  • @ruakh I am okay with the syntax possibly being misinterpreted. I am interested in being able to match and process the same traversal that I see with the `-fsyntax-only -ast-dump` flags. – fbrereto Sep 29 '18 at 00:29
  • 1
    The traversal that you see with the `-fsyntax-only -ast-dump` flags will depend on the contents of included headers. I don't think Clang has any support for trying to "guess" how to interpret syntax without reading the headers. – ruakh Sep 29 '18 at 00:32
  • @ruakh Okay, thanks for the info. How do I limit the scope of the matching, then, to just the contents of the original file? I don't want to match against the contents of the standard library, or other headers I include. Is this possible? – fbrereto Sep 29 '18 at 00:39
  • 1
    I honestly don't know, but if nothing else, it seems like you should be able to filter in your own matcher code by examining the `clang_getCursorLocation` to determine what file you're in. (You'll have to decide how you want to handle nodes that are split among includes; hopefully that should be rare.) – ruakh Sep 29 '18 at 00:57
  • @ruakh Thanks for all the help! I was able to figure out what file the node originated in with the `getBeginLoc` API. For the time being I'll assume if the node begins in the file(s) passed to the tool, they should be handled. – fbrereto Sep 29 '18 at 01:35
  • Did you ever find a solution to this @fbrereto? – Andrespch May 16 '19 at 20:47
  • @Andrespch Yes and no. The solution was to do the necessary path inclusion to result in a successful compilation pass over the file. As I mentioned in an above comment, I filtered the actions I took on the result based on where the found symbols lived (i.e., in the file I was originally intent on processing.) – fbrereto May 16 '19 at 20:58

0 Answers0