summaryrefslogtreecommitdiffstats
path: root/clang/lib/Sema/SemaObjCProperty.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't compute a patched/semantic storage class.Rafael Espindola2013-04-031-1/+0
| | | | | | | | | | | For variables and functions clang used to store two storage classes. The one "as written" in the code and a patched one, which, for example, propagates static to the following decls. This apparently is from the days clang lacked linkage computation. It is now redundant and this patch removes it. llvm-svn: 178663
* Objective-C: Provide fixit hints when warningFariborz Jahanian2013-04-021-0/+2
| | | | | | | | about 'isa' ivar being explicitely accessed when base is a user class object reference. // rdar://13503456 llvm-svn: 178562
* Objective-C: Property declaration overiding one inFariborz Jahanian2013-03-251-0/+2
| | | | | | | its super class or protocols inherit their availability/deprecated attribute. // rdar://13467644 llvm-svn: 177948
* Objective-C: Tighten the rules when warningFariborz Jahanian2013-03-211-1/+2
| | | | | | | | | | is issused for on overriding 'readwrite' property which is not auto-synthesized. Buttom line is that if hueristics determine that there will be a user implemented setter, no warning will be issued. // rdar://13388503 llvm-svn: 177662
* Objective-C: In my last path, also checkFariborz Jahanian2013-03-121-1/+2
| | | | | | | | for existence of user setter before issuing the warning about non-synthesizable property. // rdar://13388503 llvm-svn: 176906
* Objective-C: Issue warning in couple of obscure casesFariborz Jahanian2013-03-121-3/+21
| | | | | | | | | | when property autosynthesis does not synthesize a property. When property is declared 'readonly' in a super class and is redeclared 'readwrite' in a subclass. When a property autosynthesis causes it to share 'ivar' with another property. // rdar://13388503 llvm-svn: 176889
* objective-C: synthesize properties in order of theirFariborz Jahanian2013-02-141-7/+10
| | | | | | | | declarations to synthesize their ivars in similar determinstic order so they are laid out in a determinstic order. // rdar://13192366 llvm-svn: 175214
* objective-C: When implementing custom accessor method forFariborz Jahanian2013-02-141-0/+27
| | | | | | | | a property, the -Wdirect-ivar-access should not warn when accessing the property's synthesized instance variable. // rdar://13142820 llvm-svn: 175195
* objective-C: Fixes a bogus warning due to not settingFariborz Jahanian2013-02-101-3/+13
| | | | | | | | the "nonatomic" attribute in property redeclaration in class extension. Also, improved on diagnostics in this area while at it. // rdar://13156292 llvm-svn: 174821
* QoI: -Wreadonly-iboutlet-property should have the warning's location on the ↵Ted Kremenek2013-02-091-2/+2
| | | | | | | | | | property. There's no need to refer to the @implementation at all. Fixes <rdar://problem/13186515> llvm-svn: 174802
* objective-C: don't issue bogus warning aboutFariborz Jahanian2013-02-081-12/+30
| | | | | | | | "auto-synthesized may not work correctly with 'nib' loader" when 'readonly' property is redeclared 'readwrite' in class extension. // rdar://13123861 llvm-svn: 174775
* Eliminate Sema::CompareProperties(), which was walking over a pile ofDouglas Gregor2013-01-211-56/+66
| | | | | | | | | lexical declarations looking for properties when we could more efficiently check for property mismatches at property declaration time. Good for ~1% of -fsyntax-only time when most of the properties we're checking against come from an AST file. llvm-svn: 173079
* Eliminate the oddly-named Sema::ComparePropertiesInBaseAndSuper, whichDouglas Gregor2013-01-211-45/+28
| | | | | | | | | | did a redundant traversal of the lexical declarations in the superclass. Instead, when we declare a new property, look into the superclass to see whether we're redeclaring the property. Goot for 1% of -fsyntax-only time on Cocoa.h and a little less than 3% on my modules test case. llvm-svn: 173073
* Replace some unnecessary O(N^2) lookups for properties withDouglas Gregor2013-01-211-40/+53
| | | | | | | DeclContext lookups. The performance win is negligible in my tests, but it's the Right Thing To Do (TM). llvm-svn: 173068
* Rework the traversal of Objective-C categories and extensions toDouglas Gregor2013-01-161-17/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | consider (sub)module visibility. The bulk of this change replaces myriad hand-rolled loops over the linked list of Objective-C categories/extensions attached to an interface declaration with loops using one of the four new category iterator kinds: visible_categories_iterator: Iterates over all visible categories and extensions, hiding any that have their "hidden" bit set. This is by far the most commonly used iterator. known_categories_iterator: Iterates over all categories and extensions, ignoring the "hidden" bit. This tends to be used for redeclaration-like traversals. visible_extensions_iterator: Iterates over all visible extensions, hiding any that have their "hidden" bit set. known_extensions_iterator: Iterates over all extensions, whether they are visible to normal name lookup or not. The effect of this change is that any uses of the visible_ iterators will respect module-import visibility. See the new tests for examples. Note that the old accessors for categories and extensions are gone; there are *Raw() forms for some of them, for those (few) areas of the compiler that have to manipulate the linked list of categories directly. This is generally discouraged. Part two of <rdar://problem/10634711>. llvm-svn: 172665
* Use Decl::getAvailability() rather than checking for the "unavailable"Douglas Gregor2013-01-081-1/+2
| | | | | | | attribute when determining whether we need to see an implementation of a property. Fixes <rdar://problem/12958191>. llvm-svn: 171877
* Revert r170500. It over-zealously converted *ALL* things named Attributes, ↵Bill Wendling2012-12-201-118/+118
| | | | | | which is wrong here. llvm-svn: 170721
* objective-C: Don't warn of unimplemented property of protocols in Fariborz Jahanian2012-12-191-4/+15
| | | | | | | category, when those properties will be implemented in category's primary class or one of its super classes. // rdar://12568064 llvm-svn: 170573
* Rename the 'Attributes' class to 'Attribute'. It's going to represent a ↵Bill Wendling2012-12-191-118/+118
| | | | | | single attribute in the future. llvm-svn: 170500
* [objc] For the ARC error that is emitted when a synthesized property ↵Argyrios Kyrtzidis2012-12-121-3/+5
| | | | | | | | | | | | | | | implementation has inconsistent ownership with the backing ivar, point the error location to the ivar. Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed. Also provide the location of @synthesize via a note. This also fixes the problem where an auto-synthesized property would emit an error without any location. llvm-svn: 170039
* Sort all of Clang's files under 'lib', and fix up the broken headersChandler Carruth2012-12-041-5/+5
| | | | | | | | | | | | | uncovered. This required manually correcting all of the incorrect main-module headers I could find, and running the new llvm/utils/sort_includes.py script over the files. I also manually added quite a few missing headers that were uncovered by shuffling the order or moving headers up to be main-module-headers. llvm-svn: 169237
* Address Jordan's review: comments, spaces.Anna Zaks2012-10-311-3/+3
| | | | llvm-svn: 167091
* Fix Objective-C implicit property synthesis for C++ classes so we use valid Eli Friedman2012-10-181-10/+15
| | | | | | | | | | | source locations in places where it is necessary for diagnostics. By itself, this causes assertions, so while I'm here, also fix property synthesis for properties of C++ class type so we use so we properly set up a scope and mark variable declarations. <rdar://problem/12514189>. llvm-svn: 166219
* Factor CollectClassPropertyImplementations out of Sema into ASTAnna Zaks2012-10-181-42/+12
| | | | | | This would make it possible for the analyzer to use the function. llvm-svn: 166210
* Move Sema::PropertyIfSetterOrGetter to ObjCMethodDecl::findPropertyDecl.Jordan Rose2012-10-101-91/+0
| | | | | | | | 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
* Change Sema::PropertyIfSetterOrGetter to make use of isPropertyAccessor.Jordan Rose2012-10-101-35/+34
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Rename ObjCMethodDecl::isSynthesized to isPropertyAccessor.Jordan Rose2012-10-101-4/+4
| | | | | | | | | | | | | 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
* Make getDefaultSynthIvarName() a member of ObjCPropertyDecl.Anna Zaks2012-09-271-11/+1
| | | | llvm-svn: 164789
* [analyzer] Add experimental ObjC invalidation method checker.Anna Zaks2012-09-261-1/+2
| | | | | | | | | | | This checker is annotation driven. It checks that the annotated invalidation method accesses all ivars of the enclosing objects that are objects of type, which in turn contains an invalidation method. This is driven by __attribute((annotation("objc_instance_variable_invalidator")). llvm-svn: 164716
* objective-C: when diagnosing deprecated/unavailable usage ofFariborz Jahanian2012-09-211-0/+53
| | | | | | | setter or getter backing a deprecated/unavailable property, also not location of the property. // rdar://12324295 llvm-svn: 164412
* objective-C: don't warn about class extension property's Fariborz Jahanian2012-09-171-1/+3
| | | | | | | missing 'assign' attribute as it is determined by its overridden property in primary class. // rdar://12214070 llvm-svn: 164080
* objective-C: peroform property attribute consistencyFariborz Jahanian2012-09-171-1/+3
| | | | | | | checking on property declared in class extension. // rdar://12214070 llvm-svn: 164053
* Fix some dead stores which the static analyzer warned about. No functionalityRichard Smith2012-09-141-2/+1
| | | | | | change (the problematic cases in ParseDecl.cpp are currently impossible). llvm-svn: 163920
* objective-C: When checking for valid overriden propertyFariborz Jahanian2012-08-241-1/+7
| | | | | | | | in class extension, assume default is rewdwrite and don't issue any diagnostics, privided other ownership models are ok. llvm-svn: 162583
* Fix undefined behavior: member function calls where 'this' is a null pointer.Richard Smith2012-08-231-2/+4
| | | | llvm-svn: 162430
* Reduce duplicated hash map lookups.Benjamin Kramer2012-08-221-2/+2
| | | | llvm-svn: 162361
* change function name in my last patch.Fariborz Jahanian2012-08-211-3/+3
| | | | | | // rdar://12103400 llvm-svn: 162320
* objective-C: Change rules for overriding properties in Fariborz Jahanian2012-08-211-13/+25
| | | | | | | | | class extensions a little. clang now allows readonly property with no ownership rule (assign, unsafe_unretained, weak, retain, strong, or copy) with a readwrite property with an ownership rule. // rdar://12103400 llvm-svn: 162319
* Screw around with ObjCRuntime some more, changing theJohn McCall2012-08-211-1/+1
| | | | | | | | diagnostics for bad deployment targets and adding a few more predicates. Includes a patch by Jonathan Schleifer to enable ARC for ObjFW. llvm-svn: 162252
* Fix a pair of bugs relating to properties in ARC.John McCall2012-08-201-1/+18
| | | | | | | | | | | | | | | | | | | | First, when synthesizing an explicitly strong/retain/copy property of Class type, don't pretend during compatibility checking that the property is actually assign. Instead, resolve incompatibilities by secretly changing the type of *implicitly* __unsafe_unretained Class ivars to be strong. This is moderately evil but better than what we were doing. Second, when synthesizing the setter for a strong property of non-retainable type, be sure to use objc_setProperty. This is possible when the property is decorated with the NSObject attribute. This is an ugly, ugly corner of the language, and we probably ought to deprecate it. The first is rdar://problem/12039404; the second was noticed by inspection while fixing the first. llvm-svn: 162244
* Remove unused variables.Benjamin Kramer2012-08-081-2/+0
| | | | llvm-svn: 161483
* Attaching comments to declarations during parsing: handle more Objective-C ↵Dmitri Gribenko2012-07-131-0/+2
| | | | | | declarations. llvm-svn: 160156
* fix a typo in my last commit. I thought I recompiled,Fariborz Jahanian2012-06-291-1/+1
| | | | | | but apparently I did not. llvm-svn: 159452
* objc diagnostic: pass IdentifierInfo* to the diagnostic systemFariborz Jahanian2012-06-291-2/+2
| | | | | | to produce quotes instead of adding qoute to the test. llvm-svn: 159450
* objective-c mrc: Issue warning for mrc, as is done for arc, whenFariborz Jahanian2012-06-271-2/+1
| | | | | | | property retains a block object as it could be on the stack. // rdar://11761511 llvm-svn: 159293
* objc: tweak my last patch to warn if class extensionFariborz Jahanian2012-06-201-1/+1
| | | | | | has not overridden the property. // rdar://11656982 llvm-svn: 158871
* objective-c: Normally, a property cannot be both 'readonly' and having a Fariborz Jahanian2012-06-201-6/+80
| | | | | | | | | | "write" attribute (copy/retain/etc.). But, property declaration in primary class and protcols are tentative as they may be overridden into a 'readwrite' property in class extensions. Postpone diagnosing such warnings until the class implementation is seen. // rdar://11656982 llvm-svn: 158869
* objc: improved diagnostic when property autosynthesis may causeFariborz Jahanian2012-06-201-17/+19
| | | | | | change in behavior. // rdar://11671080 llvm-svn: 158828
* Restructure how the driver communicates information about theJohn McCall2012-06-201-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | target Objective-C runtime down to the frontend: break this down into a single target runtime kind and version, and compute all the relevant information from that. This makes it relatively painless to add support for new runtimes to the compiler. Make the new -cc1 flag, -fobjc-runtime=blah-x.y.z, available at the driver level as a better and more general alternative to -fgnu-runtime and -fnext-runtime. This new concept of an Objective-C runtime also encompasses what we were previously separating out as the "Objective-C ABI", so fragile vs. non-fragile runtimes are now really modelled as different kinds of runtime, paving the way for better overall differentiation. As a sort of special case, continue to accept the -cc1 flag -fobjc-runtime-has-weak, as a sop to PLCompatibilityWeak. I won't go so far as to say "no functionality change", even ignoring the new driver flag, but subtle changes in driver semantics are almost certainly not intended. llvm-svn: 158793
* objective-c: warn when autosynthesizing a property which has sameFariborz Jahanian2012-06-191-0/+16
| | | | | | | | 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
OpenPOWER on IntegriCloud