This fixes the missing warning here:
struct S {
template <typename T>
void meth() {
char arr[3];
arr[4] = 0; // warning: array index 4 is past the end of the array
}
};
template <typename T>
void func() {
char arr[3];
arr[4] = 0; // no warning
}
llvm-svn: 170180
has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
is switched of by about 0.8% (tested with int i<N>).
Additionally, this puts computing the diagnostic class into the hot
path more when parsing, in preparation for upcoming optimizations
in this area.
llvm-svn: 169976
definition, rather than at the end of the definition of the set of nested
classes. We still defer checking of the user-specified exception specification
to the end of the nesting -- we can't check that until we've parsed the
in-class initializers for non-static data members.
llvm-svn: 169805
array from a braced-init-list. There seems to be a core wording wart
here (it suggests we should be testing whether the elements of the init
list are implicitly convertible to the array element type, not whether
there is an implicit conversion sequence) but our prior behavior appears
to be a bug, not a deliberate effort to implement the standard as written.
llvm-svn: 169690
the cases where we can't determine whether special members would be trivial
while building the class, we eagerly declare those special members. The impact
of this is bounded, since it does not trigger implicit declarations of special
members in classes which merely *use* those classes.
In order to determine whether we need to apply this rule, we also need to
eagerly declare move operations and destructors in cases where they might be
deleted. If a move operation were supposed to be deleted, it would instead
be suppressed, and we could need overload resolution to determine if we fall
back to a trivial copy operation. If a destructor were implicitly deleted,
it would cause the move constructor of any derived classes to be suppressed.
As discussed on cxx-abi-dev, C++11's selected constructor rules are also
retroactively applied as a defect resolution in C++03 mode, in order to
identify that class B has a non-trivial copy constructor (since it calls
A's constructor template, not A's copy constructor):
struct A { template<typename T> A(T &); };
struct B { mutable A a; };
llvm-svn: 169673
Remove pre-standard restriction on explicitly-defaulted copy constructors with
'incorrect' parameter types, and instead just make those special members
non-trivial as the standard requires.
This required making CXXRecordDecl correctly handle classes which have both a
trivial and a non-trivial special member of the same kind.
This also fixes PR13217 by reimplementing DiagnoseNontrivial in terms of the
new triviality computation technology.
llvm-svn: 169667
properly, rather than faking it up by pretending that a reference member makes
the default constructor non-trivial. That leads to rejects-valids when putting
such types inside unions.
llvm-svn: 169662
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
Don't require that, during template deduction, a template specialization type
as a function parameter has at least as many template arguments as one used in
a function argument (not even if the argument has been resolved to an exact
type); the additional parameters might be provided by default template
arguments in the template. We don't need this check, since we now implement
[temp.deduct.call]p4 with an additional check after deduction.
llvm-svn: 169475
For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.
(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)
This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.
<rdar://problem/11982013>
llvm-svn: 169400
The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.
There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.
In C++, the type of a character literal is 'char', and so this problem
doesn't exist.
<rdar://problem/12282316>
llvm-svn: 169398
Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.
llvm-svn: 169374
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
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
performed, to determine whether that special member is deleted or constexpr.
That overload resolution process can in turn trigger the instantiation of a
template, which can do anything, including triggering the declaration of that
very same special member function. When this happens, do not try to recursively
declare the special member -- that's impossible. Instead, only try to realise
the truth. There is no special member.
llvm-svn: 168847
determine which member function would be the callee from within the template
definition, don't pass that function as a "non-member function" to
CreateOverloadedBinOp. Instead, just rely on it to select the member function
for itself.
llvm-svn: 168818
constructor/assignment operator with a const-qualified parameter type. The
prior method for determining this incorrectly used overload resolution.
llvm-svn: 168775
a special member" diagnostic from warning to error, and fix the cases where it
produced diagnostics with incorrect wording.
We don't support this as an extension, and we ban it even in C++98 mode. This
breaks too much (for instance, the ABI-specified calling convention for a type
can change if it acquires a copy constructor through the addition of a default
argument).
llvm-svn: 168769
objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570
llvm-svn: 168740
initialization, don't rebuild it. Remove a couple of hacks which were trying to
work around this. Fix the special case for one-argument CXXConstructExprs to
not apply if the one argument is a default argument.
llvm-svn: 168582
It brought bunch of (possibly false) warnings.
llvm/unittests/VMCore/PassManagerTest.cpp:60:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:86:22: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleNDM2::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:106:21: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char ModuleDNM::ID=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:217:16: warning: variable 'initcount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::initcount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:218:16: warning: variable 'fincount' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int LPass::fincount=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:259:16: warning: variable 'inited' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::inited=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:260:16: warning: variable 'fin' is not needed and will not be emitted [-Wunneeded-internal-declaration]
int BPass::fin=0;
^
llvm/unittests/VMCore/PassManagerTest.cpp:283:24: warning: variable 'ID' is not needed and will not be emitted [-Wunneeded-internal-declaration]
char OnTheFlyTest::ID=0;
^
8 warnings generated.
llvm-svn: 168549
"clang -cc1 -fsyntax-only" on the preprocessed output of
#define M extern int a;
#define M2 M M
#define M4 M2 M2
#define M8 M4 M4
#define M16 M8 M8
#define M32 M16 M16
#define M64 M32 M32
#define M128 M64 M64
#define M256 M128 M128
#define M512 M256 M256
#define M1024 M512 M512
#define M2048 M1024 M1024
#define M4096 M2048 M2048
#define M8192 M4096 M4096
#define M16384 M8192 M8192
M16384
goes from 2.994s to 1.416s. GCC is at 0.022s, so we still have a long way to go.
llvm-svn: 168519
and defined within the current instantiation, but which are not part of the
current instantiation. Previously, it would look at bases which could be
specialized separately from the current template.
llvm-svn: 168477
getUnderlyingDecl()) so that derivatives of
CorrectionCandidateCallback::ValidateCandidate(...) don't have to worry
about being thrown by UsingDecls and such.
llvm-svn: 168317
width of an enum with negative values in IntRange. Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.
llvm-svn: 168126
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
It may become a dangling pointer if the underlying SmallVector reallocates.
Sadly the testcase is really large and doesn't reduce well because of
SmallVector's reallocation patterns.
Fixes PR14336.
llvm-svn: 168045
type-name is looked up in the context of the complete postfix-expression. Don't
forget to pass the scope into this lookup when the type-name is a template-id;
it might name an alias template which can't be found within the class itself.
Bug spotted by Johannes Schaub on #llvm.
llvm-svn: 168011
BinaryOperator::Opcode. This is bad form, and the behavior of the static_cast
in this case is unspecified according to the standard.
Fixes a warning that showed up from r167992 on self-host.
llvm-svn: 168010
type conversion between integers. This allows the warning to be more accurate.
Also, turned the warning off in an analyzer test. The relavent test cases
are covered by the tests in Sema.
llvm-svn: 167992
and we resolve it to a specific function based on the type which it's used as,
don't forget to mark it as referenced.
Fixes a regression introduced in r167514.
llvm-svn: 167918
* getMostSpecialized()
/// \param Index if non-NULL and the result of this function is non-nULL,
/// receives the index corresponding to the resulting function template
/// specialization.
* DeduceTemplateArguments()
/// \param Name the name of the function being called. This is only significant
/// when the function template is a conversion function template, in which
/// case this routine will also perform template argument deduction based on
/// the function to which
llvm-svn: 167909
This corrects the mangling and linkage of classes (& their member functions) in
cases like this:
struct foo {
struct {
void func() { ... }
} x;
};
we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.
This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.
Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.
Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.
llvm-svn: 167906
positions of Objective-C methods.
It is possible to recover a lot of type information about
Objective-C methods from the reflective metadata for their
implementations. This information is not rich when it
comes to struct types, however, and it is not possible to
produce a type in the debugger's round-tripped AST which
will really do anything useful during type-checking.
Therefore we allow __unknown_anytype in these positions,
which essentially disables type-checking for that argument.
We infer the parameter type to be the unqualified type of
the argument expression unless that expression is an
explicit cast, in which case it becomes the type-as-written
of that cast.
rdar://problem/12565338
llvm-svn: 167896
if the type of the value is a non-trivial class type. Fixes PR14318.
(There's a minor ObjC++ language change here: given that we can't save the
value, the type of the assignment expression is void in such cases.)
llvm-svn: 167884
new container so we can safely iterate over them.
The container holding the lookup decls can under certain conditions
be changed while iterating (e.g. because of deserialization).
llvm-svn: 167816
- In C++11, perform overload resolution over all assignment operators, rather than just looking for copy/move assignment operators.
- Clean up after temporaries produced by operator= immediately, rather than accumulating them until the end of the function.
llvm-svn: 167798
applied to CXXRecordDecls, where functions with that return type will
inherit the warn_unused_result attribute.
Also includes a tiny fix (with no discernable behavior change for
existing code) to re-sync AttributeDeclKind enum and
err_attribute_wrong_decl_type with warn_attribute_wrong_decl_type since
the enum is used with both diagnostic messages to chose the correct
description.
llvm-svn: 167783
assignment generation. This incidentally avoids reusing the same Expr* across
multiple statements in the same object; that was generating slightly broken
ASTs, but I couldn't trigger any observable bad behavior, so no test.
llvm-svn: 167779
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
The 'a', 'c', and 'd' constraints on i386 mean a 32-bit register. We cannot
place a 64-bit value into the 32-bit register. Error out instead of causing the
compiler to spew general badness.
<rdar://problem/12415959>
llvm-svn: 167717
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
would have diagnosed this at instantiation time anyway, if only we
didn't hang on all of these test cases. Fixes <rdar://problem/12629723>
llvm-svn: 167651
C++11 3.3.3/2 "A parameter name shall not be redeclared in the outermost block
of the function definition nor in the outermost block of any handler associated
with a function-try-block."
It's not totally clear to me whether the "FIXME" case is covered by this, but
Richard Smith thinks it probably should be. It's just a bit more involved to
fix that case.
llvm-svn: 167650
This warning was failing to fire under ARC because of the implicit
lifetime casts added around the object literal expression.
<rdar://problem/11300873>, again.
llvm-svn: 167648
I couldn't think of a way to make an operator() invalid without returning
earlier from this function other than making it static, so no new test.
llvm-svn: 167609
function that takes a const Foo&, where Foo is convertible from a large number
of pointer types, we print ALL the overloads, no matter the setting of
-fshow-overloads.
There is potential follow-on work in unifying the "print candidates, but not
too many" logic between OverloadCandidateSet::NoteCandidates and
ImplicitConversionSequence::DiagnoseAmbiguousConversion.
llvm-svn: 167596
Eli Friedman