Don't leak TemplateIds when a plugin parses late-parsed templates at TU end.
In -fdelayed-template-parsing mode, templates that aren't used are not parsed at all. For some diagnostic plugins, this is a problem since they want to analyse the contents of the template function body. What has been suggested on cfe-dev [1] is to explicitly parse interesting templates in HandleTranslationUnit(); IWYU does this for example [2]. This is workable, but since the delayed parsing doesn't run below a call to ParseTopLevelDecl(), no DestroyTemplateIdAnnotationsRAIIObj object is on the stack to clean up TemplateIds that are created during parsing. To fix this, let ~Parser() clean them up in delayed template parsing mode instead of leaking (or asserting in +Assert builds). (r219810, relanded in r220400, fixed the same problem in incremental processing mode; the review thread of r219810 has a good discussion of the problem.) To test this, give the PrintFunctionNames plugin a flag to force parsing of a template and add a test that uses it in -fdelayed-template-parsing mode. Without the Parser.cpp change, that test asserts. 1: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-August/038415.html 2: https://code.google.com/p/include-what-you-use/source/detail?r=566 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237531 91177308-0d34-0410-b5e6-96231b3b80d8
Showing
- examples/PrintFunctionNames/PrintFunctionNames.cpp 53 additions, 2 deletionsexamples/PrintFunctionNames/PrintFunctionNames.cpp
- lib/Parse/Parser.cpp 29 additions, 20 deletionslib/Parse/Parser.cpp
- test/Frontend/plugin-delayed-template.cpp 17 additions, 0 deletionstest/Frontend/plugin-delayed-template.cpp
Loading
Please register or sign in to comment