name as an existing ivar since this is common source of error
when people remove @synthesize to take advantage of autosynthesis.
// rdar://11671080
llvm-svn: 158756
Objective-C literals conceptually always create new objects, but may be
optimized by the compiler or runtime (constant folding, singletons, etc).
Comparing addresses of these objects is relying on this optimization
behavior, which is really an implementation detail.
In the case of == and !=, offer a fixit to a call to -isEqual:, if the
method is available. This fixit is directly on the error so that it is
automatically applied.
Most of the time, this is really a newbie mistake, hence the fixit.
llvm-svn: 158230
This was a problem for people who write 'return(result);'
Also fix ARCMT's corresponding code, though there's no test case for this
because implicit casts like this are rejected by the migrator for being
ambiguous, and explicit casts have no problem.
<rdar://problem/11577346>
llvm-svn: 158130
Within the guts of CheckFormatHandler, the IsObjCLiteral flag was being used in
two ways: to see if null bytes were allowed, and to see if the '%@' specifier
is allowed.* The former usage has been changed to an explicit test and the
latter pushed down to CheckPrintfHandler and renamed ObjCContext, since it
applies to CFStrings as well.
* This also changes how wide chars are interpreted; in OS X Foundation, the
wide character type is 'unichar', a typedef for short, rather than wchar_t.
llvm-svn: 157968
getter result type is safe but does not match with property
type resulting in spurious warning followed by crash in
IRGen. // rdar://11515196
llvm-svn: 157641
Where diagnostic about unfound property is not
issued in the context where a setter is looked up
in situation in which name and property name differ
in their first letter case. // rdar://11363363
llvm-svn: 157407
that the methods have the same number of parameters, although we
certainly assumed this in many places. Objective-C can be insane
sometimes. Fixes <rdar://problem/11460990>.
llvm-svn: 157025
Previously we would reject it as illegal using a value of
enum type and on ObjC++ it was illegal to use an enumerator
as well.
rdar://11454917
llvm-svn: 156843
Once we've found a "good" method, we don't need to check its argument types
again. (Even if we might have later found a "bad" method, we were already
caching the method we first looked up.)
llvm-svn: 156719
@throw expression; l2r conversion can introduce new cleanups
in certain cases, like when the expression is an ObjC property
reference of retainable type in ARC.
llvm-svn: 156425
shadow of a block expression with non-trivial destructed cleanups,
we should flag that in the enclosing function, not in the block
that we're about to pop.
llvm-svn: 154646
The warning this inhibits, -Wobjc-root-class, is opt-in for now. However, all clang unit tests that would trigger
the warning have been updated to use -Wno-objc-root-class. <rdar://problem/7446698>
llvm-svn: 154187
defined here, but not semantically, so
new struct S {};
is always ill-formed, even if there is a struct S in scope.
We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.
llvm-svn: 152549
NSNumber, and boolean literals. This includes both Sema and Codegen support.
Included is also support for new Objective-C container subscripting.
My apologies for the large patch. It was very difficult to break apart.
The patch introduces changes to the driver as well to cause clang to link
in additional runtime support when needed to support the new language features.
Docs are forthcoming to document the implementation and behavior of these features.
llvm-svn: 152137
(Hopefully, common usage of these pragmas isn't irregular enough to break our current handling. Doug has ideas for a more crazy approach if necessary.)
llvm-svn: 151307
has been declared in its primary class, superclass,
or in one of their protocols, no need to issue unimplemented method.
// rdar://10823023
llvm-svn: 150206
Parsing of @implementations was based on modifying global state from
the parser; the logic for late parsing of methods was spread in multiple places
making it difficult to have a robust error recovery.
-it was difficult to ensure that we don't neglect parsing the lexed methods.
-it was difficult to setup the original objc container context for parsing the lexed methods
after completing ParseObjCAtImplementationDeclaration and returning to top level context.
Enhance parsing of @implementations by centralizing it in Parser::ParseObjCAtImplementationDeclaration().
ParseObjCAtImplementationDeclaration now returns only after an @implementation is fully parsed;
all the data and logic for late parsing of methods is now in one place.
This allows us to provide code-completion for late parsed methods with mis-matched braces.
rdar://10775381
llvm-svn: 149987
want to provide "po"-like functionality which
treats the result of an expression implicitly as
"id" (if it is not otherwise known) and prints
it as an Objective-C object.
This has in the past been gated by the
"DebuggerSupport" language option, but that is
too general. Debuggers also provide other commands
like "print" that do not make any assumptions
about whether the object is an Objective-C object.
This patch makes the assumption conditional on a
new language option: DebuggerCastResultToId. I
have also made corresponding modifications to the
testsuite.
llvm-svn: 149735
CFBridgingRetain/CFBridgingRelease calls instead
of __bridge_retained/__bridge_transfer casts as preferred
way of moving cf objects to arc land. // rdar://10207950
llvm-svn: 149449
This is to prevent diagnostic when using NSLocalizedString or CFCopyLocalizedString
macros which are usually used in place of NS and CF strings literals.
llvm-svn: 149268
- Remove the printf0 special handling as we treat it as printf anyway.
- Perform basic checks (non-literal, empty) for all formats and not only printf/scanf.
llvm-svn: 149236
declarator just because we were able to build an invalid decl
for it. The invalid-type diagnostics, in particular, are still useful
to know, and may indicate something about why the decl is invalid.
Also, recover from an illegal pointer/reference-to-unqualified-retainable
type using __strong instead of __autoreleasing; in general, a random
object is much more likely to be __strong, so this avoids unnecessary
cascading errors in the most common case.
llvm-svn: 149074
PR 10274: format function attribute with the NSString archetype yields no compiler warnings
PR 10275: format function attribute isn't checked in Objective-C methods
llvm-svn: 148324
declarations and definitions) as ObjCInterfaceDecls within the same
redeclaration chain. This new representation matches what we do for
C/C++ variables/functions/classes/templates/etc., and makes it
possible to answer the query "where are all of the declarations of
this class?"
llvm-svn: 146679
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
force the unknown any type to "id" so that the message send can be
completed without requiring a case. Fixes <rdar://problem/10506646>.
llvm-svn: 145552
Objective-C classes. This has two purposes: to consistently provide
"forward declaration here" notes when we hit an incomplete type, and
to give LLDB a chance to complete the type.
RequireCompleteType bits from Sean Callanan!
llvm-svn: 144573
doesn't duplicate, but they all surface as implicit
properties. It's also a useful optimization to not
duplicate the implicit getter lookup. So, trust the
getter lookup that was already done in these cases.
llvm-svn: 144031
__weak is unsupported by the deployment target, since it is going to be
ignored anyway.
Makes it easier for incremental migration from GC.
llvm-svn: 143975
expressions: expressions which refer to a logical rather
than a physical l-value, where the logical object is
actually accessed via custom getter/setter code.
A subsequent patch will generalize the AST for these
so that arbitrary "implementing" sub-expressions can
be provided.
Right now the only client is ObjC properties, but
this should be generalizable to similar language
features, e.g. Managed C++'s __property methods.
llvm-svn: 142914
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
calls, or calls to audited functions without an explicit
return attribute, to be casted without a bridge cast.
Tie this mechanism in with the existing exceptions to
the cast restrictions. State those restrictions more
correctly and generalize.
llvm-svn: 140912
pointer to the annotated struct type can be used as an
Objective-C object pointer. If an argument is given, the
type is actually "toll-free bridged" to the specific type
named there, rather than just to 'id'.
For now, we cannot rely on all types being so annotated,
and we'll always have to have exceptions for things like
CFTypeRef (aka const void*), but this is clearly a good
foundation for improving toolage in this area.
llvm-svn: 140779
attribute must match its overriden method. Same also for
ns_returns_retained/not_retained on the result type.
This is one half of // rdar://10187884
llvm-svn: 140649
system change in <rdar://problem/10109725> that allows conversion from
'self' in class methods to the root of the class's hierarchy. This
conversion rule is a hack that has non-trivial repurcussions
(particularly with overload resolution).
llvm-svn: 140605
protocol declares the property, as well as one of its superclasses.
Property will be implemented in the super class. // rdar://10120691
llvm-svn: 140586
merging for overrides. One might want to make a method's availability
in a superclass different from that of its subclass. Fixes
<rdar://problem/10166223>.
llvm-svn: 140406
'id' that can be used (only!) via a contextual keyword as the result
type of an Objective-C message send. 'instancetype' then gives the
method a related result type, which we have already been inferring for
a variety of methods (new, alloc, init, self, retain). Addresses
<rdar://problem/9267640>.
llvm-svn: 139275
synthesis. This new feature is currently placed under
-fobjc-default-synthesize-properties option
and is off by default pending further testing.
It will become the default feature soon.
// rdar://8843851
llvm-svn: 138913
and does the Sema on their body after the entire
class/category @implementation is seen. This change allows messaging
of forward private methods, as well as, access to
synthesized ivars of properties with foward synthesize
declarations; among others. In effect, this patch removes
several restrictions placed on objective-c due to in-place
semantics processing of methods.
This is part of // rdar://8843851.
llvm-svn: 138865
of the function in question when applicable (that is, not for blocks).
Patch by Joerg Sonnenberger with some stylistic tweaks by me.
When discussing this weth Joerg, streaming the decl directly into the
diagnostic didn't work because we have a pointer-to-const, and the
overload doesn't accept such. In order to make my style tweaks to the
patch, I first changed the overload to accept a pointer-to-const, and
then changed the diagnostic printing layer to also use
a pointer-to-const, cleaning up a gross line of code along the way.
llvm-svn: 138854
overridden methods to diagnose their type mismatch.
This is a general solution for previous fixes
for // rdar://6191214 and // rdar://9352731
and removes lots of duplicate code.
llvm-svn: 137222
situation. When a class explicitly or implicitly (through inheritance)
"conformsTo" two protocols which conflict (have methods which conflict).
This patch fixes the previous patch where warnings were coming out in
non-deterministic order. This is 2nd part of // rdar://6191214.
llvm-svn: 137055
ActOnStartOfSwitchStmt (i.e. before binding up a full-expression)
instead of ActOnFinishSwitchStmt.
Among other things, this means that property l-values are properly
converted inside the full-expression.
llvm-svn: 137014
situation. When a class explicitly or implicitly (through inheritance)
"conformsTo" two protocols which conflict (have methods which conflict).
This is 2nd part of // rdar://6191214.
llvm-svn: 136927
special diagnostic for ARC ownership-qualified types. We wouldn't want
to expose Objective-C programmers to the term "POD", would we? Fixes
<rdar://problem/9772982>.
llvm-svn: 136558
masks an existing method in its primary class, class extensions,
and primary class's non-optional protocol methods; as primary
class, or one of its subclass's will implement this method.
This warning has potential of being noisy so it has its own
group. // rdar://7020493
llvm-svn: 136426
for-in statements; specifically, make sure to close over any
temporaries or cleanups it might require. In ARC, this has
implications for the lifetime of the collection, so emit it
with a retain and release it upon exit from the loop.
rdar://problem/9817306
llvm-svn: 136204
@interface Foo : NSObject
@property (readonly) id myProp;
@end
@implementation Foo
@synthesize myProp;
@end
t.m:9:13: error: ARC forbids synthesizing a property of an Objective-C object with unspecified storage attribute
@synthesize myProp;
^
which is fine, we want the ownership of the synthesized ivar to be explicit. But we should _not_ emit an error
for the following cases, because we can get the ownership either from the declared ivar or from the property type:
@interface Foo : NSObject {
__weak id _myProp1;
id myProp2;
}
@property (readonly) id myProp1;
@property (readonly) id myProp2;
@property (readonly) __strong id myProp3;
@end
@implementation Foo
@synthesize myProp1 = _myProp1;
@synthesize myProp2;
@synthesize myProp3;
@end

