| Age | Commit message (Collapse) | Author |
|---|
|
found: if an overloaded operator& is present before a template definition,
the expression &T::foo is represented as a CXXOperatorCallExpr, not as a
UnaryOperator, so we didn't notice that it's permitted to reference a non-static
data member of an unrelated class.
While investigating this, I discovered another problem in this area: we are
treating template default arguments as unevaluated contexts during substitution,
resulting in performing incorrect checks for uses of non-static data members in
C++11. That is not fixed by this patch (I'll look into this soon; it's related
to the failure to correctly instantiate constexpr function templates), but was
resulting in this bug not firing in C++11 mode (except with -Wc++98-compat).
Original message:
PR14124: When performing template instantiation of a qualified-id outside of a
class, diagnose if the qualified-id instantiates to a non-static class member.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166385 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166369 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166361 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Suggestion from Matt Beaumont-Gay reviewing r165283.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166296 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Richard has an unreduced testcase to work with.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166272 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
class, diagnose if the qualified-id instantiates to a non-static class member.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166268 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://12491143
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166030 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
hopelessly poorly written code after spewing several
errors. // rdar://12491143
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166025 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165988 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
See PR14013.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165962 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
|
|
This only applies if the type has a name. (we could potentially do something
crazy with decltype in C++11 to qualify members of unnamed types but that
seems excessive)
It might be nice to also suggest a fixit for "&this->i", "&foo->i",
and "&foo.i" but those expressions produce 'bound' member functions that have
a different AST representation & make error recovery a little trickier. Left
as future work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165763 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Then, switch users of PropertyIfSetterOrGetter and LookupPropertyDecl
(the latter by name) over to findPropertyDecl. This actually makes
-Wreceiver-is-weak a bit stronger than it was before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165628 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165384 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165383 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This appears to be consistent with GCC's implementation of the same warning
under -Wparentheses. Suppressing a << b + c for cases where 'a' is a user
defined type for compatibility with C++ stream IO. Otherwise suggest
parentheses around the addition or subtraction subexpression.
(this came up when MSVC was complaining (incorrectly, so far as I can tell)
about a perceived violation of this within the LLVM codebase, PR14001)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165283 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
that doesn't have a 'self' as this implicitly captures 'self' and could
create retain cycles. Provide fixit. // rdar://11194874
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165133 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164989 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164855 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
|
|
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.
I would appreciate if someone would double-check that we get the mangling
correct with this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164658 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
> 'long long' is an extension when C99 mode is not enabled
to
> 'long long' is a C++11 extension
while compiling in C++98 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164545 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
StringRef makes code cleaner. Also, make the temporary buffer smaller:
512 characters is unreasonably large for integer literals.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
setter or getter backing a deprecated/unavailable property,
also not location of the property. // rdar://12324295
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164412 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
|
|
without a cast. Fixes <rdar://problem/11830912>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://12233989
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163338 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Don't warn if annotated decl is used inside another
unused. // rdar://12233989
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163329 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162962 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
__objc_yes/__objc_no to (BOOL)1/(BOOL)0 when
BOOL is declared; otherwise it resorts to
default of 'signed char'. This is important to
selecting the correct Numeric API numberWithBool:
Can't have a clang test for this. Will checkin and
executable llvm test. // rdar://12156616
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162922 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
when assignment expression in conditional invloves
property reference. // rdar://11066598
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162846 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162552 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
MutableArrayRef.
This required changing all get() calls to data() and using the simpler constructors.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These were nops for quite a while and only lead to confusion. ASTMultiPtr
now behaves like a proper dumb array reference.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162475 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This is effectively a warning for code that violates core issue 903 & thus will
become standard error in the future, hopefully. It catches strange null
pointers such as: '\0', 1 - 1, const int null = 0; etc...
There's currently a flaw in this warning (& the warning for 'false' as a null
pointer literal as well) where it doesn't trigger on comparisons (ptr == '\0'
for example). Fix to come in a future patch.
Also, due to this only being a warning, not an error, it triggers quite
frequently on gtest code which tests expressions for null-pointer-ness in a
SFINAE context (so it wouldn't be a problem if this was an error as in an
actual implementation of core issue 903). To workaround this for now, the
diagnostic does not fire in unevaluated contexts.
Review by Sean Silva and Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161501 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
-Wdirect-ivar-access.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161500 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
memory models, except when arc is accessing a weak
ivar (which is an error). // rdar://6505197
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161458 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Allow direct ivar access in init and dealloc methods
in mrr. // rdar://650197
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161426 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
// rdar://6505197
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161362 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The one caller that's surrounded by nearby code manipulating the underlying
evaluation context list is left unmodified for readability.
Review by Sean Silva and Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161355 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
on object pointers and whether pointer arithmetic on object pointers
is supported. Make ObjFW interpret subscripts as pseudo-objects.
Based on a patch by Jonathan Schleifer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161028 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160847 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160614 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
While we still want to consider this a hard error (non-POD variadic args are
normally a DefaultError warning), delaying the diagnostic allows us to give
better error messages, which also match the usual non-POD errors more closely.
In addition, this change improves the diagnostic messages for format string
argument type mismatches by passing down the type of the callee, so we can
say "variadic method" or "variadic function" appropriately.
<rdar://problem/11825593>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160517 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Fixes pr13353.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160393 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Due to performance cost, this is an opt-in option placed
under -Wassign-enum. // rdar://11824807
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160382 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Checks against nil often appear as guards in macros, and comparing
Objective-C literals to nil has well-defined behavior (if tautological).
On OS X, 'nil' has not been typed as 'id' since 10.6 (possibly earlier),
so the warning was already not firing, but other runtimes continue to use
((id)0) or some variant. This change accepts comparisons to any null pointer;
to keep it simple, it looks through all casts (not just casts to 'id').
PR13276
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160379 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Suggested by Ted, since string literal comparison is at least slightly more
sensible than comparison of runtime literals. (Ambiguous language on
developer.apple.com implies that strings are guaranteed to be uniqued within
a translation unit and possibly across a linked binary.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160378 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Recovering as if the user had actually called -isEqual: is a bit too far from
the semantics of the program as written, /even though/ it's probably what they
intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160377 91177308-0d34-0410-b5e6-96231b3b80d8
|
