| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
Patch by chris.wailes@gmail.com. The following functionality was added:
* The same functionality is now supported for both CXXOperatorCallExprs and CXXMemberCallExprs.
* Factored out some code in StmtVisitor.
* Removed variables from the state map when their destructors are encountered.
* Started adding documentation for the consumed analysis attributes.
llvm-svn: 189059
|
|
|
|
|
|
| |
in comments. [-Wdocumentation]
llvm-svn: 188248
|
|
|
|
|
|
|
|
|
| |
This moves a header-only class from Sema to Analysis and puts the option
check in Sema.
Patch by Chris Wailes!
llvm-svn: 188230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewed by delesley, dblaikie.
Add the annotations and code needed to support a basic 'consumed' analysis.
Summary:
This new analysis is based on academic literature on linear types. It tracks
the state of a value, either as unconsumed, consumed, or unknown. Methods are
then annotated as CallableWhenUnconsumed, and when an annotated method is
called while the value is in the 'consumed' state a warning is issued. A value
may be tested in the conditional statement of an if-statement; when this occurs
we know the state of the value in the different branches, and this information
is added to our analysis. The code is still highly experimental, and the names
of annotations or the algorithm may be subject to change.
llvm-svn: 188206
|
|
|
|
| |
llvm-svn: 185264
|
|
|
|
|
|
| |
Fixes -Werror bootstrap.
llvm-svn: 185023
|
|
|
|
|
|
| |
These checks are enabled with the -Wthread-safety-beta flag.
llvm-svn: 179046
|
|
|
|
|
|
| |
case when [[clang::fallthrough]]; is used in a method of a local class.
llvm-svn: 178543
|
|
|
|
|
|
| |
These all appear in comments or (ironically) diagnostics output.
llvm-svn: 176383
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use Optional<CFG*> where invalid states were needed previously. In the one case
where that's not possible (beginAutomaticObjDtorsInsert) just use a dummy
CFGAutomaticObjDtor.
Thanks for the help from Jordan Rose & discussion/feedback from Ted Kremenek
and Doug Gregor.
Post commit code review feedback on r175796 by Ted Kremenek.
llvm-svn: 175938
|
|
|
|
|
|
| |
See r175462 for another example/more details.
llvm-svn: 175796
|
|
|
|
| |
llvm-svn: 175289
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unreachable code" was issued incorrectly.
Summary:
-Wimplicit-fallthrough: fixed two cases where "fallthrough annotation in unreachable code" was issued incorrectly:
1. In actual unreachable code, but not immediately on a fall-through execution
path "fallthrough annotation does not directly precede switch label" is better;
2. After default: in a switch with covered enum cases. Actually, these shouldn't
be treated as unreachable code for our purpose.
Reviewers: rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D374
llvm-svn: 174575
|
|
|
|
| |
llvm-svn: 174182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
A motivating example:
class ClassWithDtor {
public:
~ClassWithDtor() {}
};
void fallthrough3(int n) {
switch (n) {
case 2:
do {
ClassWithDtor temp;
return;
} while (0); // This generates a chain of unreachable CFG blocks.
case 3:
break;
}
}
Reviewers: rsmith, doug.gregor, alexfh
Reviewed By: alexfh
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D330
llvm-svn: 173889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
normal label.
Summary:
It's unlikely that a fallthrough is unintended in the following code:
switch (n) {
...
label:
case 1:
...
goto label;
...
}
Reviewers: rsmith, doug.gregor
Reviewed By: doug.gregor
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D329
llvm-svn: 173486
|
|
|
|
|
|
| |
multiple case labels.
llvm-svn: 173458
|
|
|
|
|
|
|
|
| |
it apart from [[gnu::noreturn]] / __attribute__((noreturn)), since their
semantics are not equivalent (for instance, we treat [[gnu::noreturn]] as
affecting the function type, whereas [[noreturn]] does not).
llvm-svn: 172691
|
|
|
|
|
|
| |
brought into 'clang' namespace by clang/Basic/LLVM.h
llvm-svn: 172323
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
|
|
|
|
|
| |
with -Werror. Previously, compiling with -Werror would emit only the first
warning in a compilation unit, because clang assumes that once an error occurs,
further analysis is unlikely to return valid results. However, warnings that
have been upgraded to errors should not be treated as "errors" in this sense.
llvm-svn: 169649
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the analysis improves, it will continue to add new warnings that are
potentially disruptive to existing users. From now on, such warnings will
first be introduced under the "beta" flag. Such warnings are not turned on by
default; their purpose is to allow users to test their code against future
planned changes, before those changes are actually made. After a suitable
migration period, beta warnings will be folded into the standard
-Wthread-safety.
llvm-svn: 169338
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on C, but also include dialects of C++ earlier than C++11.
There was enough consensus that we *can* get a good language solution
to have an annotation outside of C++11, and without this annotation
this warning doesn't quite mean's completeness criteria for this
kind of warning. For now, restrict this warning to C++11 (where an
annotation exists), and make this the behavior for the LLVM 3.2 release.
Afterwards, we will hammer out a language solution that we are all
happy with.
llvm-svn: 167749
|
|
|
|
|
|
| |
discussion on cfe-dev.
llvm-svn: 167662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rationale is that there is no good workflow to silence the warning
for specific cases, other than using pragmas. This is because the
attribute to decorate an explicit fall through is only available
in C++11.
By that argument, this should probably also be disabled unless one
is using C++11, but apparently there is an explicit test case for
this warning when using C++98. This will require further discussion
on cfe-commits.
Fixes: <rdar://problem/12584746>
llvm-svn: 167655
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the warning would erroneously fire on this:
for (Test *a in someArray)
use(a.weakProp);
...because it looks like the same property is being accessed over and over.
However, clearly this is not the case. We now ignore loops like this for
local variables, but continue to warn if the base object is a parameter,
global variable, or instance variable, on the assumption that these are
not repeatedly usually assigned to within loops.
Additionally, do-while loops where the condition is 'false' are not really
loops at all; usually they're just used for semicolon-swallowing macros or
using "break" like "goto".
<rdar://problem/12578785&12578849>
llvm-svn: 166942
|
|
|
|
|
|
|
|
|
|
| |
This is a "safe" pattern, or at least one that cannot be helped by using
a strong local variable. However, if the single read is within a loop,
it should /always/ be treated as potentially dangerous.
<rdar://problem/12437490>
llvm-svn: 165719
|
|
|
|
| |
llvm-svn: 165383
|
|
|
|
|
|
|
| |
use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.
llvm-svn: 164892
|
|
|
|
|
|
|
| |
No need to specialize BeforeThanCompare for a comparator that's only
going to be used once.
llvm-svn: 164859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When issuing a diagnostic message for the -Wimplicit-fallthrough diagnostics, always try to find the latest macro, defined at the point of fallthrough, which is immediately expanded to "[[clang::fallthrough]]", and use it's name instead of the actual sequence.
Known issues:
* uses PP.getSpelling() to compare macro definition with a string (anyone can suggest a convenient way to fill a token array, or maybe lex it in runtime?);
* this can be generalized and used in other similar cases, any ideas where it should reside then?
Reviewers: doug.gregor, rsmith
Reviewed By: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D50
llvm-svn: 164858
|
|
|
|
|
|
|
|
|
|
| |
Like properties, loading from a weak ivar twice in the same function can
give you inconsistent results if the object is deallocated between the
two loads. It is safer to assign to a strong local variable and use that.
Second half of <rdar://problem/12280249>.
llvm-svn: 164855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivating example:
if (self.weakProp)
use(self.weakProp);
As with any non-atomic test-then-use, it is possible a weak property to be
non-nil at the 'if', but be deallocated by the time it is used. The correct
way to write this example is as follows:
id tmp = self.weakProp;
if (tmp)
use(tmp);
The warning is controlled by -Warc-repeated-use-of-receiver, and uses the
property name and base to determine if the same property on the same object
is being accessed multiple times. In cases where the base is more
complicated than just a single Decl (e.g. 'foo.bar.weakProp'), it picks a
Decl for some degree of uniquing and reports the problem under a subflag,
-Warc-maybe-repeated-use-of-receiver. This gives a way to tune the
aggressiveness of the warning for a particular project.
The warning is not on by default because it is not flow-sensitive and thus
may have a higher-than-acceptable rate of false positives, though it is
less noisy than -Wreceiver-is-weak. On the other hand, it will not warn
about some cases that may be legitimate issues that -Wreceiver-is-weak
will catch, and it does not attempt to reason about methods returning weak
values.
Even though this is not a real "analysis-based" check I've put the bug
emission code in AnalysisBasedWarnings for two reasons: (1) to run on
every kind of code body (function, method, block, or lambda), and (2) to
suggest that it may be enhanced by flow-sensitive analysis in the future.
The second (smaller) half of this work is to extend it to weak locals
and weak ivars. This should use most of the same infrastructure.
Part of <rdar://problem/12280249>
llvm-svn: 164854
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164766
llvm-svn: 164769
|
|
|
|
| |
llvm-svn: 164766
|
|
|
|
|
|
|
| |
LOCKS_EXCLUDED is used on a method with a name that is is not a simple
identifier.
llvm-svn: 164242
|
|
|
|
|
|
|
|
|
| |
analysis that may give false positives because it is confused by aliasing, and
a less precise analysis that has fewer false positives, but may have false
negatives. The more precise warnings are enabled by -Wthread-safety-precise.
An additional note clarify the warnings in the precise case.
llvm-svn: 163537
|
|
|
|
|
|
| |
...and hopefully unbreak buildbots. My apologies!
llvm-svn: 163267
|
|
|
|
| |
llvm-svn: 162210
|
|
|
|
|
|
|
| |
* Treat compound assignment as a use, at Jordy's request.
* Always add compound assignments into the CFG, so we can correctly diagnose the use in 'return x += 1;'
llvm-svn: 160334
|
|
|
|
|
|
| |
locks_required function.
llvm-svn: 159607
|
|
|
|
| |
llvm-svn: 158545
|
|
|
|
| |
llvm-svn: 158325
|
|
|
|
|
|
| |
diagnostics: -Wimplicit-fallthrough-per-method
llvm-svn: 157871
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-Wsometimes-uninitialized diagnostics to make it clearer that the cause
of the issue may be a condition which must always evaluate to true or
false, rather than an uninitialized variable.
To emphasize this, add a new note with a fixit which removes the
impossible condition or replaces it with a constant.
Also, downgrade the diagnostic from -Wsometimes-uninitialized to
-Wconditional-uninitialized when it applies to a range-based for loop,
since the condition is not written explicitly in the code in that case.
llvm-svn: 157511
|
|
|
|
|
|
| |
switch label immediately followed by a 'break;'.
llvm-svn: 157508
|
|
|
|
|
|
|
|
|
|
|
| |
-Wsometimes-uninitialized. This detects cases where an explicitly-written branch
inevitably leads to an uninitialized variable use (so either the branch is dead
code or there is an uninitialized use bug).
This chunk of warnings tentatively lives within -Wuninitialized, in order to
give it more visibility to existing Clang users.
llvm-svn: 157458
|
|
|
|
|
|
| |
functional change.
llvm-svn: 157440
|
|
|
|
|
|
| |
-Wconditional-uninitialized into -Wuninitialized.
llvm-svn: 156512
|