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.
Related
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.
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
My first attempt at building a company iOS library/framework was this week, by following the steps found at this blog post here.
For reasons beyond this question, I can only link when building for a Device and not for simulator.
However, now I am getting a very bizarre error:
ld: 2 duplicate symbols for architecture armv7 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
The lines in question suggest:
duplicate symbol _OBJC_CLASS_$_iContactsGridCell in:
/Users/*/Desktop/Projects/contactservice/branch/ContactServicesClient/DerivedData/iContacts/Build/Intermediates/iContacts.build/Debug-iphoneos/iContacts-5.1.build/Objects-normal/armv7/iContactsGridCell.o
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/athium-iOS.framework/athium-iOS
duplicate symbol _OBJC_METACLASS_$_iContactsGridCell in:
/Users/*/Desktop/Projects/contactservice/branch/ContactServicesClient/DerivedData/iContacts/Build/Intermediates/iContacts.build/Debug-iphoneos/iContacts-5.1.build/Objects-normal/armv7/iContactsGridCell.o
/Applications/Xcode.app/Contents/Developer/Library/Frameworks/athium-iOS.framework/athium-iOS
Obviously the Class in question is iContactsGridCell.h
The class itself inherits from Cell.h
#interface iContactsGridCell : Cell
The class Cell.h is part of the framework, if I do not import the correct file, then as expected I get a semantic error: Cannot find interface declaration for Cell etc etc.
However, when I do import it, I get the following duplicate error.
This file is not included anywhere else in the project, apart from iContactsGridCell.h!
The file Cell.h in turn, is just a class found under the framework:
#interface Cell : NSObject
#property (strong,nonatomic) UIView *view;
#property CGRect rect;
#property int UID;
#property BOOL highlighted;
#property UIColor *b_colr;
- (id) initWithRect:(CGRect)frame;
- (BOOL) hasCoordinates:(CGPoint)coord;
- (void) ripple;
- (void) cubefy;
- (void) flipfy;
- (void) rotate;
- (void) setBg:(UIColor *)bg withAlpha:(CGFloat)alpha;
- (void) highlight;
- (void) unhighlight;
- (void) updateWithRect:(CGRect)rect;
#end
Why on earth am I getting the duplicate error?
What could be causing this?
How could it get fixed?
How can I get more info more verbose output of where the duplicates are found?
PS: I have followed the intructions found at the blog to the letter. Yet I cannot link for simulator (getting a wrong architecture error) so my guess that maybe something is broken in the framework and not the project itself. Could this be the reason for the duplicate errors?
There are several places where this error could be arising. I would do the following to start searching for the problem:
Search the project folder with finder and see if anywhere else the file "iContactsGridCell.h" exists. Or if any two files exist somewhere.
Make sure that you don't have two Objects that are of Class iContactsGridCell that share the same name for example:
iContactsGridCell *myObj;
iContactsGridCell *myObj;
Make sure your not doing anything like this: #import
"iContactsGridCell .m"
Or like this: #import "iContactsGridCell.h" #import "iContactsGridCell.h"
Make sure your not re-declaring a class (including ones that Apple has provided in their frameworks)
Main Point: That's all I can think of off the top of my head. But the thing to remember is that somewhere in your project resides two objects, class declarations etc. That are the same. And the compiler is complaining because of it.
Why the Compiler would complain (more info): While this information is really "unnecessary" it's good practice as a programmer to understand what's going on under the hood and will often help debug, so here's a little info on compilers:
Remember that a Compiler (while much more complex) is a program just like the ones that you create using it. One of the steps in most (if not all) compilers go through at one point or another reading code is creating "Symbols or Keys" for each variable, class, struct ect. So, at some point the compiler reached a line of code that "repeats / duplicates" somewhere else. So the "Key/Symbol" creation process done routine by the compiler fails.
I can't get rid of two errors on my class module, even when I have simplified the code to the minimum expression:
#import <Foundation/Foundation.h>
#interface MyClass : NSObject
#end
Both errors are reported on the #interface line, and they are:
- missing #end
- expected identifier or '{'
Check the header files that are #imported on the same page, and verify that the headers have matching #interface/#end statements.
I had the same problem, and XCode reported that my .m file's #implementation had a missing #end statement, even when I pared it down to just:
#import "MasterViewController.h"
#import "MyBadHeaderFile.h"
#implementation MasterViewController
#end
In reality the bug was a missing #end from a #imported MyBadHeaderFile.h file.
I had a similar problem found adding a } in my code got rid of the errors for me.
Before I added the } I was getting the following errors:
unexpected # in program (parse issue)
Expected } (parse issue)
#end is missing in implementation context (semantic issue)
rokjarc's comment should be a correct answer:
1) compiler can point you to completely wrong file. go trough all .h and .m files in your project and check for matching '#interface'/'#end', '#implementation'/'#end' and so on.
2) it happens also if you by mistake import .m file instead of .h
It doesnt matter in which file the error is appearing. Make sure to check for all the files you have recently modified. I appeared to have copied a file from test project to my actual project and forgot #end in one of the files. It gave me error on totally unrelated .h file.
Try to remove the implementation file of this class from "Compile sources in project settings"
#interface MyClass : NSObject{
}
#end
I experienced a similar issue, the code was fine but it was throwing this error.
I eventually resolved it by cleaning the project, have you tried that?
PEBKAC + Lack of Specificity in the Static Analyzer Strings
The existing answers are certainly useful. I just want to add a common PEBKAC that causes this; as well as highlight that CLANG should be clearer here. Someone with domain knowledge should file a patch to make the error message clearer. The \n#end\n part of the message is ridiculous no matter what.
(Showing line breaks as \n in a message designed to help users of a
GUI? Really CLANG?)
The Cause
When you have just created a new Class, the #interface & #implementation files look extremely similar, and Xcode will automatically place your cursor in the implementation.
If you thoughtlessly begin typing out your interface (your method signature declarations) in the implementation file, you'll end up with this warning because the analyzer sees methods without opening and closing braces.
A visual example, shown forthwith
I had the same error ,and it was because i had
#interface MyViewController ()
declared two times in the MyViewController.m
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.