rdar://9844006.
llvm-svn: 136155
declared in protocol in the class qualified by the
protocol have type conflicts. To reduce amount of
noise, this is done when class is implemented.
// rdar://9352731
llvm-svn: 135890
will be rejected with a compilation error in ARC mode, and a compiler warning otherwise.
This may cause breakage in non-arc (and arc) tests which don't expect warning/error. Feel free
to fix the tests, or reverse the patch, if I am unavailable. // rdar://9818354 - WIP
llvm-svn: 135740
__unknown_anytype, and rewrite such message sends correctly.
I had to bite the bullet and actually add a debugger support mode for this
one, which is a bit unfortunate, but there really isn't anything else
I could imagine doing; this is clearly just debugger-specific behavior.
llvm-svn: 135051
block pointers) that don't have any qualification to be POD types. We
were previously considering them to be non-POD types, because this was
convenient in C++ for is_pod-like traits. However, we now end up
inferring lifetime in such cases (template arguments infer __strong),
so it is not necessary.
Moreover, we want rvalues of object type (which have their lifetime
stripped) to be PODs to allow, e.g., va_arg(arglist, id) to function
properly. Fixes <rdar://problem/9758798>.
llvm-svn: 134993
For this sample:
@interface Foo
@property id x;
@end
we get:
t.m:2:1: error: ARC forbids properties of Objective-C objects with unspecified storage attribute
@property id x;
^
1 error generated.
The error should be imposed on the implementor of the interface, not the user. If the user uses
a header of a non-ARC library whose source code he does not have, we are basically asking him to
go change the header of the library (bad in general), possible overriding how the property is
implemented if he gets confused and says "Oh I'll just add 'copy' then" (even worse).
Second issue is that we don't emit any error for 'readonly' properties, e.g:
@interface Foo
@property (readonly) id x; // no error here
@end
@implementation Foo
@synthesize x; // no error here too
@end
We should give an error when the implementor is @synthesizing a property which doesn't have
any storage specifier; this is when the explicit specifier is important, because we are
going to create an ivar and we want its ownership to be explicit.
Related improvements:
-OBJC_PR_unsafe_unretained turned out to not fit in ObjCPropertyDecl's bitfields, fix it.
-For properties of extension classes don't drop PropertyAttributesAsWritten values.
-Have PropertyAttributesAsWritten actually only reflect what the user wrote
rdar://9756610.
llvm-svn: 134960
require destruction and there is possibility of that without
construction. Thanks Johnm for review and suggestions offline.
// rdar://9535237.
llvm-svn: 134906
structure to hold inferred information, then propagate each invididual
bit down to -cc1. Separate the bits of "supports weak" and "has a native
ARC runtime"; make the latter a CodeGenOption.
The tool chain is still driving this decision, because it's the place that
has the required deployment target information on Darwin, but at least it's
better-factored now.
llvm-svn: 134453
cast type has no ownership specified, implicitly "transfer" the ownership of the cast'ed type
to the cast type:
id x;
(NSString**)&x; // Casting as (__strong NSString**).
llvm-svn: 134275
specifiers. Fixes <rdar://problem/9607158>." because it causes false positives
on some code that uses CF toll free bridging.
- I'll let Doug or Ted figure out the right fix here, possibly just to accept
any pointer type.
llvm-svn: 134041
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
arithmetic into a couple of common routines. Use these to make the
messages more consistent in the various contexts, especially in terms of
consistently diagnosing binary operators with invalid types on both the
left- and right-hand side. Also, improve the grammar and wording of the
messages some, handling both two pointers and two (different) types.
The wording of function pointer arithmetic diagnostics still strikes me
as poorly phrased, and I worry this makes them slightly more awkward if
more consistent. I'm hoping to fix that with a follow-on patch and test
case that will also make them more helpful when a typedef or template
type parameter makes the type completely opaque.
Suggestions on better wording are very welcome, thanks to Richard Smith
for some initial help on that front.
llvm-svn: 133906
to turn off warning on those properties which follow Cocoa naming
convention for retaining objects and yet they were not meant for
such purposes. Also, perform consistancy checking for declared
getters of such methods. // rdar://9636091
llvm-svn: 133849
they should still be officially __strong for the purposes of errors,
block capture, etc. Make a new bit on variables, isARCPseudoStrong(),
and set this for 'self' and these enumeration-loop variables. Change
the code that was looking for the old patterns to look for this bit,
and change IR generation to find this bit and treat the resulting
variable as __unsafe_unretained for the purposes of init/destroy in
the two places it can come up.
llvm-svn: 133243
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
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
There are APIs, e.g. [NSValue valueWithBytes:objCType:], which use the encoding to find out
the size of an object pointed to by a pointer. Make things safer by making it illegal to @encode
incomplete types.
llvm-svn: 131364
bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.
Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.
Fixes <rdar://problem/9402499>.
llvm-svn: 131065
invalid expression rather than the far-more-generic "error". Fixes a
mild regression in error recovery uncovered by the GCC testsuite.
llvm-svn: 130128
-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.
Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.
This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.
llvm-svn: 130051
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
definitely have a path leading to them, and possibly have a path leading
to them; reflect that distinction in the warning text emitted.
llvm-svn: 129126
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
declaration as this results in a confusing error message,
instead of message related to missing property declaration.
// rdar://9106929
llvm-svn: 127682
diagnostic. Also, these attributes are commonly written with macros which we
actually pre-define, so instead of expanding the macro location, refer to the
instantiation location and name it using the macro loc.
llvm-svn: 127219
that was ignored in a few places (most notably, code
completion). Introduce Selector::getNameForSlot() for the common case
where we only care about the name. Audit all uses of
getIdentifierInfoForSlot(), switching many over to getNameForSlot(),
fixing a few crashers.
Fixed <rdar://problem/8939352>, a code-completion crasher.
llvm-svn: 125977
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
is unqualified but its initialized is qualified.
This is for c only and fixes the imm. problem.
c++ is more involved and is wip.
// rdar://8979379
llvm-svn: 125386
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
The rationale is that it is highly likely that the user's getter/setter isn't atomically implemented. Off by default.
Addresses rdar://8782645.
-Wcustom-atomic-properties and -Wimplicit-atomic-properties are under the -Watomic-properties group.
llvm-svn: 124609
error: no super class declared in @interface for 'XXX'
to be:
error: 'X' cannot use 'super' because it is a root class
The latter explains what the user actually did wrong.
Fixes: <rdar://problem/8904409>
llvm-svn: 124074
earlier revisions Clang was incorrectly warning
about an incomplete @implementation when a property
was getting synthesized. This got fixed somewhere
down the line.
llvm-svn: 123939
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
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
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
@property declaration to the autogenerated methods. I'm uncertain
whether this should apply to attributes in general, but these are
a reasonable core.
Implements rdar://problem/8617301
llvm-svn: 118676
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
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
declaration have the 'readwrite' attribute. This is a common case, and we can issue a more lucid diagnostic.
Fixes <rdar://problem/7629420>.
llvm-svn: 117045
don't repeatedly loop through identifiers, correcting the same typo'd
identifier over and over again.
We still bail out after 20 typo corrections, but this should help
improve performance in the common case where we're typo-correcting
because the user forgot to include a header.
llvm-svn: 116901
we did was an acceptable lookup. If it is, then we can re-use that
lookup result. If it isn't, we have to perform the lookup again. This
is almost surely the cause behind the mysterious typo.m failures on
some builders; we were getting the wrong lookup results returned.
llvm-svn: 116586
identifiers to determine good typo-correction candidates. Once we've
identified those candidates, we perform name lookup on each of them
and the consider the results.
This optimization makes typo correction > 2x faster on a benchmark
example using a single typo (NSstring) in a tiny file that includes
Cocoa.h from a precompiled header, since we are deserializing far less
information now during typo correction.
There is a semantic change here, which is interesting. The presence of
a similarly-named entity that is not visible can now affect typo
correction. This is both good (you won't get weird corrections if the
thing you wanted isn't in scope) and bad (you won't get good
corrections if there is a similarly-named-but-completely-unrelated
thing). Time will tell whether it was a good choice or not.
llvm-svn: 116528
properties.
1. Generates the AST for lexical info. of accessing
getter/setter methods using dot-syntax notation.
This fixes //rdar: //8528170.
2. Modifes rewriter to handle the AST putout in 1.
3. Supportes in rewriter ObjCImplicitSetterGetter ASTs.
llvm-svn: 116237
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
(on functions with no pointer arguments) but only when
the attribute has not been coming from a macro
instantiation in a header file. Fixes first part
of radar 6857843.
llvm-svn: 114860
of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
llvm-svn: 114225
previous use of a synthesized 'ivar' with property of same name
declared as @dynamic. In this case, 'ivar' is in the
inherited class and no diagnostics should be issued.
llvm-svn: 111940
GCC emits a warning instead of an error when using an unavailable Objective-C protocol, so now
Clang's behavior is more strict in this case, but more consistent. We will need to see how much
this fires on real code and determine whether this case should be downgraded to a warning.
Fixes <rdar://problem/8213093>.
llvm-svn: 109033
the test case right (for the noreturn warning) because the CFG
doesn't support @try yet, but the test case is now present when
we do properly implement CFG support for @try...@catch.
llvm-svn: 107203
unimplemented property warning for properties
coming from class's conformin protocol. It also
simplifies the algorithm in the process.
Fixes radar 8035776.
llvm-svn: 107174
(-Wunused-exception-parameter) than normal variables, since it's more
common to name and then ignore an exception parameter. This warning is
neither enabled by default nor by -Wall. Fixes <rdar://problem/7931045>.
llvm-svn: 102931
(which is ill-formed) with an initializer list. Also, change the
fallback from an assertion to a generic error message, which is far
friendlier. Fixes <rdar://problem/7730948>.
llvm-svn: 102930
conforms to a protocol as one of its super classes does. This is because
conforming super class will implement the property. This implements
new warning rules for unimplemented properties (radar 7884086).
llvm-svn: 102919
function-parameter checking and splitting it into the normal
ActOn*/Build* pair in Sema. We now use VarDecl to represent the @catch
parameter rather than the ill-fitting ParmVarDecl.
llvm-svn: 102347
method parameter, provide a note pointing at the parameter itself so
the user does not have to manually look for the function/method being
called and match up parameters to arguments. For example, we now get:
t.c:4:5: warning: incompatible pointer types passing 'long *' to
parameter of
type 'int *' [-pedantic]
f(long_ptr);
^~~~~~~~
t.c:1:13: note: passing argument to parameter 'x' here
void f(int *x);
^
llvm-svn: 102038
sends. Major changes include:
- Expanded the interface from two actions (ActOnInstanceMessage,
ActOnClassMessage), where ActOnClassMessage also handled sends to
"super" by checking whether the identifier was "super", to three
actions (ActOnInstanceMessage, ActOnClassMessage,
ActOnSuperMessage). Code completion has the same changes.
- The parser now resolves the type to which we are sending a class
message, so ActOnClassMessage now accepts a TypeTy* (rather than
an IdentifierInfo *). This opens the door to more interesting
types (for Objective-C++ support).
- Split ActOnInstanceMessage and ActOnClassMessage into parser
action functions (with their original names) and semantic
functions (BuildInstanceMessage and BuildClassMessage,
respectively). At present, this split is onyl used by
ActOnSuperMessage, which decides which kind of super message it
has and forwards to the appropriate Build*Message. In the future,
Build*Message will be used by template instantiation.
- Use getObjCMessageKind() within the disambiguation of Objective-C
message sends vs. array designators.
Two notes about substandard bits in this patch:
- There is some redundancy in the code in ParseObjCMessageExpr and
ParseInitializerWithPotentialDesignator; this will be addressed
shortly by centralizing the mapping from identifiers to type names
for the message receiver.
- There is some #if 0'd code that won't likely ever be used---it
handles the use of 'super' in methods whose class does not have a
superclass---but could be used to model GCC's behavior more
closely. This code will die in my next check-in, but I want it in
Subversion.
llvm-svn: 102021
LookupInObjCMethod. Doing so allows all sorts of invalid code
to slip through to codegen. This patch does not change the
AST representation of super, though that would now be a natural
thing to do since it can only be in the receiver position and
in the base of a ObjCPropertyRefExpr.
There are still several ugly areas handling super in the parser,
but this is definitely a step in the right direction.
llvm-svn: 100959
destination type for initialization, assignment, parameter-passing,
etc. The main issue fixed here is that we used rather confusing
wording for diagnostics such as
t.c:2:9: warning: initializing 'char const [2]' discards qualifiers,
expected 'char *' [-pedantic]
char *name = __func__;
^ ~~~~~~~~
We're not initializing a 'char const [2]', we're initializing a 'char
*' with an expression of type 'char const [2]'. Similar problems
existed for other diagnostics in this area, so I've normalized them all
with more precise descriptive text to say what we're
initializing/converting/assigning/etc. from and to. The warning for
the code above is now:
t.c:2:9: warning: initializing 'char *' from an expression of type
'char const [2]' discards qualifiers [-pedantic]
char *name = __func__;
^ ~~~~~~~~
Fixes <rdar://problem/7447179>.
llvm-svn: 100832
instead it crashes on them. We might extend this attribute to work on methods, but for
now fix the crasher. Addresses <rdar://problem/7670939>.
llvm-svn: 96723
those declared in it. This is to allow duplicate
property diagnostics for properties declared in class extensions
multiple times (radar 7629420) and for future use.
llvm-svn: 96276
attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.
llvm-svn: 95571
checking. It passes all existing tests, and the diagnostics have been
refined to provide better range information (we now highlight
individual format specifiers) and more precise wording in the
diagnostics.
llvm-svn: 94837
corresponding @interface, provide a note showing which interface we're
referring to. This note has the fix-it hint on it.
Also, don't automatically apply fix-it hints for notes. They're meant
to express fix-its that would change semantics.
llvm-svn: 92870
interface, suggest correction of typos. For example, given:
@interface NSString
@end
@implementation NSstring
@end
we'll warn with:
t.m:4:19: warning: cannot find interface declaration for 'NSstring';
did you mean 'NSString'?
@implementation NSstring
^
However, since this is just a warning, we don't provide a fix-it
hint. Good idea, Ted!
llvm-svn: 92488
constructs:
- Instance variable lookup ("foo->ivar" and, in instance methods, "ivar")
- Property name lookup ("foo.prop")
- Superclasses
- Various places where a class name is required
- Protocol names (e.g., id<proto>)
This seems to cover many of the common places where typos could occur.
llvm-svn: 92449
declarations of abort(), and two, we mark it noreturn. Missing the latter
shows up in one of the "embarassing" tests (from the thread on llvmdev
"detailed comparison of generated code size for LLVM and other compilers").
llvm-svn: 91515
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
into pretty much everything about overload resolution in order to wean
BuildDeclarationNameExpr off LookupResult::getAsSingleDecl(). Replace
UnresolvedFunctionNameExpr with UnresolvedLookupExpr, which generalizes the
idea of a non-member lookup that we haven't totally resolved yet, whether by
overloading, argument-dependent lookup, or (eventually) the presence of
a function template in the lookup results.
Incidentally fixes a problem with argument-dependent lookup where we were
still performing ADL even when the lookup results contained something from
a block scope.
Incidentally improves a diagnostic when using an ObjC ivar from a class method.
This just fell out from rewriting BuildDeclarationNameExpr's interaction with
lookup, and I'm too apathetic to break it out.
The only remaining uses of OverloadedFunctionDecl that I know of are in
TemplateName and MemberExpr.
llvm-svn: 89544
specification of 'assign' (no warning to be issued),
when a continuation class makes a 'readonly' attribute
'readwrite' but also specifies the 'assign' attribute.
(this matches gcc's behavior and prevents exessive
warnings)/
llvm-svn: 86297
used in a conditional expression by finding the most-derived common
super class of the two and qualifies the resulting type by the
intersection of the protocl qualifier list of the two objective-c
pointer types. ( this is continuation of radar 7334235).
llvm-svn: 85554
notation. There is still an issue accessing field of a 'Class''s isa
in legacy code using dot field access notation (as noted in the test case)
but unrelated to this patch.
llvm-svn: 82555
1) Issue digsnostics in non-fragile ABI, when an expression
evaluates to an interface type (except when it is used to
access a non-fragile ivar).
2) Issue unsupported error in fragile ABI when an expression
evaluates to an interface type (except when it is used to
access a fragile ivar).
llvm-svn: 80860
-Wmost group (too noisy). Placed warning on parameter type
misatch between methods in sub and super class under
-Wsuper-class-method-mismatch (also too noisy).
llvm-svn: 79745
is found. Instead of complaining about a generic "unused expr",
emit:
t.m:7:3: warning: property access result unused - getters should not have side effects
While objc property getters *could* have side effects, according to
the language best practices, they *shouldn't*. Hopefully the
diagnostic now gets this across.
llvm-svn: 79192
declarations (and not function pointers). This is consistent with GCC. Accepting
this attribute on function pointers means that the attribute should be treated
as a type qualifier, which apparently is not what GCC does. We obviously can
change this later should we desire to enhance the 'malloc' attribute in this
way.
llvm-svn: 79060
attaching to Objective-C methods (which mirrors GCC's behavior) and to allow the
return type of the function to be an Objective-C pointer or Block pointer (which
GCC also accepts).
Along the way, add 'const' to some of the pointer arguments of various utility
functions...
llvm-svn: 79040
Remove XFAIL from 'conditional-expr-4.m' test case (which would have caught this).
Also tweaked several aspects of the test to jive with the current type checking.
llvm-svn: 77453
Enhance test case to cover 'isa' access on interface types (clang produces an error, GCC produces a warning).
Still need back-end CodeGen for ObjCIsaExpr.
llvm-svn: 76979
- Move Sema::ObjCQualifiedIdTypesAreCompatible(), Sema::QualifiedIdConformsQualifiedId(), and a couple helper functions to ASTContext.
- Change ASTContext::canAssignObjCInterfaces() to use ASTContext:: ObjCQualifiedIdTypesAreCompatible().
- Tweak several test cases to accommodate the new/improved type checking.
llvm-svn: 76830
value. This is on by default, and controlled by -Wreturn-type (-Wmost
-Wall). I believe there should be very few false positives, though
the most interesting case would be:
int() { bar(); }
when bar does:
bar() { while (1) ; }
Here, we assume functions return, unless they are marked with the
noreturn attribute. I can envision a fixit note for functions that
never return normally that don't have a noreturn attribute to add a
noreturn attribute.
If anyone spots other false positives, let me know!
llvm-svn: 76821
an interface/category with its implementation (if one exists).
- Introduce ObjCInterfaceDecl::get/setImplementation() and ObjCCategoryDecl::get/setImplementation() that use the above methods.
- Add a compiler error for when a category is reimplemented.
llvm-svn: 76508
Objective-C pointers to using ObjCObjectPointerType.
Now the checking for 'attribute ((nonnull))' in Sema doesn't emit an error when
trying to apply that attribute to a parameter that is an Objective-C pointer
(this is a regression).
To prevent this regression from occuring in the future, the 'nonnull.c' test was
moved to test/SemaObjC and renamed 'nonnull.m'. I also enhanced the tests to
show that function calls involved a NULL Objective-C pointer constant does not
trigger a warning. This is consistent with GCC, but should likely be fixed.
llvm-svn: 75856
This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).
This patch also adds Type::isObjCBuiltinType().
This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.
llvm-svn: 75808
- These kinds of "shotgun" tests are very slow, and do not belong in the
regression suite. If these kinds of tests are regarded to have value, they
should be added to the LLVM test-suite.
- I would actually like to remove all of these tests, but I left Sema/carbon.c
and SemaObjC/cocoa.m...
llvm-svn: 75399
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
C++. This logic is required to trigger implicit instantiation of
function templates and member functions of class templates, which will
be implemented separately.
This commit includes support for -Wunused-parameter, printing warnings
for named parameters that are not used within a function/Objective-C
method/block. Fixes <rdar://problem/6505209>.
llvm-svn: 73797
hack which introduces some strange inconsistencies in compatibility
for block pointers.
Note that unlike an earlier revision proposed on cfe-commits, this patch
still allows declaring block pointers without a prototype.
llvm-svn: 73041
in merge_types. It is incomplete. We probably want to issue
a warning if user attempts to change the attribute from __weak to
__strong or vice-vera. It also assumes that a __weak/__strong
attribute can not be specified with other (currently one) type
attriute.
llvm-svn: 72711
properties at the moment:
1. It allows stuff like "__strong id x; __weak id x;".
2. For constructs like "__strong id x; id x;", subsequent references to
x lose the objc_gc attribute.
3. This incorrectly allows merges involving the address_space attribute.
4. Constructs like "id x; /* some code using x */ __weak id x;" don't
apply the objc_gc attribute consistently to all uses of x.
The first three can probably be fixed relatively easily; the fourth
would be extremely difficult to fix.
llvm-svn: 72683
and objects of this class are derived from 'NSProxy'.
Under such conditions, which means that every method possible is
implemented in the class, we should not issue "Method definition not found"
warnings.
llvm-svn: 72267
Fariborz Jahanian