| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
reimplemented in the AsmParser where it belongs.
llvm-svn: 165752
|
|
|
|
|
|
|
|
|
| |
now unused static helper function.
The test case needs to be remove temporarily until I can better filter memory
operands that aren't actual variable reference.
llvm-svn: 165751
|
|
|
|
| |
llvm-svn: 165733
|
|
|
|
|
|
| |
Fix-up for r165718, should get the buildbots back online.
llvm-svn: 165723
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, [foo weakProp] was not being treated the same as foo.weakProp.
Now, for every explicit message send, we check if it's a property access,
and if so, if the property is weak. Then for every assignment of a
message, we have to do the same thing again.
This is a potentially expensive increase because determining whether a
method is a property accessor requires searching through the methods it
overrides. However, without it -Warc-repeated-use-of-weak will miss cases
from people who prefer not to use dot syntax. If this turns out to be
too expensive, we can try caching the result somewhere, or even lose
precision by not checking superclass methods. The warning is off-by-default,
though.
<rdar://problem/12407765>
llvm-svn: 165718
|
|
|
|
| |
llvm-svn: 165710
|
|
|
|
| |
llvm-svn: 165679
|
|
|
|
|
|
| |
member operator(). PR14057.
llvm-svn: 165678
|
|
|
|
|
|
|
| |
Reading from a weak property, casting the result, and assigning to a
strong pointer should still be considered safe.
llvm-svn: 165629
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 165628
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old algorithm:
1. See if the name looks like a getter or setter.
2. Use the name to look up a property in the current ObjCContainer
and all its protocols.
3. If the current container is an interface, also look in all categories
and superclasses (and superclass categories, and so on).
New algorithm:
1. See if the method is marked as a property accessor. If so, look through
all properties in the current container and find one that has a matching
selector.
2. Find all overrides of the method using ObjCMethodDecl's
getOverriddenMethods. This collects methods in superclasses and protocols
(as well as superclass categories, which isn't really necessary), and
checks if THEY are accessors. This part is not done recursively, since
getOverriddenMethods is already recursive.
This lets us handle getters and setters that do not match the property
names.
llvm-svn: 165627
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This more accurately reflects its use: this flag is set when a method
matches the getter or setter name for a property in the same class,
and does not actually specify whether or not the definition of the method
will be synthesized (either implicitly or explicitly with @synthesize).
This renames the setter and backing field as well, and changes the
(soon-to-be-obsolete?) XML dump format to use 'property_accessor'
instead of 'synthesized'.
llvm-svn: 165626
|
|
|
|
|
|
|
|
| |
constructor with invalid code.
rdar://12240916
llvm-svn: 165623
|
|
|
|
|
|
|
|
|
|
|
|
| |
write out the macro history for that macro. Similarly, we need to cope
with reading a macro definition that has been #undef'd.
Take advantage of this new ability so that global code-completion
results can refer to #undef'd macros, rather than losing them
entirely. For multiply defined/#undef'd macros, we will still get the
wrong result, but it's better than getting no result.
llvm-svn: 165502
|
|
|
|
|
|
| |
OverloadCandidateSet::clear and don't do it on destruction.
llvm-svn: 165501
|
|
|
|
|
|
| |
canonical method; avoid storing them again for an out-of-line definition.
llvm-svn: 165472
|
|
|
|
| |
llvm-svn: 165384
|
|
|
|
| |
llvm-svn: 165383
|
|
|
|
|
|
| |
what's going on, per Sean Silva's suggestion.
llvm-svn: 165286
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
llvm-svn: 165283
|
|
|
|
|
|
| |
import declaration.
llvm-svn: 165277
|
|
|
|
|
|
|
|
| |
a non-inline namespace, then reopens it as inline to try to add its symbols to
the surrounding namespace. In this one special case, permit the namespace to be
reopened as inline, and patch up the name lookup tables to match.
llvm-svn: 165263
|
|
|
|
| |
llvm-svn: 165259
|
|
|
|
| |
llvm-svn: 165258
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
mess by handling all pragmas which the parser touches uniformly.
<rdar://problem/12248901>, etc.
llvm-svn: 165195
|
|
|
|
|
|
|
| |
that doesn't have a 'self' as this implicitly captures 'self' and could
create retain cycles. Provide fixit. // rdar://11194874
llvm-svn: 165133
|
|
|
|
|
|
|
|
| |
- General C++11 attributes were previously parsed and ignored. Now they are parsed and stored in AST.
- Add support to parse arguments of attributes that in 'gnu' namespace.
- Differentiate unknown attributes and known attributes that can't be applied to statements when emitting diagnostic.
llvm-svn: 165082
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 165070
|
|
|
|
|
|
|
| |
A Sema lookup is used to determine the size of the variable, which is in turn
used during wildcard matching.
llvm-svn: 165058
|
|
|
|
|
|
|
|
| |
pointer size
directives (e.g., dword ptr [eax]).
llvm-svn: 165031
|
|
|
|
| |
llvm-svn: 165025
|
|
|
|
|
|
|
|
| |
is allowed or ignored with warning. This allows for correct name mangling for x64 targets on Windows, which in turn allows for linking against the Win32 APIs.
Fixes PR13782
llvm-svn: 165015
|
|
|
|
|
|
|
|
| |
allowed
for ARC. Fixes <rdar://problem/12407705>
llvm-svn: 164990
|
|
|
|
|
|
|
|
| |
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).
llvm-svn: 164989
|
|
|
|
|
|
|
|
| |
function.
Fixes <rdar://problem/12355298>
llvm-svn: 164988
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also applies to -Wnonnull, -Wtype-safety, and -Wnon-pod-varargs.
All of these can be better checked at instantiation time.
This change does not actually affect regular CallExpr function calls,
since the checks there only happen after overload resolution.
However, it will affect Objective-C method calls.
<rdar://problem/12373934>
llvm-svn: 164984
|
|
|
|
|
|
| |
Rework the logic to account for the fact that we no longer create a MCInst.
llvm-svn: 164980
|
|
|
|
|
|
|
| |
representation. Fix crash if it appears in the return type of a member function
definition.
llvm-svn: 164967
|
|
|
|
| |
llvm-svn: 164966
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
New output:
warning: weak property may be unpredictably set to nil
note: property declared here
note: assign the value to a strong variable to keep the object alive
during use
<rdar://problem/12277204>
llvm-svn: 164857
|
|
|
|
|
|
|
|
|
| |
The infrastructure for -Warc-repeated-use-of-weak got a little too heavy
to leave sitting at the top of Sema.cpp.
No functionality change.
llvm-svn: 164856
|
|
|
|
|
|
|
|
|
|
| |
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
|