variable. Previously we didn't notice the type was dependent if the only
dependence came from an array bound.
Patch by Brian Brooks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167642 91177308-0d34-0410-b5e6-96231b3b80d8
The problem is as follows: C++11 has contexts which are not
potentially-evaluated, and yet in which we are required or encouraged to
perform constant evaluation. In such contexts, we are not permitted to
implicitly define special member functions for literal types, therefore
we cannot evalaute those constant expressions.
Punt on this in one more context for now by skipping checking constexpr
variable initializers if they occur in dependent contexts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166956 91177308-0d34-0410-b5e6-96231b3b80d8
whether the initializer is value-dependent rather than whether we are in a
dependent context. This allows us to detect some errors sooner, and fixes a
crash-on-invalid if a dependent type leaks out to a non-dependent context in
error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166898 91177308-0d34-0410-b5e6-96231b3b80d8
might have been used in constant expressions, rather than suppressing it for
variables which are const. The important thing here is that such variables
can have their values used without actually being marked as 'used'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166896 91177308-0d34-0410-b5e6-96231b3b80d8
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Patch by Ed Schouten.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166498 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166372 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166285 91177308-0d34-0410-b5e6-96231b3b80d8
Only deleted functions may override deleted functions and non-deleted functions
may only override non-deleted functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166082 91177308-0d34-0410-b5e6-96231b3b80d8
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 ).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165817 91177308-0d34-0410-b5e6-96231b3b80d8
For GNU attributes, instead of reusing attribute source
location for the scope location, use SourceLocation() since
GNU attributes don not have scope tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165234 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165074 91177308-0d34-0410-b5e6-96231b3b80d8
-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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164951 91177308-0d34-0410-b5e6-96231b3b80d8
use it to suggest appropriate macro for __attribute__((deprecated)) in
-Wdocumentation-deprecated-sync.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164892 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164854 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164366 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164313 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164083 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163962 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163831 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163434 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163224 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162938 91177308-0d34-0410-b5e6-96231b3b80d8
variables without a storage class within a function, to implement
CUDA B.2.5: "__shared__ and __constant__ variables have implied static
storage [duration]."
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162788 91177308-0d34-0410-b5e6-96231b3b80d8
Richard Smith