Property with attribute 'retain (or strong)' was selected for synthesis
This is a new error that appeared after updating from xcode 9.2 to xcode 9.3. This happens when building my test project, one of my variables is throwing this error:
#property (nonatomic, retain) NSNumber* myVariable;
This has been a 'retain' property for a very long time in this old code base, does anyone have any idea why there is suddenly an error?
Additional information:
There are several of the same name variables throughout the project, all defined the same way in various #protocol files. These protocols are all at some point #import into the test project, which throws the error when it tries to build.
Is there additional information I can provide?
Edit
In the process of making this error recreate-able it became apparent that the error is due to one of the duplicate variable names within the project having a 'readonly' property rather than the 'retain' that the rest have. I'm posting the recreation and answer in case anyone else has an old project or typo throwing the same error.
This can be recreated:
Create a new single view ios project
Use objective C and include unit tests
Add a header file that is an #protocol containing the given 'myVariable'
Add a second #protocol header file matching the first, then change 'retain' to 'readonly'
Add a new NSObject
#interface MyObject : NSObject <MyProtocol, MyProtocol2>
In the implementation of MyObject #synthesize myVariable;
Run unit tests - error should appear
The problem came down to not realizing that one of the variables with the same name was a readonly property while the others were all retain. It seems that xcode 9.2 and previous never caught such an error either but xcode 9.3 now does. My solution was to change the readonly to match the retain variables.
A better solution for others may be to rename the readonly variable to denote it is unique.
Related
I've been using Typhoon in my app for a while. After a recent upgrade to Typhoon v3.2.8, I've been getting a new info-level message logged into the console on app launch:
2015-09-04 15:27:07.761 MYApp[1348:10138960] -[TyphoonAssembly
activateWithFactory:collaborators:][Line 280] [info] * Warning *
Can't find assembly of type MYCoreAssembly. Is this intentional? The
property 'coreAssembly' in class MYApplicationAssembly will be left as
nil.
In my app, Typhoon is Info.plist activated, with two collaborating assemblies: MYApplicationAssembly and MYCoreAssembly.
My app delegate has several Typhoon-injected properties, including the MYApplicationAssembly instance. The MYApplicationAssembly implementation "collaborates with" the MYCoreAssembly assembly. The relevant interface declarations are:
#interface MYApplicationAssembly : TyphoonAssembly
#property (nonatomic, readonly) MYCoreAssembly *coreAssembly;
- (MYHomeViewController *)homeViewController;
#end
#interface MYCoreAssembly : TyphoonAssembly
- (id)someCoreThing;
#end
I'd like to figure out what the underlying cause of the warning message above is, and if it's not actually an issue (everything continues to work as expected), then how to silence it. Thanks!
This is a known bug. As far is we know it doesn't cause any other issues, nonetheless we will fix ASAP.
I updated to Xcode 6.3, and I had two separate projects (one is a framework) in my workspace. Now, Xcode autogenerated this "frameworkname"-Swift.h header file, but when I had a generic class as a property, it produces the following lines:
#class Presentation;
SWIFT_CLASS("_TtC13BusinessLogic31MeetupDetailViewControllerModel")
#interface MeetupDetailViewControllerModel : NSObject
#property (nonatomic) /* RsvpStore<Rsvp> */ anRsvpStore;
#end
There is no equialent to gerenics in Objective-c, so how can I solve this problem?
I found that I can solve the problem if I set the type to NSObject like:
#property (nonatomic) NSObject * __nonnull anRsvpStore;
but with every build, this file is recreated to the same wrong version. So how can I force this build to set the type of this generic to NSObject?
I could stop creating this compatibility header by setting in Build Settings -> Swift Compiler - Code Generation -> Intall Objective-C Compatibility Header to No.
Since I've not written Objective-C code in my project, there is no problem with this option, but this is rather a workaround than a solution for generics in the compatibility header.
Another workaround is if you mark your properties with private, then they won't appear in the compatibility header.
Swift 2.0 update
A new
#nonobjc
attribute is introduced to selectively suppress ObjC export for instance members that would
otherwise be
#objc
. (16763754)
Blockquote
Not tested, but this looks like a solution.
I solved in #1873 https://github.com/realm/realm-cocoa/issues/1873
If you don't need to use swift in objc,just set Intall Objective-C Compatibility Header to No.
If you need to use swift in objc,you have to edited the -Swift.h and set it in Objective-C Generated Interface Header Name
I am getting the following error(and YES, I have already search through google again and again):
I have multiple 'extern NSInteger' defined and can use them, though this 'timeofclick' for some reason causes this error
On other threads people talk about adding frameworks and including stuff, but here I'm just using one more NSInteger
In my .h
In my .m
Could it be that you haven't actually defined the timeOfClick variable anywhere (inside a .m file). Putting the extern declaration in a header says "don't worry, this thing will get defined somewhere, and you'll find it at link time". If the linker comes along (like here) and it can't actually find the variable defined, you'll get an error like this.
Essentially you want to have an NSInteger timeOfClick somewhere in an implementation (.m) file.
I think you got the error because you didn't write
#synthesize timeofclick2;
under your #implementation ReactingViewController.
By default, the compiler will generate an instance variable (ivar) for you if you only declare a property but you don't synthesize it explicitly. The generated ivar usually goes by _<property_name>, like in your case _timeofclick2, instead of the same name as the property.
Thus, you got the error when you tried to call timeofclick2 without _ prefix because there is no ivar with that name.
By explicitly write #synthesize <property_name> (without '<..>'), the compiler will generate ivar for you with the exact name of the property.
So, if you add the code I mentioned above, the compiler will create ivar timeofclick2 for you. Then you can access it via your extern.
...Or another solution, you can just change the extern from
extern NSInteger timeofclick2;
to
extern NSInteger _timeofclick2;
Then you'd be fine :D
I have been having some trouble lately with using custom classes as types. As described in the title, I have been getting compile errors similar to the one below:
expected specifier-qualifier list before 'MyClass'
My code is usually something along the lines of this:
#interface MyCoolClass : NSObject {
MyClass *myClassObject; // Error is on this line.
}
I also occasionally use something like this:
#interface MyCoolClass : NSObject {
IBOutlet MyClass *myClassObject; // Error again on this line
}
Im not really sure if that is good to use but on occasion, I have done something like that so I could connect my objects together with Interface Builder so that one object could invoke a method on another object.
I've been able to do this before successfully with other projects but when I tried to do it today, it gave me this error. Any ideas what could be causing it? As far as I can tell, I have done the same thing that I did in the other project here.
It is also to my understanding that this error usually gets thrown if the type is not defined, but I am pretty sure that I have defined it.
Oh, GCC how obtuse and opaque can your errors possibly be....
Try compiling with the LLVM 2.0 compiler. It'll give you much more sane errors.
In this case, what is usually going on is that the compiler doesn't have a clue what MyClass is or there is a syntax error in the previously included header file that doesn't cause a compilation error until the #interface is hit in the file spewing the error.
It could also be a misspelling.
Or, as suggested, you need to #import "MyClass.h" into the header file (or implementation file or, even better, the PCH file) so that MyClass is defined before the iVar declaration.
#class MyClass;
That'll also do the trick.
Just as background, there are no compile-time errors or warnings in the subject project "Project".
There are numerous occurrences of using the same instance variable name in two (or more classes). In the following, I'll use the variable name "index" as an example. It appears as an instance variable in class1 and class2. The variable has different but similar meanings in both classes, hence the use of the common term.
I define index in the header file for both class1 and class2, for example:
#interface class1 : NSObject
{
int index;
}
...
Repeat for class2.
When I build the project, Xcode reports:
Duplicate symbol _index in /Project/build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/i386/class1.o and /Project/build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/i386/class2.o
Changing the occurrences of "index" to "indexnotverycommon", reports the same error with the new name.
Changing the occurrences to "index1" and "index2" respectively gets rid of the error. Xcode then reports the next duplicate it finds during linking, and so on, and so on.
I can continue the renaming process although I'd rather not, as I'm concerned that there is a more pathological underlying issue.
Any advice or question is appreciated.
index is a also a C function and thus a very unfortunate name in Objective-C.
This article describes why it's not a good idea to use index as a name.
I'm not sure why you get duplicate symbols though.
I figured it out using the Xcode find-in-project feature. Thanks for the advice about index.
don't #include or #import .m files. Just add those .m files into the Target | Build Phases. Don't add .h files into build phases, but #import .h files wherever you need those functions.
The compiler knows that it's just a header file "for information only" and that the bodies of the functions will be available when it will compile the .m files and put them all into 1 executable
The header file contains only forward declarations. Compiler knows that the body is either defined in another file or is in a lib linked to the project
The tip to check for an #import "Xxx.m" instead of the correct .h worked.
A quick workspace wide search for "Xxx.m" spotted the error in the include which was causing the link error.