| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This is at least good documentation, but also opens the possibility of
using pipefail.
llvm-svn: 185652
|
| |
|
|
|
|
|
| |
private ivars in class extensions and class
@implementation. // rdar://14278560
llvm-svn: 185025
|
| |
|
|
|
|
|
| |
is declared to have 'assign' attribute.
// rdar://14212998
llvm-svn: 184863
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
of using -performSelectorXXX.
-performSelector: and friends return a value that is boxed as an Objective-C
pointer. Sometimes it is an Objective-C pointer, sometimes it isn't.
Some clients may wish to silence this warning based on calling
this method.
Fixes <rdar://problem/14147304>
llvm-svn: 184789
|
| |
|
|
|
|
|
| |
CheckParmForFunctionDef performs standard checks for type completeness
and other things like a destructor check for the MSVC++ ABI.
llvm-svn: 184740
|
| |
|
|
| |
llvm-svn: 184519
|
| |
|
|
| |
llvm-svn: 184417
|
| |
|
|
|
|
|
| |
selector would be correted to identical selector name
in certain corner cases. // rdar://7853549
llvm-svn: 184208
|
| |
|
|
| |
llvm-svn: 184199
|
| |
|
|
|
|
|
|
| |
in addition of receiver having static type, but also when
receiver has dynamic type (of 'id' variety) as well as when
receiver is of 'Class' type vareity. // rdar://7853549
llvm-svn: 184195
|
| |
|
|
| |
llvm-svn: 184093
|
| |
|
|
|
|
| |
is sent to a receiver object. This is wip. // rdar://7853549
llvm-svn: 184086
|
| |
|
|
|
|
|
|
| |
random checks for ObjC object return types to SemaType.cpp.
Fixes issue with ObjC method type checking reported on cfe-dev.
llvm-svn: 184006
|
| |
|
|
|
|
|
| |
property auto-synthesis before knowingit it is to be
auto-synthesized. // rdar://14094682
llvm-svn: 183556
|
| |
|
|
|
|
| |
of properties. Fixes // rdar://14085456
llvm-svn: 183542
|
| |
|
|
|
|
|
| |
'ivar' was used inside a record/union used
as argument to __typeof. // rdar14037151 pr5984
llvm-svn: 183048
|
| |
|
|
|
|
|
|
| |
which diagnoses type mismatches of identical
selectors declared in classes throughout.
// rdar://14007194
llvm-svn: 182964
|
| |
|
|
|
|
|
| |
in an @selector expression has no implementation.
// rdar://14002507
llvm-svn: 182812
|
| |
|
|
|
|
|
| |
variables when they are used in such unevaluated
contexts as __typeof, etc. // rdar://13942025
llvm-svn: 182423
|
| |
|
|
|
|
|
|
| |
protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes
the property. // rdar://13075400
llvm-svn: 182316
|
| |
|
|
|
|
|
|
| |
synthesize a property getter method that overrides
a method definition named 'retain' and the like.
Fixes // rdar://13885083
llvm-svn: 182039
|
| |
|
|
|
|
|
| |
working on new Objective-C array subscripting
syntax. // rdar://13855682
llvm-svn: 181940
|
| |
|
|
|
|
|
| |
warning when property-dot syntax is used
with -Wsign-conversion. // rdar://13855394
llvm-svn: 181914
|
| |
|
|
|
|
| |
patch (r181847).
llvm-svn: 181896
|
| |
|
|
|
|
|
|
| |
found for a receiver, note where receiver class
is declaraed (this is most common when receiver is a forward
class). // rdar://3258331
llvm-svn: 181847
|
| |
|
|
|
|
| |
More of rdar://13200889.
llvm-svn: 181390
|
| |
|
|
|
|
| |
Per discussion in cfe-commits, asserting may be a better way than introducing a special test flag.
llvm-svn: 181073
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180973
|
| |
|
|
| |
llvm-svn: 180972
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180970
|
| |
|
|
|
|
|
|
|
|
|
|
| |
message, to the selector location.
Previously it would point to the left bracket or the receiver, which can be particularly
problematic if the receiver is a block literal and we end up point the diagnostic far away
for the selector that is complaining about.
rdar://13620447
llvm-svn: 180833
|
| |
|
|
|
|
|
| |
in the diagnostics. Remove them when reporting incompatible
Objective-C pointer types. // rdar://13752880.
llvm-svn: 180765
|
| |
|
|
| |
llvm-svn: 180651
|
| |
|
|
|
|
|
|
|
|
| |
patch -n r180198.
When reporting on missing property accessor implementation in
categories, do not report when they are declared in primary class,
class's protocol, or one of it super classes or in of the other
categories. // rdar://13713098
llvm-svn: 180580
|
| |
|
|
|
|
|
|
| |
property cannot be synthesized because its backing
ivar does not support weak references.
// rdar://13676793
llvm-svn: 180211
|
| |
|
|
|
|
|
|
| |
categories, do not report when they are declared in primary class,
class's protocol, or one of it super classes. This is because,
its class is going to implement them. // rdar://13713098
llvm-svn: 180198
|
| |
|
|
|
|
| |
tweak warning to suggest that it is just a bad thing to do.
llvm-svn: 180175
|
| |
|
|
| |
llvm-svn: 180056
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
VerifyDiagnosticConsumer previously would not check that the diagnostic and
its matching directive referenced the same source file. Common practice was
to create directives that referenced other files but only by line number,
and this led to problems such as when the file containing the directive
didn't have enough lines to match the location of the diagnostic in the
other file, leading to bizarre file formatting and other oddities.
This patch causes VerifyDiagnosticConsumer to match source files as well as
line numbers. Therefore, a new syntax is made available for directives, for
example:
// expected-error@file:line {{diagnostic message}}
This extends the @line feature where "file" is the file where the diagnostic
is generated. The @line syntax is still available and uses the current file
for the diagnostic. "file" can be specified either as a relative or absolute
path - although the latter has less usefulness, I think! The #include search
paths will be used to locate the file and if it is not found an error will be
generated.
The new check is not optional: if the directive is in a different file to the
diagnostic, the file must be specified. Therefore, a number of test-cases
have been updated with regard to this.
This closes out PR15613.
llvm-svn: 179677
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overridden methods.
When we are in a implementation, we check the global method pool whether there were category
methods with the same selector. If there were none (common case) we don't need to do lookups for
overridden methods again.
Note that for an interface method (if we don't encounter its implementation), it is considered that
it overrides methods that were declared before it, not for category methods introduced after it.
This is tradeoff in favor of performance, since it is expensive to do lookups in case there was a
category, and moving the global method pool to ASTContext (so we can check it) would increase complexity.
rdar://13508196
llvm-svn: 179654
|
| |
|
|
|
|
|
|
| |
references thereto.
Patch by Tong Shen!
llvm-svn: 179585
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit r179436.
Due to caching, it was possible that we could miss overridden methods that
were introduced by categories later on.
Along with reverting the commit I also included a test case that would have caught this.
llvm-svn: 179547
|
| |
|
|
|
|
|
|
| |
Yes, this came from actual code.
Fixes <rdar://problem/13557053>.
llvm-svn: 179155
|
| |
|
|
|
|
|
|
|
|
|
| |
when result type of protocol property and getter method
differ by fixing a more serious problem. When a forward
protocol declaration comes between its definition and
its use in class protocol list, the forward protocol
ast was being used in building the protocol list.
// rdar://12522752
llvm-svn: 179108
|
| |
|
|
|
|
|
|
| |
that method gets a warning.
Test case from <rdar://problem/11627873>.
llvm-svn: 179070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New rule:
- Method decls in @implementation are considered "redeclarations"
and inherit deprecated/availability from the @interface.
- All other cases are consider overrides, which do not inherit
deprecated/availability. For example:
(a) @interface redeclares a method in an adopted protocol.
(b) A subclass redeclares a method in a superclass.
(c) A protocol redeclares a method from another protocol it adopts.
The idea is that API authors should have the ability to easily
move availability/deprecated up and down a class/protocol hierarchy.
A redeclaration means that the availability/deprecation is a blank
slate.
Fixes <rdar://problem/13574571>
llvm-svn: 178937
|
| |
|
|
|
|
|
| |
deprecated typedef to subclass or invoke a class method.
// rdar://13569424
llvm-svn: 178775
|
| |
|
|
|
|
| |
when redeclaring ObjC properties.
llvm-svn: 178770
|
| |
|
|
|
|
| |
to inherit "deprecated".
llvm-svn: 178743
|
| |
|
|
|
|
|
|
| |
warning when doing a __bride cast in non-arc
mode (which has no retain count effect).
// rdar://13514210
llvm-svn: 178592
|