| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 322753
|
|
|
|
|
|
|
|
|
|
| |
Use variadic templates instead of relying on <cstdarg> + sentinel.
This enforces better type checking and makes code more readable.
Differential revision: https://reviews.llvm.org/D32550
llvm-svn: 302572
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains 2 improvements to the CFNumber checker:
- Checking of CFNumberGetValue misuse.
- Treating all CFNumber API misuse errors as non-fatal. (Previously we treated errors that could cause uninitialized memory as syncs and the truncation errors as non-fatal.)
This implements a subset of functionality from https://reviews.llvm.org/D17954.
Differential Revision: https://reviews.llvm.org/D25876
llvm-svn: 285253
|
|
|
|
|
|
|
|
| |
fixes.
Differential revision: http://reviews.llvm.org/D17060
llvm-svn: 260414
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lib/StaticAnalyzer/Checkers
Summary: Use clang-tidy to simplify boolean conditional return values
Reviewers: dcoughlin, krememek
Subscribers: krememek, cfe-commits
Patch by Richard Thomson!
Differential Revision: http://reviews.llvm.org/D10021
llvm-svn: 256491
|
|
|
|
|
|
| |
This is now allowed and has the behavior of removing the mapping.
llvm-svn: 252679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The analyzer trims unnecessary nodes from the exploded graph before reporting
path diagnostics. However, in some cases it can trim all nodes (including the
error node), leading to an assertion failure (see
https://llvm.org/bugs/show_bug.cgi?id=24184).
This commit addresses the issue by adding two new APIs to CheckerContext to
explicitly create error nodes. Unless the client provides a custom tag, these
APIs tag the node with the checker's tag -- preventing it from being trimmed.
The generateErrorNode() method creates a sink error node, while
generateNonFatalErrorNode() creates an error node for a path that should
continue being explored.
The intent is that one of these two methods should be used whenever a checker
creates an error node.
This commit updates the checkers to use these APIs. These APIs
(unlike addTransition() and generateSink()) do not take an explicit Pred node.
This is because there are not any error nodes in the checkers that were created
with an explicit different than the default (the CheckerContext's Pred node).
It also changes generateSink() to require state and pred nodes (previously
these were optional) to reduce confusion.
Additionally, there were several cases where checkers did check whether a
generated node could be null; we now explicitly check for null in these places.
This commit also includes a test case written by Ying Yi as part of
http://reviews.llvm.org/D12163 (that patch originally addressed this issue but
was reverted because it introduced false positive regressions).
Differential Revision: http://reviews.llvm.org/D12780
llvm-svn: 247859
|
|
|
|
| |
llvm-svn: 246978
|
|
|
|
|
|
| |
to the caller instead of hiding it in emitReport. NFC.
llvm-svn: 240400
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Sean McBride, tests adjusted by me.
llvm-svn: 211453
|
|
|
|
| |
llvm-svn: 209642
|
|
|
|
|
|
|
|
|
|
| |
This also includes some infrastructure to make it easier to build multi-argument
selectors, rather than trying to use string matching on each piece. There's a bit
more setup code, but less cost at runtime.
PR18908
llvm-svn: 205827
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
| |
llvm-svn: 202639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/15999214>
llvm-svn: 201007
|
|
|
|
|
|
|
|
| |
raw_ostream, and started using it in places it made sense.
No functional changes intended, just API cleanliness.
llvm-svn: 198428
|
|
|
|
|
|
|
| |
There are about 30 removed in this patch, generated by a new FixIt I haven't
got round to submitting yet.
llvm-svn: 195814
|
|
|
|
|
|
|
|
|
| |
I've added the missing ImutProfileInfo [sic] specialization for bool,
so this patch on r194235 is no longer needed.
This reverts r194244 / 2baea2887dfcf023c8e3560e5d4713c42eed7b6b.
llvm-svn: 194265
|
|
|
|
|
|
|
|
|
| |
ContainerNonEmptyMap with "int" instead of "bool", to appease building since r194235.
In ADT/ImmutableSet, ImutProfileInfo<bool> cannot be matched to ImutProfileInteger.
I didn't have idea it'd the right way if PROFILE_INTEGER_INFO(bool) could be added there.
llvm-svn: 194244
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An Objective-C for-in loop will have zero iterations if the collection is
empty. Previously, we could only detect this case if the program asked for
the collection's -count /before/ the for-in loop. Now, the analyzer
distinguishes for-in loops that had zero iterations from those with at
least one, and can use this information to constrain the result of calling
-count after the loop.
In order to make this actually useful, teach the checker that methods on
NSArray, NSDictionary, and the other immutable collection classes don't
change the count.
<rdar://problem/14992886>
llvm-svn: 194235
|
|
|
|
| |
llvm-svn: 194005
|
|
|
|
|
|
|
|
|
|
|
| |
should be entered
This fixes false positives by allowing us to know that a loop is always entered if
the collection count method returns a positive value and vice versa.
Addresses radar://14169391.
llvm-svn: 184618
|
|
|
|
|
|
| |
(Modifying the checker to record that the values are no longer nil will be done separately.)
llvm-svn: 181744
|
|
|
|
| |
llvm-svn: 181738
|
|
|
|
| |
llvm-svn: 181616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an Objective-C for-in loop "for (id element in collection) {}", the loop
will run 0 times if the collection is nil. This is because the for-in loop
is implemented using a protocol method that returns 0 when there are no
elements to iterate, and messages to nil will result in a 0 return value.
At some point we may want to actually model this message send, but for now
we may as well get the nil case correct, and avoid the false positives that
would come with this case.
<rdar://problem/13744632>
llvm-svn: 180639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the analyzer used isIntegerType() everywhere, which uses the C
definition of "integer". The C++ predicate with the same behavior is
isIntegerOrUnscopedEnumerationType().
However, the analyzer is /really/ using this to ask if it's some sort of
"integrally representable" type, i.e. it should include C++11 scoped
enumerations as well. hasIntegerRepresentation() sounds like the right
predicate, but that includes vectors, which the analyzer represents by its
elements.
This commit audits all uses of isIntegerType() and replaces them with the
general isIntegerOrEnumerationType(), except in some specific cases where
it makes sense to exclude scoped enumerations, or any enumerations. These
cases now use isIntegerOrUnscopedEnumerationType() and getAs<BuiltinType>()
plus BuiltinType::isInteger().
isIntegerType() is hereby banned in the analyzer - lib/StaticAnalysis and
include/clang/StaticAnalysis. :-)
Fixes real assertion failures. PR15703 / <rdar://problem/12350701>
llvm-svn: 179081
|
|
|
|
| |
llvm-svn: 179034
|
|
|
|
| |
llvm-svn: 178935
|
|
|
|
|
|
|
|
|
| |
Register the nil tracking visitors with the region and refactor trackNullOrUndefValue a bit.
Also adds the cast and paren stripping before checking if the value is an OpaqueValueExpr
or ExprWithCleanups.
llvm-svn: 178093
|
|
|
|
|
|
| |
and ensure it works with subscripting.
llvm-svn: 177789
|
|
|
|
| |
llvm-svn: 177318
|
|
|
|
| |
llvm-svn: 176755
|
|
|
|
|
|
|
| |
This is a precursor to making Optional<T>'s operator bool 'explicit' when
building Clang & LLVM as C++11.
llvm-svn: 175722
|
|
|
|
| |
llvm-svn: 175705
|
|
|
|
|
|
| |
Post-commit CR feedback from Jordan Rose regarding r175594.
llvm-svn: 175679
|
|
|
|
| |
llvm-svn: 175678
|
|
|
|
|
|
| |
See r175462 for another example/more details.
llvm-svn: 175594
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 169095
|
|
|
|
|
|
| |
Patch by Sean McBride!
llvm-svn: 167537
|
|
|
|
|
|
| |
Thanks Jordan.
llvm-svn: 167438
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 167275
|
|
|
|
|
|
| |
dispatch.
llvm-svn: 164579
|
|
|
|
| |
llvm-svn: 163505
|
|
|
|
| |
llvm-svn: 162951
|