| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 166625
|
|
|
|
|
|
|
|
|
| |
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Patch by Ed Schouten.
llvm-svn: 166498
|
|
|
|
|
|
|
|
|
|
|
|
| |
since it also has an implicit exception specification. Downgrade the error to
an extwarn, since at least for operator delete, system headers like to declare
it as 'noexcept' whereas the implicit definition does not have an explicit
exception specification. Move the exception specification for user-declared
'operator delete' functions from the type-as-written into the type, to reflect
reality and to allow us to detect whether there was an implicit exception spec
or not.
llvm-svn: 166372
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, unify ObjCShouldCallSuperDealloc and ObjCShouldCallSuperFinalize.
The two have identical behavior and will never be active at the same time.
There's one last simplification now, which is that if we see a call to
[super foo] and we are currently in a method named 'foo', we will
/unconditionally/ clear the ObjCShouldCallSuper flag, rather than check
first to see if we're in a method where calling super is required. There's
no reason to pay the extra lookup price here.
llvm-svn: 166285
|
|
|
|
|
|
|
| |
Only deleted functions may override deleted functions and non-deleted functions
may only override non-deleted functions.
llvm-svn: 166082
|
|
|
|
| |
llvm-svn: 165829
|
|
|
|
|
|
| |
declarations.
llvm-svn: 165826
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When suggesting "foo::bar" as a correction for "fob::bar" we mistakenly
replaced only "bar" with "foo::bar" producing "fob::foo::bar" which was broken.
This corrects that replacement in as many places as I could find & provides
test cases for all those cases I could find a test case for. There are a couple
that don't seem to be reachable (one looks entirely dead, the other just
doesn't seem to ever get called with a namespace to namespace change).
Review by Richard Smith ( http://llvm-reviews.chandlerc.com/D57 ).
llvm-svn: 165817
|
|
|
|
|
|
| |
canonical method; avoid storing them again for an out-of-line definition.
llvm-svn: 165472
|
|
|
|
| |
llvm-svn: 165259
|
|
|
|
| |
llvm-svn: 165256
|
|
|
|
|
|
|
|
| |
For GNU attributes, instead of reusing attribute source
location for the scope location, use SourceLocation() since
GNU attributes don not have scope tokens.
llvm-svn: 165234
|
|
|
|
|
|
|
| |
each one separately, process a stack of MemberExpr's as a single unit so that
static calls and member access will not be warned on.
llvm-svn: 165074
|
|
|
|
|
|
|
|
| |
allowed
for ARC. Fixes <rdar://problem/12407705>
llvm-svn: 164990
|
|
|
|
|
|
|
| |
representation. Fix crash if it appears in the return type of a member function
definition.
llvm-svn: 164967
|
|
|
|
|
|
|
|
|
|
|
| |
-Allow Sema to do more processing on the initial Expr before checking it.
-Remove the special conditions in HandleExpr()
-Move the code so that only one call site is needed.
-Removed the function from Sema and only call it locally.
-Warn on potentially evaluated reference variables, not just casts to r-values.
-Update tests.
llvm-svn: 164951
|
|
|
|
|
|
|
| |
use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.
llvm-svn: 164892
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Patch by Andy Gibbs!
llvm-svn: 164590
|
|
|
|
|
|
|
|
|
|
|
| |
This makes the wording more informative, and consistent with the other
warnings about uninitialized variables.
Also, me and David who reviewed this couldn't figure out why we would
need to do a lookup to get the name of the variable; so just print the
name directly.
llvm-svn: 164366
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is some really old code (took me a while to find the test cases) & the
diagnostic text is slightly incorrect (it should really only apply to
re/declarations/, redefinitions are an error regardless of whether the types
match). Not sure if anyone cares about it, though.
For now this just makes the diagnostic more clear in less obvious cases where
the type of a declaration might not be explicitly written (eg: because it
uses decltype)
llvm-svn: 164313
|
|
|
|
| |
llvm-svn: 164274
|
|
|
|
|
|
|
|
| |
is no compelling argument that this is a generally useful warning,
and imposes a strong stylistic argument on code beyond what it was
intended to find warnings in.
llvm-svn: 164083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically, this should warn:
__block block_t a = ^{ a(); };
Furthermore, this case which previously warned now does not, since the value
of 'b' is captured before the assignment occurs:
block_t b; // not __block
b = ^{ b(); };
(This will of course warn under -Wuninitialized, as before.)
<rdar://problem/11015883>
llvm-svn: 163962
|
|
|
|
|
|
| |
// rdar://10554025
llvm-svn: 163917
|
|
|
|
| |
llvm-svn: 163874
|
|
|
|
|
|
|
|
| |
warning to an error. C++ bans it, and both GCC and EDG diagnose it as
an error. Microsoft allows it, so we still warn in Microsoft
mode. Fixes <rdar://problem/11135644>.
llvm-svn: 163831
|
|
|
|
|
|
| |
super's annotated methods. // rdar://6386358
llvm-svn: 163517
|
|
|
|
|
|
|
|
| |
in classes. Use it to flag those method implementations which don't
contain call to 'super' if they have 'super' class and it has the method
with this attribute set. This is wip. // rdar://6386358
llvm-svn: 163434
|
|
|
|
|
|
| |
// rdar://12233989
llvm-svn: 163338
|
|
|
|
| |
llvm-svn: 163325
|
|
|
|
|
|
| |
don't trample over the caller's LookupResult in the case where the check fails.
llvm-svn: 163281
|
|
|
|
|
|
|
|
| |
of a c-function for what it is. Otherwise, this func
is treated as an overloadable c-function resulting in
a crash much later. // rdar://11743706
llvm-svn: 163224
|
|
|
|
| |
llvm-svn: 163039
|
|
|
|
|
|
| |
instead of aliasing to "struct" which had some incorrect behaviour. Patch by David Robins.
llvm-svn: 163013
|
|
|
|
|
|
|
| |
constructor not user provided (and, therefore, non-trivial). Fixes
<rdar://problem/11736429>.
llvm-svn: 162947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
initiated enum constant has the same value as another enum constant.
For instance:
enum test { A, B, C = -1, D, E = 1 };
Clang will warn that:
A and D both have value 0
B and E both have value 1
A few exceptions are made to keep the noise down. Enum constants which are
initialized to another enum constant, or an enum constant plus or minus 1 will
not trigger this warning. Also, anonymous enums are not checked.
llvm-svn: 162938
|
|
|
|
|
|
|
|
| |
variables without a storage class within a function, to implement
CUDA B.2.5: "__shared__ and __constant__ variables have implied static
storage [duration]."
llvm-svn: 162788
|
|
|
|
|
|
| |
Patch by Timur Iskhodzhanov!
llvm-svn: 162639
|
|
|
|
|
|
|
|
| |
MutableArrayRef.
This required changing all get() calls to data() and using the simpler constructors.
llvm-svn: 162501
|
|
|
|
|
|
|
| |
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
llvm-svn: 162475
|
|
|
|
| |
llvm-svn: 162198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).
This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.
llvm-svn: 162159
|
|
|
|
|
|
|
|
| |
specifier is unsed in a declaration; as it may not make the symbol
local to linkage unit as intended. Suggest using "hidden" visibility
attribute instead. // rdar://7703982
llvm-svn: 162138
|
|
|
|
|
|
|
| |
Initializing a reference with itself, e.g. "int &a = a;" seems like a
very bad idea.
llvm-svn: 162093
|
|
|
|
|
|
|
|
| |
both a waste of time, and prone to crash due to the use of the
error-recovery path in parser. Fixes <rdar://problem/12103608>, which
has been driving me nuts.
llvm-svn: 162081
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function arguments and arguments for variadic functions are of a particular
type which is determined by some other argument to the same function call.
Usecases include:
* MPI library implementations, where these attributes enable checking that
buffer type matches the passed MPI_Datatype;
* for HDF5 library there is a similar usecase as MPI;
* checking types of variadic functions' arguments for functions like
fcntl() and ioctl().
llvm-svn: 162067
|
|
|
|
|
|
| |
an abstract c++ class. // rdar://12095239
llvm-svn: 162052
|