| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
is not implemented. // rdar://9651605
llvm-svn: 133819
|
| |
|
|
|
|
|
| |
diagnose it properly and don't throw clang into an
infinit loop. // rdar://9653341
llvm-svn: 133773
|
| |
|
|
|
|
| |
complaining about mismatches in the global method pool.
llvm-svn: 133123
|
| |
|
|
|
|
|
|
|
|
| |
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
|
| |
|
|
|
|
| |
inference, to be used (only) by the Objective-C rewriter.
llvm-svn: 133025
|
| |
|
|
|
|
| |
reason to allow the user to control these semantics through a flag.
llvm-svn: 132919
|
| |
|
|
| |
llvm-svn: 132917
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related result types apply Cocoa conventions to the type of message
sends and property accesses to Objective-C methods that are known to
always return objects whose type is the same as the type of the
receiving class (or a subclass thereof), such as +alloc and
-init. This tightens up static type safety for Objective-C, so that we
now diagnose mistakes like this:
t.m:4:10: warning: incompatible pointer types initializing 'NSSet *'
with an
expression of type 'NSArray *' [-Wincompatible-pointer-types]
NSSet *array = [[NSArray alloc] init];
^ ~~~~~~~~~~~~~~~~~~~~~~
/System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:72:1:
note:
instance method 'init' is assumed to return an instance of its
receiver
type ('NSArray *')
- (id)init;
^
It also means that we get decent type inference when writing code in
Objective-C++0x:
auto array = [[NSMutableArray alloc] initWithObjects:@"one", @"two",nil];
// ^ now infers NSMutableArray* rather than id
llvm-svn: 132868
|
| |
|
|
|
|
| |
'true' on detecting protocol cycles. No functionality change.
llvm-svn: 131297
|
| |
|
|
|
|
|
|
| |
don't build circular AST in protocol's protocol list
when user code has introduced it. Indexer and other
clients may crash. // rdar://9221614
llvm-svn: 131254
|
| |
|
|
|
|
|
| |
scope depth overlaps with the ObjCDeclQualifier, dropping
memory usage back to previous levels.
llvm-svn: 130671
|
| |
|
|
|
|
| |
stop considering whether I can compress them. :)
llvm-svn: 130633
|
| |
|
|
| |
llvm-svn: 130045
|
| |
|
|
|
|
|
|
|
|
|
| |
ObjC NeXt runtime where method pointer registered in
metadata belongs to an unrelated method. Ast part of this fix,
I turned at @end missing warning (for class
implementations) into an error as we can never
be sure that meta-data being generated is correct.
// rdar://9072317
llvm-svn: 130019
|
| |
|
|
| |
llvm-svn: 129567
|
| |
|
|
|
|
| |
Luis Felipe Strano Moraes!
llvm-svn: 129559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
|
| |
|
|
|
|
|
| |
method prototypes under the -Wduplicate-method-arg and
turn it off by default.
llvm-svn: 127552
|
| |
|
|
| |
llvm-svn: 127225
|
| |
|
|
|
|
|
| |
used for attributes that are okay to inherit when written on a parameter.
Dependent on LLVM r126827.
llvm-svn: 126828
|
| |
|
|
|
|
|
| |
protocols do not match with method implementation.
// rdar://7076235
llvm-svn: 126162
|
| |
|
|
|
|
|
| |
own weird little DenseMap. Hey look, we now emit unused label
warnings deterministically, amazing.
llvm-svn: 125813
|
| |
|
|
|
|
| |
Warning and its note will be ignored in default case.
llvm-svn: 125621
|
| |
|
|
| |
llvm-svn: 125619
|
| |
|
|
|
|
| |
deprecated class and methods in objective-c.
llvm-svn: 125573
|
| |
|
|
|
|
|
|
|
| |
Warn if class for a deprecated class is implemented.
Warn if category for a deprecated class is implemented.
All under control of -Wdeprecated-implementations.
// rdar://8973810.
llvm-svn: 125545
|
| |
|
|
|
|
|
| |
warning when same parameter name used multiple times.
// rdar://8877730
llvm-svn: 125229
|
| |
|
|
|
|
|
|
| |
when selector metadata is generated, which is triggered
by at least on class implementation. This is to match gcc's
behavior. // rdar://8851684.
llvm-svn: 124909
|
| |
|
|
|
|
|
| |
more accurate, and makes it make sense for it to hold a delegating constructor
call.
llvm-svn: 123084
|
| |
|
|
|
|
|
|
|
|
|
|
| |
to allow us to explicitly control whether or
not Objective-C properties are default synthesized.
Currently this feature only works when using
the -fobjc-non-fragile-abi2 flag (so there is
no functionality change), but we can now turn
off this feature without turning off all the features
coupled with -fobjc-non-fragile-abi2.
llvm-svn: 122519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
classes, categories, protocols, and class extensions, where the
methods and properties of these entities would be inserted into the
DeclContext in an ordering that doesn't necessarily reflect source
order. The culprits were Sema::ActOnMethodDeclaration(), which did not
perform the insertion of the just-created method declaration into
the DeclContext for these Objective-C entities, and
Sema::ActOnAtEnd(), which inserted all method declarations at the
*end* of the DeclContext.
With this fix in hand, clean up the code-completion actions for
property setters/getters that worked around this brokenness in the AST.
Fixes <rdar://problem/8062781>, where this problem manifested as poor
token-annotation information, but this would have struck again in many
other places.
llvm-svn: 122347
|
| |
|
|
|
|
|
|
| |
unknown type and there is a possibility that
at runtime method is resolved to a deprecated or
unavailable method. Addreses // rdar://8769853
llvm-svn: 122294
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Diagnostic pragmas are broken because we don't keep track of the diagnostic state changes and we only check the current/latest state.
Problems manifest if a diagnostic is emitted for a source line that has different diagnostic state than the current state; this can affect
a lot of places, like C++ inline methods, template instantiations, the lexer, etc.
Fix the issue by having the Diagnostic object keep track of the source location of the pragmas so that it is able to know what is the diagnostic state at any given source location.
Fixes rdar://8365684.
llvm-svn: 121873
|
| |
|
|
|
|
|
|
| |
for declaration of property setter/getter in forward
class extensions and also skip over
propeties which are @dynamic.
llvm-svn: 121617
|
| |
|
|
|
|
|
|
|
|
|
| |
declared setter or getter in current class extension or one
of the other class extensions. Mark them as synthesized as
property will be synthesized when property with same name is
seen in the @implementation. This prevents bogus warning
about unimplemented methods to be issued for these methods.
Fixes // rdar://8747333
llvm-svn: 121597
|
| |
|
|
|
|
|
| |
methods in protocols when protocols are in system
headers and thus ignored. //rdar: //8227199
llvm-svn: 117739
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
is that we need more information to decide the exact conditions for whether
one ObjCObjectPointer is an acceptable return/parameter override for another,
so we're going to disable that entire class of warning for now. The
"forward developement" warning category, -Wmethod-signatures, can receive
unrestricted feature work, and when we're happy with how it acts, we'll
turn it on by default.
This is a pretty conservative change, and nobody's totally content with it.
llvm-svn: 117524
|
| |
|
|
|
|
|
|
|
|
|
| |
covariant/contravariant overrides and implementations, but do so under
control of a new flag (-Wno-objc-covariant-overrides, which yes does cover
contravariance too).
*At least* the covariance cases will probably be enabled by default shortly,
but that's not totally uncontroversial.
llvm-svn: 117346
|
| |
|
|
|
|
|
|
|
|
| |
incompatible, not when they are simply different. Now we test whether the difference in types breaks the principle of substitutability, rather than whether they are different.
A common idiom in Objective-C is to provide a definition of a method in a subclass that returns a more-specified version of an object than the superclass. This does not violate the principle of substitutability, because you can always use the object returned by the subclass anywhere that you could use the type returned by the superclass. It was, however, generating warnings with clang, leading people to believe that semantically correct code was incorrect and requiring less accurate type specification and explicit down-casts (neither of which is a good thing to encourage).
This change ensures that any method definition has parameter and return types that make it accept anything that something conforming to the declaration may pass and return something that the caller will expect, but allows stricter definitions.
llvm-svn: 117271
|
| |
|
|
|
|
|
|
|
| |
one declared in class's extension and not one declared
in class's superclass. This supresses a bogus warning on
method type mismatch.
Fixes //rdar: // 8530080
llvm-svn: 116118
|
| |
|
|
|
|
|
| |
attribute(unavailable) to do next.
// rdar:// 6734520.
llvm-svn: 115842
|
| |
|
|
|
|
|
| |
Previously, compiler warned only if it was unsafe if types
did not match. Fixes // rdar: //7933061
llvm-svn: 115683
|
| |
|
|
|
|
|
| |
method definitions instead of crashing in code gen.
Fixes radar 8421082.
llvm-svn: 114223
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
ReferencedProtocols and AllReferencedProtocols. ReferencedProtocols
(and thus protocol_begin(), protocol_end()) now only contains the list of protocols that were directly referenced in
an @interface declaration. 'all_referenced_protocol_[begin,end]()' now returns the set of protocols that were referenced
in both the @interface and class extensions. The latter is needed for semantic analysis/codegen, while the former is
needed to maintain the lexical information of the original source.
Fixes <rdar://problem/8380046>.
llvm-svn: 112691
|
| |
|
|
|
|
| |
semantics slightly. No functionality change in the absence of inline namespaces. Also, change a few places where inline namespaces actually make a difference to be prepared for them.
llvm-svn: 112563
|
| |
|
|
|
|
| |
This lets us remove Sema.h's dependency on Expr.h and Decl.h.
llvm-svn: 112156
|
| |
|
|
|
|
|
| |
Clients of Sema don't need to know (for example) the list of diagnostics we
support.
llvm-svn: 112093
|
| |
|
|
| |
llvm-svn: 112038
|
| |
|
|
| |
llvm-svn: 112030
|
| |
|
|
|
|
|
| |
#include Sema.h while keeping all the AST declarations opaque. That may
not be reasonably attainable, though.
llvm-svn: 111907
|