summaryrefslogtreecommitdiffstats
path: root/clang-tools-extra/clang-tidy-vs/ClangTidy
Commit message (Collapse)AuthorAgeFilesLines
* Remove clang-tidy-vs from clang-tools-extra (PR41791)Alex Lorenz2019-08-2732-3396/+0
| | | | | | | | | | | | | | | | | | | | | | The clang-tidy-vs visual studio plugin in clang-tools-extra contains a security vulnerability in the YamlDotNet package [1]. I posted to cfe-dev [2], asking if there was anyone who was interested in updating the the plugin to address the vulnerability. Reid mentioned that Zach (the original committer), said that there's another plugin (Clang Power Tools) that provides clang-tidy support, with additional extra features, so it would be ok to remove clang-tidy-vs. This commit removes the plugin to address the security vulnerability, and adds a section to the release notes that mentions that the plugin was removed, and suggests to use Clang Power Tools. Fixes PR 41791. [1]: https://nvd.nist.gov/vuln/detail/CVE-2018-1000210 [2]: http://lists.llvm.org/pipermail/cfe-dev/2019-August/063196.html Differential Revision: https://reviews.llvm.org/D66813 llvm-svn: 370096
* Fix typos throughout the license files that somehow I and my reviewersChandler Carruth2019-01-211-1/+1
| | | | | | | | | | | all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-192-8/+6
| | | | | | | | | | | | | | | | | 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
* Update some code used in our visual studio plugins to use linux fileChandler Carruth2019-01-193-265/+265
| | | | | | | | endings. We already used them in some cases, and this makes things consistent. This will also simplify updating the licenses in these files. llvm-svn: 351632
* Install new LLVM license structure and new developer policy.Chandler Carruth2019-01-191-21/+236
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 llvm-svn: 351631
* Update copyright year to 2018.Paul Robinson2018-06-181-1/+1
| | | | llvm-svn: 334936
* [clang-tidy] Remove google-runtime-member-string-referencesBenjamin Kramer2018-04-051-4/+0
| | | | | | | | | | This is triggering on a pattern that's both too broad (const std::string& members can be used safely) and too narrow (std::string is not the only class with this problem). It has a very low true positive rate, just remove it until we find a better solution for dangling string references. llvm-svn: 329292
* Remove 'misc-pointer-and-integral-operation' clang-tidy check. The only casesRichard Smith2016-10-211-4/+0
| | | | | | | it detects are ill-formed (some per C++ core issue 1512, others always have been). llvm-svn: 284888
* Make building the clang-tidy VS extension less spammy.Zachary Turner2016-10-041-1/+1
| | | | | | | | The package that strong name signs the 3rd party references spams a ton of output to the log, making the build really ugly. Make this quiet. llvm-svn: 283261
* Fix a few oversights in the clang-tidy VS plugin.Zachary Turner2016-09-074-9/+2
| | | | | | | Over-zealous cleanup of using statements removed some that were actually needed. Also cleaned up a few warnings. llvm-svn: 280844
* Add a clang-tidy visual studio extension.Zachary Turner2016-09-0732-0/+3198
For now this only adds the UI necessary to configure clang-tidy settings graphically, and it enables reading in and saving out of .clang-tidy files. It does not actually run clang-tidy on any source files yet. Differential Revision: https://reviews.llvm.org/D23848 llvm-svn: 280840
OpenPOWER on IntegriCloud