summaryrefslogtreecommitdiff
path: root/examples
Commit message (Collapse)AuthorAgeFilesLines
* Fixup build of clang-interpreter example after change in r370122.Douglas Yung2019-08-281-5/+1
| | | | | | This should fix the build failure on llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@370151 91177308-0d34-0410-b5e6-96231b3b80d8
* [Clang] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-143-3/+3
| | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368942 91177308-0d34-0410-b5e6-96231b3b80d8
* [ORC] Fix clang-interpreter example code broken by r368707.Douglas Yung2019-08-141-3/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@368778 91177308-0d34-0410-b5e6-96231b3b80d8
* Update the SimpleJIT class in the clang-interpreter example to use ORCv2.Lang Hames2019-07-181-44/+53
| | | | | | This will remove the ORCv1 deprecation warnings. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@366511 91177308-0d34-0410-b5e6-96231b3b80d8
* cmake: Add CLANG_LINK_CLANG_DYLIB optionTom Stellard2019-07-033-5/+9
| | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@365092 91177308-0d34-0410-b5e6-96231b3b80d8
* [PragmaHandler] Expose `#pragma` locationJoel E. Denny2019-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently, a pragma AST node's recorded location starts at the namespace token (such as `omp` in the case of OpenMP) after the `#pragma` token, and the `#pragma` location isn't available. However, the `#pragma` location can be useful when, for example, rewriting a directive using Clang's Rewrite facility. This patch makes `#pragma` locations available in any `PragmaHandler` but it doesn't yet make use of them. This patch also uses the new `struct PragmaIntroducer` to simplify `Preprocessor::HandlePragmaDirective`. It doesn't do the same for `PPCallbacks::PragmaDirective` because that changes the API documented in `clang-tools-extra/docs/pp-trace.rst`, and I'm not sure about backward compatibility guarantees there. Reviewed By: ABataev, lebedev.ri, aaron.ballman Differential Revision: https://reviews.llvm.org/D61643 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@361335 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland "[analyzer] Add an example plugin for checker dependency handling"Kristof Umann2019-05-164-70/+0
| | | | | | | | | | | | Buildbots complained that they couldn't find the newly added plugins. The solution was to move the check-clang cmake target closer to the bottom of the file, after the new dependencies are added. Differential Revision: https://reviews.llvm.org/D59464 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360891 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[analyzer] Add a test for plugins using checker dependencies"Kristof Umann2019-05-154-0/+70
| | | | | | | Buildbots don't seem to find the new plugin. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360805 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] Add a test for plugins using checker dependenciesKristof Umann2019-05-154-70/+0
| | | | | | | | | | | | Also, I moved the existing analyzer plugin to test/ as well, in order not to give the illusion that the analyzer supports plugins -- it's capable of handling them, but does not _support_ them. Differential Revision: https://reviews.llvm.org/D59464 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@360799 91177308-0d34-0410-b5e6-96231b3b80d8
* [build] Rename clang-headers to clang-resource-headersShoaib Meenai2019-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current install-clang-headers target installs clang's resource directory headers. This is different from the install-llvm-headers target, which installs LLVM's API headers. We want to introduce the corresponding target to clang, and the natural name for that new target would be install-clang-headers. Rename the existing target to install-clang-resource-headers to free up the install-clang-headers name for the new target, following the discussion on cfe-dev [1]. I didn't find any bots on zorg referencing install-clang-headers. I'll send out another PSA to cfe-dev to accompany this rename. [1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits Tags: #clang, #sanitizers, #lldb, #openmp, #llvm Differential Revision: https://reviews.llvm.org/D58791 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@355340 91177308-0d34-0410-b5e6-96231b3b80d8
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-194-16/+12
| | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@351636 91177308-0d34-0410-b5e6-96231b3b80d8
* cmake: Remove uses of add_llvm_loadable_module macroTom Stellard2018-12-203-3/+3
| | | | | | This was removed from llvm in r349839. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349840 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix the example checker plugin after r349812.Aaron Ballman2018-12-201-1/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349816 91177308-0d34-0410-b5e6-96231b3b80d8
* Link examples/clang-interpreter against clangSerializationKristof Umann2018-12-151-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349279 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a compilation error in examples/Kristof Umann2018-12-151-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@349278 91177308-0d34-0410-b5e6-96231b3b80d8
* Test commit - delete trailing space.Michael Platings2018-11-191-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@347194 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix buildbots - update clang-interpreter to use Legacy ORC classes ↵Simon Pilgrim2018-10-161-3/+3
| | | | | | introduced in rL344572. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@344598 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix a clang::driver::ArgStringList usage I missed in rL344398. NFCI.Simon Pilgrim2018-10-121-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@344400 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-interpreter: Add missing LLVM component ObjectFangrui Song2018-06-031-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333836 91177308-0d34-0410-b5e6-96231b3b80d8
* Convert clang-interpreter to ORC JIT APIStephane Sezer2018-05-256-506/+84
| | | | | | | | | | | | | | Summary: This mostly re-uses code from the KaleidoscopeJIT example. Reviewers: ddunbar, lhames Reviewed By: lhames Subscribers: mgrang, alexshap, mgorny, xiaobai, cfe-commits Differential Revision: https://reviews.llvm.org/D45897 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333302 91177308-0d34-0410-b5e6-96231b3b80d8
* Test commitKristof Umann2018-05-231-2/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333080 91177308-0d34-0410-b5e6-96231b3b80d8
* This is a test commit.David Carlier2018-05-231-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@333059 91177308-0d34-0410-b5e6-96231b3b80d8
* s/LLVM_ON_WIN32/_WIN32/, clangNico Weber2018-04-271-1/+1
| | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@331069 91177308-0d34-0410-b5e6-96231b3b80d8
* clang-interpreter example cmake fixLuke Cheeseman2018-03-211-1/+1
| | | | | | | | | | Add in a space when appending the export to the linker options. Without the space the export is appended onto whatever the last link option was, which might be a file. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@328092 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Properly quote string arguments to quiet errors from r327528 when builtFrederich Munch2018-03-141-7/+7
| | | | | | with LLVM_ENABLE_EH and LLVM_ENABLE_RTTI. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327531 91177308-0d34-0410-b5e6-96231b3b80d8
* Expand clang-interpreter with example of throwing in and from the JIT for ↵Frederich Munch2018-03-148-49/+621
| | | | | | | | | | | | | | | | | | Windows64. Summary: Getting this to work is not particularly obvious, and having it as an example should be helpful. Portions of this could be placed into LLVM, but as a whole it seems necessary to do this a higher level. Reviewers: lhames, mehdi_amini Reviewed By: lhames Subscribers: mgrang, martell, cfe-commits, mgorny Differential Revision: https://reviews.llvm.org/D35103 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@327528 91177308-0d34-0410-b5e6-96231b3b80d8
* [analyzer] introduce getSVal(Stmt *) helper on ExplodedNode, make sure the ↵George Karpenkov2018-01-171-3/+1
| | | | | | | | | | | | | | | | | | helper is used consistently In most cases using `N->getState()->getSVal(E, N->getLocationContext())` is ugly, verbose, and also opens up more surface area for bugs if an inconsistent location context is used. This patch introduces a helper on an exploded node, and ensures consistent usage of either `ExplodedNode::getSVal` or `CheckContext::getSVal` across the codebase. As a result, a large number of redundant lines is removed. Differential Revision: https://reviews.llvm.org/D42155 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@322753 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Use PRIVATE in target_link_libraries for executablesShoaib Meenai2017-12-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently use target_link_libraries without an explicit scope specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables. Dependencies added in this way apply to both the target and its dependencies, i.e. they become part of the executable's link interface and are transitive. Transitive dependencies generally don't make sense for executables, since you wouldn't normally be linking against an executable. This also causes issues for generating install export files when using LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM library dependencies, which are currently added as interface dependencies. If clang is in the distribution components but the LLVM libraries it depends on aren't (which is a perfectly legitimate use case if the LLVM libraries are being built static and there are therefore no run-time dependencies on them), CMake will complain about the LLVM libraries not being in export set when attempting to generate the install export file for clang. This is reasonable behavior on CMake's part, and the right thing is for LLVM's build system to explicitly use PRIVATE dependencies for executables. Unfortunately, CMake doesn't allow you to mix and match the keyword and non-keyword target_link_libraries signatures for a single target; i.e., if a single call to target_link_libraries for a particular target uses one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must also be updated to use those keywords. This means we must do this change in a single shot. I also fully expect to have missed some instances; I tested by enabling all the projects in the monorepo (except dragonegg), and configuring both with and without shared libraries, on both Darwin and Linux, but I'm planning to rely on the buildbots for other configurations (since it should be pretty easy to fix those). Even after this change, we still have a lot of target_link_libraries calls that don't specify a scope keyword, mostly for shared libraries. I'm thinking about addressing those in a follow-up, but that's a separate change IMO. Differential Revision: https://reviews.llvm.org/D40823 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319840 91177308-0d34-0410-b5e6-96231b3b80d8
* Add LLVMOption to clang-interpreter, corresponding to r291938.NAKAMURA Takumi2017-01-141-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@292007 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase ↵David Blaikie2017-01-061-1/+1
| | | | | | | | | | | | | | and CodeCompleteConsumer" Aleksey Shlypanikov pointed out my mistake in migrating an explicit unique_ptr to auto - I was expecting the function returned a unique_ptr, but instead it returned a raw pointer - introducing a leak. Thanks Aleksey! This reapplies r291184, reverted in r291249. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291270 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "Fix examples for recent shared_ptrification"David Blaikie2017-01-061-1/+1
| | | | | | | | | (should've rolled in to this revert of the CompilerInstance change in the first place... anyway) This reverts commit r291185. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291252 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix examples for recent shared_ptrificationDavid Blaikie2017-01-051-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291185 91177308-0d34-0410-b5e6-96231b3b80d8
* [Examples] Fix use of sema.LateParsedTemplateMap in clang/examples.Justin Lebar2016-10-101-2/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@283778 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply r276973 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-08-052-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277806 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r276973 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-282-2/+2
| | | | | | | | | | registry" Buildbot failures when building with clang -Werror. Reverting while I try to figure this out. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@277008 91177308-0d34-0410-b5e6-96231b3b80d8
* Reapply r276856 "Adjust Registry interface to not require plugins to export ↵John Brawn2016-07-282-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276973 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r276856 "Adjust Registry interface to not require plugins to export a ↵John Brawn2016-07-272-2/+2
| | | | | | | | | registry" This is causing a huge pile of buildbot failures. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276857 91177308-0d34-0410-b5e6-96231b3b80d8
* Adjust Registry interface to not require plugins to export a registryJohn Brawn2016-07-272-2/+2
| | | | | | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@276856 91177308-0d34-0410-b5e6-96231b3b80d8
* Explicitly export symbols from the sample analyzer pluginJohn Brawn2016-07-082-1/+4
| | | | | | | | | | This is done so that it will work when built using MSVC if LLVM_EXPORT_SYMBOLS_FOR_PLUGINS=ON. Differential Revision: http://reviews.llvm.org/D21971 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@274871 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Cleaning up CMake feature gating on 2.8.12Chris Bieneman2016-06-093-3/+3
| | | | | | CMake 2.8.12 introduced interface libraries and some related policies. This removes the conditional block because we're now past 2.8.12. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272312 91177308-0d34-0410-b5e6-96231b3b80d8
* AnnotateFunctions: Tweak for mingw.NAKAMURA Takumi2016-04-041-0/+2
| | | | | | | - Externalize the registry. - Update libdeps. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265301 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a PragmaHandler Registry for plugins to add PragmaHandlers toJohn Brawn2016-04-041-1/+37
| | | | | | | | | | | This allows plugins which add AST passes to also define pragmas to do things like only enable certain behaviour of the AST pass in files where a certain pragma is used. Differential Revision: http://reviews.llvm.org/D18319 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@265295 91177308-0d34-0410-b5e6-96231b3b80d8
* Make it possible for AST plugins to enable themselves by defaultJohn Brawn2016-03-153-0/+62
| | | | | | | | | | | | | Currently when an AST plugin is loaded it must then be enabled by passing -plugin pluginname or -add-plugin pluginname to the -cc1 command line. This patch adds a method to PluginASTAction which allows it to declare that the action happens before, instead of, or after the main AST action, plus the relevant changes to make the plugin action happen at that time automatically. Differential Revision: http://reviews.llvm.org/D17959 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@263546 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r260265, "clang-cl: Support loading plugins on Windows"NAKAMURA Takumi2016-02-111-1/+0
| | | | | | 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
* clang-cl: Support loading plugins on WindowsEhsan Akhgari2016-02-091-0/+1
| | | | | | | | | | | | 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
* Remove autoconf supportChris Bieneman2016-01-264-90/+0
| | | | | | | | | | | | | | | | | 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 git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@258862 91177308-0d34-0410-b5e6-96231b3b80d8
* analyzer-plugin/MainCallChecker.cpp: s/generateSink/generateErrorNode/, ↵NAKAMURA Takumi2015-09-161-1/+1
| | | | | | corresponding to r247859. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@247862 91177308-0d34-0410-b5e6-96231b3b80d8
* Fixing a build bot break from r240400.Aaron Ballman2015-06-231-2/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240401 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240353 91177308-0d34-0410-b5e6-96231b3b80d8
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | | | 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
View Lorry Controller Status