Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3 |
|
#
6f31908d |
| 21-Aug-2023 |
Kazu Hirata <kazu@google.com> |
[StaticAnalyzer] Modernize InvalidationInfo (NFC)
|
Revision tags: llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
5c23e27b |
| 05-Jul-2023 |
Balazs Benics <benicsbalazs@gmail.com> |
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer
I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradu
[analyzer][NFC] Move away from using raw-for loops inside StaticAnalyzer
I'm involved with the Static Analyzer for the most part. I think we should embrace newer language standard features and gradually move forward.
Differential Revision: https://reviews.llvm.org/D154325
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2 |
|
#
371883f4 |
| 03-Oct-2022 |
Argyrios Kyrtzidis <kyrtzidis@apple.com> |
[clang/Sema] Fix non-deterministic order for certain kind of diagnostics
In the context of caching clang invocations it is important to emit diagnostics in deterministic order; the same clang invoca
[clang/Sema] Fix non-deterministic order for certain kind of diagnostics
In the context of caching clang invocations it is important to emit diagnostics in deterministic order; the same clang invocation should result in the same diagnostic output.
rdar://100336989
Differential Revision: https://reviews.llvm.org/D135118
show more ...
|
Revision tags: llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
5114db93 |
| 10-Apr-2022 |
Vince Bridgers <vince.a.bridgers@gmail.com> |
[analyzer] Clean checker options from bool to DefaultBool (NFC)
A recent review emphasized the preference to use DefaultBool instead of bool for checker options. This change is a NFC and cleans up s
[analyzer] Clean checker options from bool to DefaultBool (NFC)
A recent review emphasized the preference to use DefaultBool instead of bool for checker options. This change is a NFC and cleans up some of the instances where bool was used, and could be changed to DefaultBool.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D123464
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
bda3dd0d |
| 27-Mar-2020 |
Kirstóf Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patc
[analyzer][NFC] Change LangOptions to CheckerManager in the shouldRegister* functions
Some checkers may not only depend on language options but also analyzer options. To make this possible this patch changes the parameter of the shouldRegister* function to CheckerManager to be able to query the analyzer options when deciding whether the checker should be registered.
Differential Revision: https://reviews.llvm.org/D75271
show more ...
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5 |
|
#
72649423 |
| 12-Sep-2019 |
Kristof Umann <kristof.umann@ericsson.com> |
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, a
[analyzer][NFC] Fix inconsistent references to checkers as "checks"
Traditionally, clang-tidy uses the term check, and the analyzer uses checker, but in the very early years, this wasn't the case, and code originating from the early 2010's still incorrectly refer to checkers as checks.
This patch attempts to hunt down most of these, aiming to refer to checkers as checkers, but preserve references to callback functions (like checkPreCall) as checks.
Differential Revision: https://reviews.llvm.org/D67140
llvm-svn: 371760
show more ...
|
Revision tags: llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2 |
|
#
204bf2bb |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution i
[analyzer] Add CheckerManager::getChecker, make sure that a registry function registers no more than 1 checker
This patch effectively fixes the almost decade old checker naming issue. The solution is to assert when CheckerManager::getChecker is called on an unregistered checker, and assert when CheckerManager::registerChecker is called on a checker that is already registered.
Differential Revision: https://reviews.llvm.org/D55429
llvm-svn: 352292
show more ...
|
#
8fd74ebf |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep wi
[analyzer] Reimplement dependencies between checkers
Unfortunately, up until now, the fact that certain checkers depended on one another was known, but how these actually unfolded was hidden deep within the implementation. For example, many checkers (like RetainCount, Malloc or CString) modelled a certain functionality, and exposed certain reportable bug types to the user. For example, while MallocChecker models many many different types of memory handling, the actual "unix.MallocChecker" checker the user was exposed to was merely and option to this modeling part.
Other than this being an ugly mess, this issue made resolving the checker naming issue almost impossible. (The checker naming issue being that if a checker registered more than one checker within its registry function, both checker object recieved the same name) Also, if the user explicitly disabled a checker that was a dependency of another that _was_ explicitly enabled, it implicitly, without "telling" the user, reenabled it.
Clearly, changing this to a well structured, declarative form, where the handling of dependencies are done on a higher level is very much preferred.
This patch, among the detailed things later, makes checkers declare their dependencies within the TableGen file Checkers.td, and exposes the same functionality to plugins and statically linked non-generated checkers through CheckerRegistry::addDependency. CheckerRegistry now resolves these dependencies, makes sure that checkers are added to CheckerManager in the correct order, and makes sure that if a dependency is disabled, so will be every checker that depends on it.
In detail:
* Add a new field to the Checker class in CheckerBase.td called Dependencies, which is a list of Checkers. * Move unix checkers before cplusplus, as there is no forward declaration in tblgen :/ * Add the following new checkers: - StackAddrEscapeBase - StackAddrEscapeBase - CStringModeling - DynamicMemoryModeling (base of the MallocChecker family) - IteratorModeling (base of the IteratorChecker family) - ValistBase - SecuritySyntaxChecker (base of bcmp, bcopy, etc...) - NSOrCFErrorDerefChecker (base of NSErrorChecker and CFErrorChecker) - IvarInvalidationModeling (base of IvarInvalidation checker family) - RetainCountBase (base of RetainCount and OSObjectRetainCount) * Clear up and registry functions in MallocChecker, happily remove old FIXMEs. * Add a new addDependency function to CheckerRegistry. * Neatly format RUN lines in files I looked at while debugging.
Big thanks to Artem Degrachev for all the guidance through this project!
Differential Revision: https://reviews.llvm.org/D54438
llvm-svn: 352287
show more ...
|
#
058a7a45 |
| 26-Jan-2019 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. T
[analyzer] Supply all checkers with a shouldRegister function
Introduce the boolean ento::shouldRegister##CHECKERNAME(const LangOptions &LO) function very similarly to ento::register##CHECKERNAME. This will force every checker to implement this function, but maybe it isn't that bad: I saw a lot of ObjC or C++ specific checkers that should probably not register themselves based on some LangOptions (mine too), but they do anyways.
A big benefit of this is that all registry functions now register their checker, once it is called, registration is guaranteed.
This patch is a part of a greater effort to reinvent checker registration, more info here: D54438#1315953
Differential Revision: https://reviews.llvm.org/D55424
llvm-svn: 352277
show more ...
|
Revision tags: llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
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 ne
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
show more ...
|
#
76a21502 |
| 15-Dec-2018 |
Kristof Umann <dkszelethus@gmail.com> |
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed
[analyzer][NFC] Move CheckerRegistry from the Core directory to Frontend
ClangCheckerRegistry is a very non-obvious, poorly documented, weird concept. It derives from CheckerRegistry, and is placed in lib/StaticAnalyzer/Frontend, whereas it's base is located in lib/StaticAnalyzer/Core. It was, from what I can imagine, used to circumvent the problem that the registry functions of the checkers are located in the clangStaticAnalyzerCheckers library, but that library depends on clangStaticAnalyzerCore. However, clangStaticAnalyzerFrontend depends on both of those libraries.
One can make the observation however, that CheckerRegistry has no place in Core, it isn't used there at all! The only place where it is used is Frontend, which is where it ultimately belongs.
This move implies that since include/clang/StaticAnalyzer/Checkers/ClangCheckers.h only contained a single function:
class CheckerRegistry;
void registerBuiltinCheckers(CheckerRegistry ®istry);
it had to re purposed, as CheckerRegistry is no longer available to clangStaticAnalyzerCheckers. It was renamed to BuiltinCheckerRegistration.h, which actually describes it a lot better -- it does not contain the registration functions for checkers, but only those generated by the tblgen files.
Differential Revision: https://reviews.llvm.org/D54436
llvm-svn: 349275
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1 |
|
#
2a8c18d9 |
| 06-Apr-2018 |
Alexander Kornienko <alexfh@google.com> |
Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of:
archtype cas classs checkk compres definit frome iff inteval ith lod metho
Fix typos in clang
Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of:
archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
show more ...
|
Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0 |
|
#
00f70bd9 |
| 01-Mar-2018 |
George Burgess IV <george.burgess.iv@gmail.com> |
Remove redundant casts. NFC
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in
Remove redundant casts. NFC
So I wrote a clang-tidy check to lint out redundant `isa`, `cast`, and `dyn_cast`s for fun. This is a portion of what it found for clang; I plan to do similar cleanups in LLVM and other subprojects when I find time.
Because of the volume of changes, I explicitly avoided making any change that wasn't highly local and obviously correct to me (e.g. we still have a number of foo(cast<Bar>(baz)) that I didn't touch, since overloading is a thing and the cast<Bar> did actually change the type -- just up the class hierarchy).
I also tried to leave the types we were cast<>ing to somewhere nearby, in cases where it wasn't locally obvious what we were dealing with before.
llvm-svn: 326416
show more ...
|
Revision tags: llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
#
5ff6747e |
| 11-Apr-2016 |
Benjamin Kramer <benny.kra@googlemail.com> |
Remove redundant conditions of the form (A || (!A && B)) -> (A || B)
Found by cppcheck! PR27286 PR27287 PR27288 PR27289
llvm-svn: 265918
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3 |
|
#
0a4f3f43 |
| 10-Feb-2016 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
Fix some Clang-tidy readability-redundant-control-flow warnings; other minor fixes.
Differential revision: http://reviews.llvm.org/D17060
llvm-svn: 260414
|
Revision tags: llvmorg-3.8.0-rc2 |
|
#
494ee5b0 |
| 28-Jan-2016 |
Manman Ren <manman.ren@gmail.com> |
Class Property: change PropertyMap to include isClassProperty.
PropertyMap used to map IdentifierInfo (name of the property) to ObjcPropertyDecl *. Now that a class property can have the same name a
Class Property: change PropertyMap to include isClassProperty.
PropertyMap used to map IdentifierInfo (name of the property) to ObjcPropertyDecl *. Now that a class property can have the same name as an instance property, we change PropertyMap to map a pair <IdentifierInfo *, unsigned> to ObjcPropertyDecl *.
Also update a few places from iterating over instance_properties to iterating over all properties.
rdar://23891898
llvm-svn: 259119
show more ...
|
Revision tags: llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
#
3a0678e3 |
| 08-Sep-2015 |
Ted Kremenek <kremenek@apple.com> |
[analyzer] Apply whitespace cleanups by Honggyu Kim.
llvm-svn: 246978
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1 |
|
#
642f173a |
| 02-Jul-2015 |
Benjamin Kramer <benny.kra@googlemail.com> |
Switch users of the 'for (StmtRange range = stmt->children(); range; ++range)‘ pattern to range for loops.
The pattern was born out of the lack of range-based for loops in C++98 and is somewhat obsc
Switch users of the 'for (StmtRange range = stmt->children(); range; ++range)‘ pattern to range for loops.
The pattern was born out of the lack of range-based for loops in C++98 and is somewhat obscure. No functionality change intended.
llvm-svn: 241300
show more ...
|
Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1 |
|
#
ab9db510 |
| 22-Jun-2015 |
Alexander Kornienko <alexfh@google.com> |
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").
llvm-svn: 240353
|
#
3d9d929e |
| 22-Jun-2015 |
Alexander Kornienko <alexfh@google.com> |
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-comme
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
show more ...
|
Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
#
92e1b62d |
| 18-Mar-2015 |
Yaron Keren <yaron.keren@gmail.com> |
Remove many superfluous SmallString::str() calls.
Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there a
Remove many superfluous SmallString::str() calls.
Now that SmallString is a first-class citizen, most SmallString::str() calls are not required. This patch removes a whole bunch of them, yet there are lots more.
There are two use cases where str() is really needed: 1) To use one of StringRef member functions which is not available in SmallString. 2) To convert to std::string, as StringRef implicitly converts while SmallString do not. We may wish to change this, but it may introduce ambiguity.
llvm-svn: 232622
show more ...
|
Revision tags: llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
#
0dbb783c |
| 27-May-2014 |
Craig Topper <craig.topper@gmail.com> |
[C++11] Use 'nullptr'. StaticAnalyzer edition.
llvm-svn: 209642
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
#
0f6e64d5 |
| 13-Mar-2014 |
Aaron Ballman <aaron@aaronballman.com> |
[C++11] Replacing ObjCProtocolDecl iterators protocol_begin() and protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 20
[C++11] Replacing ObjCProtocolDecl iterators protocol_begin() and protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203863
show more ...
|
#
f53d8dd3 |
| 13-Mar-2014 |
Aaron Ballman <aaron@aaronballman.com> |
[C++11] Replacing ObjCInterfaceDecl iterators visible_extensions_begin() and visible_extensions_end() with iterator_range visible_extensions(). Updating all of the usages of the iterators with range-
[C++11] Replacing ObjCInterfaceDecl iterators visible_extensions_begin() and visible_extensions_end() with iterator_range visible_extensions(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203855
show more ...
|
#
a49c5064 |
| 13-Mar-2014 |
Aaron Ballman <aaron@aaronballman.com> |
[C++11] Replacing ObjCInterfaceDecl iterators protocol_begin() and protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
Drive-by fi
[C++11] Replacing ObjCInterfaceDecl iterators protocol_begin() and protocol_end() with iterator_range protocols(). Updating all of the usages of the iterators with range-based for loops.
Drive-by fixing some incorrect types where a for loop would be improperly using ObjCInterfaceDecl::protocol_iterator. No functional changes in these cases.
llvm-svn: 203842
show more ...
|