Commit Graph

77 Commits

Author SHA1 Message Date
Jameson Nash 9d59cfc67e clang-analyzer plugins require LLVM_ENABLE_PLUGINS also
The clang-analyzer plugins are not linked to a particular tool, so they
can only be compiled if plugins are broadly supported. We could opt
instead to decide whether to link them to specifically against clang or
with undefined symbols, depending on the value of LLVM_ENABLE_PLUGINS,
but we do not currently expect there to be a use case for that rather
niche configuration.

Differential Revision: https://reviews.llvm.org/D119591
2022-02-16 11:59:09 -05:00
Jameson Nash 76cad51ba7 replace clang LLVM_ENABLE_PLUGINS -> CLANG_PLUGIN_SUPPORT in tests
Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library.
Fixes an issue noted in D111100.

Differential Revision: https://reviews.llvm.org/D119199
2022-02-09 17:31:34 -05:00
Jonas Devlieghere 2b3d49b610 [Clang] Migrate llvm::make_unique to std::make_unique
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942
2019-08-14 23:04:18 +00:00
Tom Stellard 2e97d2aa1b cmake: Add CLANG_LINK_CLANG_DYLIB option
Summary:
Setting CLANG_LINK_CLANG_DYLIB=ON causes clang tools to link against
libclang_shared.so instead of the individual component libraries.

Reviewers: mgorny, beanz, smeenai, phosek, sylvestre.ledru

Subscribers: arphaman, cfe-commits, llvm-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63503

llvm-svn: 365092
2019-07-03 22:45:55 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Tom Stellard 8c020758a0 cmake: Remove uses of add_llvm_loadable_module macro
This was removed from llvm in r349839.

llvm-svn: 349840
2018-12-20 22:04:36 +00:00
Kristof Umann d173caf3bf Test commit
llvm-svn: 333080
2018-05-23 12:48:55 +00:00
David Carlier 5764db4e57 This is a test commit.
llvm-svn: 333059
2018-05-23 04:27:39 +00:00
Justin Lebar b89d85fec0 [Examples] Fix use of sema.LateParsedTemplateMap in clang/examples.
llvm-svn: 283778
2016-10-10 16:41:00 +00:00
John Brawn 4d79ec7fe8 Reapply r276973 "Adjust Registry interface to not require plugins to export a registry"
This differs from the previous version by being more careful about template
instantiation/specialization in order to prevent errors when building with
clang -Werror. Specifically:
 * begin is not defined in the template and is instead instantiated when Head
   is. I think the warning when we don't do that is wrong (PR28815) but for now
   at least do it this way to avoid the warning.
 * Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY
   instead provide a template definition then do explicit instantiation. No
   compiler I've tried has problems with doing it the other way, but strictly
   speaking it's not permitted by the C++ standard so better safe than sorry.

Original commit message:

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

llvm-svn: 277806
2016-08-05 11:01:08 +00:00
John Brawn 2853269224 Revert r276973 "Adjust Registry interface to not require plugins to export a registry"
Buildbot failures when building with clang -Werror. Reverting while I try to
figure this out.

llvm-svn: 277008
2016-07-28 17:17:22 +00:00
John Brawn 778c3c6c61 Reapply r276856 "Adjust Registry interface to not require plugins to export a registry"
This version has two fixes compared to the original:
 * In Registry.h the template static members are instantiated before they are
   used, as clang gives an error if you do it the other way around.
 * The use of the Registry template in clang-tidy is updated in the same way as
   has been done everywhere else.

Original commit message:

Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

llvm-svn: 276973
2016-07-28 12:48:17 +00:00
John Brawn 3839263204 Revert r276856 "Adjust Registry interface to not require plugins to export a registry"
This is causing a huge pile of buildbot failures.

llvm-svn: 276857
2016-07-27 11:41:18 +00:00
John Brawn 63aff61019 Adjust Registry interface to not require plugins to export a registry
Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.

This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.

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

