It causes memory exhaust on mingw-w64(x64). Investigating.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260536 91177308-0d34-0410-b5e6-96231b3b80d8

This builds on the support being added to LLVM to import and export
registries from DLLs.  This will allow us to pick up the registry
entries added in the DLL's copy of FrontendPluginRegistry.

This will allow us to use plugins on Windows using:
$ clang-cl -Xclang -load -Xclang plugin.dll \
           -Xclang -add-plugin -Xclang foo

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260265 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240353 91177308-0d34-0410-b5e6-96231b3b80d8

The patch is generated using this command:

  $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
      -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
      work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240270 91177308-0d34-0410-b5e6-96231b3b80d8

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

Summary:
The patch is generated using clang-tidy misc-use-override check.

This command was used:

  tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py \
    -checks='-*,misc-use-override' -header-filter='llvm|clang' -j=32 -fix

Reviewers: dblaikie

Reviewed By: dblaikie

Subscribers: klimek, cfe-commits

Differential Revision: http://reviews.llvm.org/D8926

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234678 91177308-0d34-0410-b5e6-96231b3b80d8

http://reviews.llvm.org/D7090

Patch by Gábor Horváth!


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226914 91177308-0d34-0410-b5e6-96231b3b80d8

After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@215323 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit r213307.

Reverting to have some on-list discussion/confirmation about the ongoing
direction of smart pointer usage in the LLVM project.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213325 91177308-0d34-0410-b5e6-96231b3b80d8

(after fixing a bug in MultiplexConsumer I noticed the ownership of the
nested consumers was implemented with raw pointers - so this fixes
that... and follows the source back to its origin pushing unique_ptr
ownership up through there too)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@213307 91177308-0d34-0410-b5e6-96231b3b80d8

This was setting a bad example. DiagIDs are a limited resource and the message
argument is evaluated as a format string.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197855 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169241 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155629 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155627 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@145001 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@140618 91177308-0d34-0410-b5e6-96231b3b80d8

for use in reporting diagnostics.
 - We don't want to use the Action's own CompilerInstance, because that is only
   initialized during file processing and I like that invariant.

Also, if ParseArgs returns false then abandon execution.

Also, remove unused PluginASTAction::PrintHelp virtual method.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@110039 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109438 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@106113 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91176 91177308-0d34-0410-b5e6-96231b3b80d8

 - The build scriptage is about twice as long as the code, which is nice. :)

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@88826 91177308-0d34-0410-b5e6-96231b3b80d8