History log of /llvm-project/clang/lib/StaticAnalyzer/Checkers/ObjCUnusedIVarsChecker.cpp (Results 1 – 25 of 32)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# 3d56ea05 18-Apr-2024 Timm Baeder <tbaeder@redhat.com>

[clang][NFC] Fix FieldDecl::isUnnamedBitfield() capitalization (#89048)

We always capitalize bitfield as "BitField".


Revision tags: 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
# 017675ff 13-Feb-2024 Artem Dergachev <adergachev@apple.com>

[attributes][analyzer] Generalize [[clang::suppress]] to declarations. (#80371)

The attribute is now allowed on an assortment of declarations, to
suppress warnings related to declarations themselve

[attributes][analyzer] Generalize [[clang::suppress]] to declarations. (#80371)

The attribute is now allowed on an assortment of declarations, to
suppress warnings related to declarations themselves, or all warnings in
the lexical scope of the declaration.

I don't necessarily see a reason to have a list at all, but it does look
as if some of those more niche items aren't properly supported by the
compiler itself so let's maintain a short safe list for now.

The initial implementation raised a question whether the attribute
should apply to lexical declaration context vs. "actual" declaration
context. I'm using "lexical" here because it results in less warnings
suppressed, which is the conservative behavior: we can always expand it
later if we think this is wrong, without breaking any existing code. I
also think that this is the correct behavior that we will probably never
want to change, given that the user typically desires to keep the
suppressions as localized as possible.

show more ...


Revision tags: 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, 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, 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, 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
# f0bb45fa 11-Sep-2019 Artem Dergachev <artem.dergachev@gmail.com>

[analyzer] NFC: Move PathDiagnostic classes to libAnalysis.

At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece
structures no longer rely on anything specific to Static Ana

[analyzer] NFC: Move PathDiagnostic classes to libAnalysis.

At this point the PathDiagnostic, PathDiagnosticLocation, PathDiagnosticPiece
structures no longer rely on anything specific to Static Analyzer, so we can
move them out of it for everybody to use.

PathDiagnosticConsumers are still to be handed off.

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

llvm-svn: 371661

show more ...


Revision tags: llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# fc76d855 13-Aug-2019 Kristof Umann <dkszelethus@gmail.com>

[analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const

When I'm new to a file/codebase, I personally find C++'s strong static type
system to be a great aid. BugReporter.c

[analyzer][NFC] Refactoring BugReporter.cpp P4.: If it can be const, make it const

When I'm new to a file/codebase, I personally find C++'s strong static type
system to be a great aid. BugReporter.cpp is still painful to read however:
function calls are made with mile long parameter lists, seemingly all of them
taken with a non-const reference/pointer. This patch fixes nothing but this:
make a few things const, and hammer it until it compiles.

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

llvm-svn: 368735

show more ...


Revision tags: 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
# 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 &registry);

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
# f2ceec48 09-Aug-2018 Stephen Kelly <steveire@gmail.com>

Port getLocStart -> getBeginLoc

Reviewers: teemperor!

Subscribers: jholewinski, whisperity, jfb, cfe-commits

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

llvm-svn: 339385


Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, 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, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, 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
# 973431b2 03-Jul-2015 Benjamin Kramer <benny.kra@googlemail.com>

Rewrite users of Stmt::child_begin/end into for-range loops.

No functionality change intended.

llvm-svn: 241355


Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, 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, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1
# d85eff49 14-Mar-2014 Aaron Ballman <aaron@aaronballman.com>

[C++11] Replacing ObjCCategoryDecl iterators propimpl_begin() and propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.

llvm-sv

[C++11] Replacing ObjCCategoryDecl iterators propimpl_begin() and propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203930

show more ...


# 3fe486a3 13-Mar-2014 Aaron Ballman <aaron@aaronballman.com>

[C++11] Replacing ObjCInterfaceDecl iterators visible_categories_begin() and visible_categories_end() with iterator_range visible_categories(). Updating all of the usages of the iterators with range-

[C++11] Replacing ObjCInterfaceDecl iterators visible_categories_begin() and visible_categories_end() with iterator_range visible_categories(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203851

show more ...


# 59abbd4d 13-Mar-2014 Aaron Ballman <aaron@aaronballman.com>

[C++11] Replacing ObjCInterfaceDecl iterators ivar_begin() and ivar_end() with iterator_range ivars(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203849


# f26acce6 13-Mar-2014 Aaron Ballman <aaron@aaronballman.com>

[C++11] Replacing ObjCContainerDecl iterators instmeth_begin() and instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.

llvm

[C++11] Replacing ObjCContainerDecl iterators instmeth_begin() and instmeth_end() with iterator_range instance_methods(). Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203839

show more ...


# 629afaef 07-Mar-2014 Aaron Ballman <aaron@aaronballman.com>

[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators wit

[C++11] Replacing DeclBase iterators decls_begin() and decls_end() with iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.

llvm-svn: 203278

show more ...


# 4aca9b1c 11-Feb-2014 Alexander Kornienko <alexfh@google.com>

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and C

Expose the name of the checker producing each diagnostic message.

Summary:
In clang-tidy we'd like to know the name of the checker producing each
diagnostic message. PathDiagnostic has BugType and Category fields, which are
both arbitrary human-readable strings, but we need to know the exact name of the
checker in the form that can be used in the CheckersControlList option to
enable/disable the specific checker.

This patch adds the CheckName field to the CheckerBase class, and sets it in
the CheckerManager::registerChecker() method, which gets them from the
CheckerRegistry.

Checkers that implement multiple checks have to store the names of each check
in the respective registerXXXChecker method.

Reviewers: jordan_rose, krememek

Reviewed By: jordan_rose

CC: cfe-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2557

llvm-svn: 201186

show more ...


Revision tags: llvmorg-3.4.0
# 9ead1243 19-Dec-2013 Aaron Ballman <aaron@aaronballman.com>

Replacing calls to getAttr with calls to hasAttr for clarity. No functional change intended -- this only replaces Boolean uses of getAttr.

llvm-svn: 197648


Revision tags: llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1, llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2, llvmorg-3.3.0-rc1
# 048fbfa3 16-Jan-2013 Douglas Gregor <dgregor@apple.com>

Rework the traversal of Objective-C categories and extensions to
consider (sub)module visibility.

The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C catego

Rework the traversal of Objective-C categories and extensions to
consider (sub)module visibility.

The bulk of this change replaces myriad hand-rolled loops over the
linked list of Objective-C categories/extensions attached to an
interface declaration with loops using one of the four new category
iterator kinds:

visible_categories_iterator: Iterates over all visible categories
and extensions, hiding any that have their "hidden" bit set. This is
by far the most commonly used iterator.

known_categories_iterator: Iterates over all categories and
extensions, ignoring the "hidden" bit. This tends to be used for
redeclaration-like traversals.

visible_extensions_iterator: Iterates over all visible extensions,
hiding any that have their "hidden" bit set.

known_extensions_iterator: Iterates over all extensions, whether
they are visible to normal name lookup or not.

The effect of this change is that any uses of the visible_ iterators
will respect module-import visibility. See the new tests for examples.

Note that the old accessors for categories and extensions are gone;
there are *Raw() forms for some of them, for those (few) areas of the
compiler that have to manipulate the linked list of categories
directly. This is generally discouraged.

Part two of <rdar://problem/10634711>.


llvm-svn: 172665

show more ...


Revision tags: llvmorg-3.2.0, llvmorg-3.2.0-rc3
# 3a02247d 04-Dec-2012 Chandler Carruth <chandlerc@gmail.com>

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/util

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

show more ...


# ea70eb30 01-Dec-2012 Benjamin Kramer <benny.kra@googlemail.com>

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.

Pull the Attr iteration parts out of Attr.h, so including DeclBase.h doesn't pull in all the generated Attr code.

Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.

llvm-svn: 169092

show more ...


Revision tags: llvmorg-3.2.0-rc2, llvmorg-3.2.0-rc1
# 40ed2973 06-Jun-2012 David Blaikie <dblaikie@gmail.com>

Revert Decl's iterators back to pointer value_type rather than reference value_type

In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I w

Revert Decl's iterators back to pointer value_type rather than reference value_type

In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.

This rolls back r155808 and r155869.

Review by Doug Gregor incorporating feedback from Chandler Carruth.

llvm-svn: 158104

show more ...


# 58d986c8 15-May-2012 Anna Zaks <ganna@apple.com>

[analyzer] Fix a regression in ObjCUnusedIVars checker.

We can no longer rely on children iterator to visit all the AST
tree children of an expression (OpaqueValueExpr has no children).

llvm-svn: 1

[analyzer] Fix a regression in ObjCUnusedIVars checker.

We can no longer rely on children iterator to visit all the AST
tree children of an expression (OpaqueValueExpr has no children).

llvm-svn: 156870

show more ...


Revision tags: llvmorg-3.1.0, llvmorg-3.1.0-rc3, llvmorg-3.1.0-rc2
# 2d7c57ec 30-Apr-2012 David Blaikie <dblaikie@gmail.com>

Remove the ref/value inconsistency in filter_decl_iterator.

filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior in

Remove the ref/value inconsistency in filter_decl_iterator.

filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.

This change errs on the side of value, making op-> return T* and op* return
T&.

(reviewed by Richard Smith)

llvm-svn: 155808

show more ...


Revision tags: llvmorg-3.1.0-rc1
# 5a10f08b 04-Apr-2012 Ted Kremenek <kremenek@apple.com>

Include the "issue context" (e.g. function or method) where a static analyzer issue occurred in the plist output.

Fixes <rdar://problem/11004527>

llvm-svn: 154030


12