llvm-svn: 276856
2016-07-27 11:18:38 +00:00
Chris Bieneman 28cdb677ed [CMake] Cleaning up CMake feature gating on 2.8.12
CMake 2.8.12 introduced interface libraries and some related policies. This removes the conditional block because we're now past 2.8.12.

llvm-svn: 272312
2016-06-09 21:29:55 +00:00
NAKAMURA Takumi d8cd060422 Revert r260265, "clang-cl: Support loading plugins on Windows"
It causes memory exhaust on mingw-w64(x64). Investigating.

llvm-svn: 260536
2016-02-11 16:33:20 +00:00
Ehsan Akhgari 75b3a4b507 clang-cl: Support loading plugins on Windows
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

llvm-svn: 260265
2016-02-09 19:43:11 +00:00
Chris Bieneman 2bf68c6c1c Remove autoconf support
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html

    "This is the way [autoconf] ends
    Not with a bang but a whimper."
    -T.S. Eliot

Reviewers: chandlerc, grosbach, bob.wilson, echristo

Subscribers: klimek, cfe-commits

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

llvm-svn: 258862
2016-01-26 21:30:40 +00:00
Alexander Kornienko ab9db51042 Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").
llvm-svn: 240353
2015-06-22 23:07:51 +00:00
Alexander Kornienko 3d9d929e42 Fixed/added namespace ending comments using clang-tidy. NFC
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.

llvm-svn: 240270
2015-06-22 09:47:44 +00:00
Nico Weber 28e0f243cf 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
2015-05-17 01:07:16 +00:00
Alexander Kornienko 34eb20725d Use 'override/final' instead of 'virtual' for overridden methods
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

llvm-svn: 234678
2015-04-11 02:00:23 +00:00
Alexander Kornienko 6ee521c7eb Replace size() calls on containers with empty() calls where appropriate. NFC
http://reviews.llvm.org/D7090

Patch by Gábor Horváth!

llvm-svn: 226914
2015-01-23 15:36:10 +00:00
David Blaikie 6beb6aa8f0 Recommit 213307: unique_ptr-ify ownership of ASTConsumers (reverted in r213325)
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.

llvm-svn: 215323
2014-08-10 19:56:51 +00:00
David Blaikie 62a56f39b7 Revert "unique_ptr-ify ownership of ASTConsumers"
This reverts commit r213307.

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

llvm-svn: 213325
2014-07-17 22:34:12 +00:00
David Blaikie a51666a4d6 unique_ptr-ify ownership of ASTConsumers
(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)

llvm-svn: 213307
2014-07-17 20:40:36 +00:00
NAKAMURA Takumi 9b9de47d15 [CMake] Give explicit dependencies to a couple of modules, PrintFunctionNames and SampleAnalyzerPlugin, for Win32.DLL.
llvm-svn: 212906
2014-07-13 13:40:23 +00:00
NAKAMURA Takumi 6672b8e4ee PrintFunctionNames/CMakeLists.txt: Fix a comment.
llvm-svn: 212905
2014-07-13 13:38:55 +00:00
NAKAMURA Takumi ad4c06c656 Instantiate llvm::Registry<clang::PluginASTAction> in FrontendAction.cpp.
- Plugins don't need to export _ZN4llvm8Registry*.
  - Win32.DLL cannot merge common symbols among DLLs. Static members in llvm::Registry should be instantiated in a parent.

llvm-svn: 212821
2014-07-11 15:06:24 +00:00
NAKAMURA Takumi 7da9487dd4 [CMake] Get rid of explicit dependencies to include/clang/*.inc and introduce CLANG_TABLEGEN_TARGETS.
This does;
  - clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
  - List of targets is added to LLVM_COMMON_DEPENDS.
  - all clang libraries and targets depend on generated headers.

You might wonder this would be regression, but in fact, this is little loss.
  - Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
  - clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
  - Each library's dependencies to tblgen'd files might vary along headers' structure.
    It made hard to track and update *really optimal* dependencies.

Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.

llvm-svn: 201842
2014-02-21 07:59:59 +00:00
Jordan Rose ab57f79df4 [examples] Add tablegen'd ClangCommentCommandList as a dependency for plugins.
Also, remove library dependencies for the sample analyzer-plugin. The only
library changes that would require a rebuild should be in headers, which
should already implicitly be marked as dependencies.

llvm-svn: 201350
2014-02-13 18:12:30 +00:00
Jordan Rose 68db107c81 [examples] Use loadable modules instead of shared libraries for Clang plugins.
This avoids linking in extra copies of, say, LLVMSupport.

llvm-svn: 201256
2014-02-12 21:04:23 +00:00
NAKAMURA Takumi ac3ff26885 [CMake] Parameterize MODULE and SHARED in add_clang_library().
llvm-svn: 199902
2014-01-23 15:33:44 +00:00
Nico Weber c45921903f Don't use PrintFunctionNames.exports on Windows.
llvm-svn: 198187
2013-12-30 00:05:56 +00:00
Nico Weber e8ef46c851 Fix typo in comment.
llvm-svn: 198186
2013-12-29 23:15:01 +00:00
Nico Weber 216436c77a [cmake] Set in LLVM_EXPORTED_SYMBOL_FILE PrintFunctionNames/CMakeLists.txt.
The corresponding Makefile sets it too. Also tweak add_clang_library to support
LLVM_EXPORTED_SYMBOL_FILE for modules.

llvm-svn: 198185
2013-12-29 23:14:26 +00:00
Alp Toker 9477f9e52f Fix getCustomDiagID() usage in example code
This was setting a bad example. DiagIDs are a limited resource and the message
argument is evaluated as a format string.

llvm-svn: 197855
2013-12-21 05:19:58 +00:00
NAKAMURA Takumi ac85179219 [CMake] Update target_link_libraries() and LLVM_LINK_COMPONENTS for each CMakeLists.txt.
llvm-svn: 196916
2013-12-10 12:40:37 +00:00
Douglas Gregor 27c42e66bb Revert r170801, which breaks the mingw build.
llvm-svn: 170804
2012-12-20 23:36:52 +00:00
Douglas Gregor d04592dc81 Eliminate errors when running the 'PrintFunctionNames' plugin, from Li Qun!
llvm-svn: 170801
2012-12-20 23:11:42 +00:00
Chandler Carruth 8675b4af77 Sort the #include lines for examples/...
llvm-svn: 169241
2012-12-04 09:37:22 +00:00
NAKAMURA Takumi a9a35c67e1 libclang, examples: [CMake] Add dependencies to tblgen'd headers.
llvm-svn: 160849
2012-07-27 06:17:56 +00:00
Chandler Carruth 28969b4139 Remove a goofy CMake hack and use the standard CMake facilities to
express library-level dependencies within Clang.

This is no more verbose really, and plays nicer with the rest of the
CMake facilities. It should also have no change in functionality.

llvm-svn: 158888
2012-06-21 01:30:21 +00:00
Manuel Klimek 34e0f6cba2 Reverted unintentional commit.
llvm-svn: 155629
2012-04-26 08:46:12 +00:00
Manuel Klimek c01d3fbe0f Adds a small tutorial on how to write RAV based ASTFrontendActions.
llvm-svn: 155627
2012-04-26 08:35:39 +00:00
Dylan Noblesmith 4cde694855 examples: flesh out PFN readme
Show how to actually use the arguments it has.

llvm-svn: 146845
2011-12-18 11:30:53 +00:00
Douglas Gregor 9f39a765e2 Update signature of HandleTopLevelDecl.
llvm-svn: 145001
2011-11-19 19:22:13 +00:00
Eli Friedman f42db7ce48 Fix examples for r140478. PR11021.
llvm-svn: 140618
2011-09-27 18:33:47 +00:00
Peter Collingbourne 8f5cf74c77 Re-instate r125819 and r125820 with no functionality change
llvm-svn: 126060
2011-02-19 23:03:58 +00:00
Rafael Espindola a6d2bff0c5 Revert 125820 and 125819 to fix PR9266.
llvm-svn: 126050
2011-02-19 21:39:31 +00:00