summaryrefslogtreecommitdiffstats
path: root/clang/unittests/Format/FormatTest.cpp
diff options
context:
space:
mode:
authorNico Weber <nicolasweber@gmx.de>2015-05-17 01:07:16 +0000
committerNico Weber <nicolasweber@gmx.de>2015-05-17 01:07:16 +0000
commit28e0f243cf521103f2c63e1a6b8ea5ff315d6da2 (patch)
tree748dbc65fa68b4e5108aee4b929462083b07feaa /clang/unittests/Format/FormatTest.cpp
parent3b6e51a73ffe202a4baa027f7ae40b12c43afaaa (diff)
downloadbcm5719-llvm-28e0f243cf521103f2c63e1a6b8ea5ff315d6da2.tar.gz
bcm5719-llvm-28e0f243cf521103f2c63e1a6b8ea5ff315d6da2.zip
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 llvm-svn: 237531
Diffstat (limited to 'clang/unittests/Format/FormatTest.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud