In an Xcode 5, ARC, iPhone project, I have received a large number of warnings reading "No 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed." I know what this warning means, and why I might want to fix it. But this would take a long time given the size of my project, so I instead want to suppress the warning. However, setting the -Wno-property-no-attribute flag on all of my .m files didn't fix anything, nor did setting the flag at Custom Compiler Flags > Other Warning Flags. I also tried #pragma GCC/clang diagnostic ignored "-Wproperty-no-attribute" before my property declarations, and have cleaned my build folder many times. The warnings persist. (Also, the -w flag did not work to suppress all warnings, when applied to my .m files.)
What should I do?
The pragma statement should be this: #pragma clang diagnostic ignored "-Wobjc-property-no-attribute"
It turned out that I had made a small typo in the Custom Compiler Flags entry (although I still do not know why the file-per-file flags didn't work), and that the LLVM warning about this was almost invisible, being swamped in the hundreds of other warnings generated.
Related
I am trying to add iRate from https://github.com/nicklockwood/iRate to my app.
After adding file i get this error before even running the project.
#import "iRate.h"
#import <Availability.h>
#if !__has_feature(objc_arc)
#error This class requires automatic reference counting
#endif
http://i.stack.imgur.com/amxPM.png
The solution in this issue in this link https://github.com/nicklockwood/iRate. It is for ARC Compatibility.
As of version 1.7, iRate requires ARC. If you wish to use iRate in a non-ARC project, just add the -fobjc-arc compiler flag to the iRate.m class. To do this, go to the Build Phases tab in your target settings, open the Compile Sources group, double-click iRate.m in the list and type -fobjc-arc into the popover.
If you wish to convert your whole project to ARC, comment out the
#error line in iRate.m, then run the Edit > Refactor > Convert to Objective-C ARC... tool in Xcode and make sure all files that you wish to use ARC for (including iRate.m) are checked.
I want to get rid of this compiler warning in just one file of my Xcode project. Is there a way to do this?
You can turn off specfic warnings in Clang using a pragma directive and the "diagnostic" keyword, like so:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wunused-variable"
// Insert code here
#pragma clang diagnostic pop
No unused variable warnings will be produced for the code between the push and the pop.
A second option, even more targeted, is to mark a particular variable with a GCC-style attribute, specifically, "unused". Clang honors GCC's established attributes and won't issue a warning about that one variable:
__attribute__((unused))
NSString * thisStringIsJustForFun = #"It's only work if somebody makes you do it.";
I keep getting this for situations that are patently false, related to objective-c categories.
NB: this was working fine, then stopped working overnight.
It's as if Xcode is fundamentally broken in it's ability to "read the file system", and it's driving me nuts. Any ideas on how to force it to ... read the file system ... would be appreciated.
e.g.:
Start Xcode, write a file, import it, using Xcode autocomplete.
cmd-click on the import line, and it jumps to the header file
A few builds later, Xcode flags a Warning:, e.g. "Class method '+stringFromCGPath:' not found (return type defaults to 'id')"
Now when you cmd-click on the import line, Xcode flashes up a dialog "Symbol not found" (world's worst dialog box? doesn't even have a confirm, it flashes and vanishes)
If you run the app, it crashes on that line, saying the selector not recognized
Then, to prove how FUBAR Xcode is:
Quit Xcode, restart
Cmd-click is working again
...but the Warning is still in place, and the app still crashes
After a few seconds, cmd-click stops working
NB: things I've checked:
The file is in the project folder? YES
The .m file is included in the Target? YES
The .m file is in the list of files to compile? YES
Do a CLEAN ... then a BUILD? YES
UPDATE: an example header I'm trying to import - that I have been successfully importing for months, and worked fine in hundreds of builds, and I have NOT changed (confirmed using SCM):
#import <Foundation/Foundation.h>
#import "CGGeometryExtensions.h"
#interface NSString(CGPath)
+(NSString*) NSStringFromCGPath:(CGPathRef) path;
#end
UPDATE2: actually, this doesn't crash at runtime - it was crashing because there was a typo in the call to "NSStringFromCGPath:" (one letter was lower case when it should have been upper case). But this was hard to see because of XCode's claim that the whole header file didn't exist - even though, as noted above, the IMPORT line was auto-generated by Xcode.
It sounds as though you may have problems with the indexer. Have you got multiple targets in your project, or multiple projects in a workspace? If so, make sure they all build completely cleanly - a failure indexing one target can mess up code completion on another.
You might also try deleting your project's DerivedData folder
I am currently using Xcode 4, and in my .pch file I have this macro:
#define localize(s) NSLocalizedString((s), nil).
When I try to use this macro in some .m file, I receive this warning: Implicit declaration of function 'localize' is invalid in C99.
This code compiles without a problem, but how can I fix this so I don't get a warning?
I had this problem when I did a global replace of NSLog with DLog. I foolishly included the
#define DLog(...) NSLog(...
statements, so I ended up with
#define DLog(...) DLog(...
which caused the warnings, and a linker error.
Implicit function declarations are those that the compiler sees the first time used as a function call (as opposed to those where a prototype or the function definition is seen first).
Apparently your code used localize(foo) but the macro definition was not visible. Possible reasons: you forgot to #include the file containing the localize macro or the precompilation of headers went south an did not include the localize macro so it was left unexpanded.
Another "foolish" mistake I ran into was the fact that my DLog was defined in the prefix header of the iOS target, so I had to copy it over to the prefix of the OSX target, as well...
I had this problem because I accidentally imported CocoaLumberjack like this:
#import <CocoaLumberjack/DDLog.h>
Apparently the CocoaLumberjack team modularized the code some more; and macros like DDLogError are now defined separately in their own header file.
I replaced the import statement with this and the error went away:
#import <CocoaLumberjack/CocoaLumberjack.h>
In my case only one file was giving this error. Turned out that I added it to the project's tests target membership (in the File Inspector on the right).
Is there a way to suppress warnings in Xcode?
For example I am calling an undocumented method and since the method is not in the header I get a warning on compile. I know I can add it to my header to stop the warning, but I am wondering if there is a way other than adding it to the header (so I can keep the headers clean and standard) to suppress the warning? A pragma or something?
To disable warnings on a per-file basis, using Xcode 3 and llvm-gcc-4.2 you can use:
#pragma GCC diagnostic ignored "-Wwarning-flag"
Where warning name is some gcc warning flag.
This overrides any warning flags on the command line. It doesn't work with all warnings though. Add -fdiagnostics-show-option to your CFLAGS and you can see which flag you can use to disable that warning.
there is a simpler way to suppress Unused variable warnings:
#pragma unused(varname)
EDIT:
source: http://www.cocoadev.com/index.pl?XCodePragmas
UPDATE:
I came accross with a new solution, a more robust one
Open the Project > Edit Active Target> Build tab.
Under User-Defined: find (or create if you don't find one )the key : GCC_WARN_UNUSED_VARIABLE set it to NO.
EDIT-2
Example:
BOOL ok = YES;
NSAssert1(ok, #"Failed to calculate the first day the month based on %#", self);
the compiler shows unused variable warning for ok.
Solution:
BOOL ok = YES;
#pragma unused(ok)
NSAssert1(ok, #"Failed to calculate the first day the month based on %#", self);
PS:
You can also set/reset other warning:
GCC_WARN_ABOUT_RETURN_TYPE : YES/NO
For gcc you can use
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wshadow-ivar"
// your code
#pragma GCC diagnostic pop
You can learn about GCC pragma here and to get the warning code of a warning go to the Report Navigator (Command+9), select the topmost build, expand the log (the '=' button on the right), and scroll to the bottom and there your warning code is within square brackets like this [-Wshadow-ivar]
For clang you can use
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wshadow-ivar"
// your code
#pragma clang diagnostic pop
In order to surpress a warning for an individual file do the following:
select the file in the xcode project.
press get info
go to the page with build options
enter -Wno- to negate a warning:
-Wno-
e.g.
-Wno-unused-parameter
You can get the name of the warning if you look on the project settings look at the GCC warnings located at the bottom of the build tab page, by clicking on each warning it will tell you the warning parameter name:
e.g.
Warn whenever a function parameter is
unused aside from its declaration.
[GCC_WARN_UNUSED_PARAMETER,
-Wunused-parameter]
With Objective-C, a number of serious errors only appear as warnings. Not only do I never disable warnings, I normally turn on "Treat warnings as errors" (-Werror).
Every type of warning in your code can be avoided by doing things correctly (normally by casting objects to the correct type) or by declaring prototypes when you need them.
To get rid of the warning: try creating a category interface for the object in question
#interface NSTheClass (MyUndocumentedMethodsForNSTheClass)
-(id)theUndocumentedMethod;
#end
...
#implementation myClass : mySuperclass
-(void) myMethod {
...
[theObject theUndocumentedMethod];
...
}
As an aside, I strongly advise against calling undocumented methods in shipping code. The interface can and will change, and it will be your fault.
http://nshipster.com/pragma/#inhibiting-warnings - skip to inhibiting warnings section
Create a new, separate header file called 'Undocumented.h' and add it to your project. Then create one interface block for each class you want to call undocumented functions on and give each a category of '(Undocumented)'. Then just include that one header file in your PCH. This way your original header files remain clean, there's only one other file to maintain, and you can comment out one line in your PCH to re-enable all the warnings again.
I also use this method for depreciated functions in 'Depreciated.h' with a category of '(Depreciated)'.
the best part is you can selectively enable/disable individual warnings by commenting or uncommenting the individual prototypes.
Suppressing that particular warning is not safe. The compiler needs to know the types of the arguments and returns to a method to generate correct code.
For example, if you're calling a method like this
[foo doSomethingWithFloat:1.0];
that takes a float, and there is no prototype visible, then the compiler will guess that the method takes a double, not a float. This can cause crashes and incorrectly interpreted values. In the example above, on a little endian machine like the intel machines, the receiver method would see 0 passed, not 1.
You can read why in the i386 ABI docs, or you can just fix your warnings. :-)