I've got a function with such part of code:
if (CGFLOAT_IS_DOUBLE) {
return fabs(x / y);
} else {
return fabsf(x / y);
}
However with new Xcode I'm obtaining a warning here:
Absolute value function 'fabsf' given an argument of type 'double' but
has parameter of type 'float' which may cause truncation of value
The warning wasn't visible in Xcode 6, but in Xcode 7 Beta it is.
With such wrapping, I'm moreover sure that the values are float type. Now the question is how to suppress the warning?
I've tried with many Clang flags, ended on most general:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wall"
// above code
#pragma clang diagnostic pop
But it doesn't help (odd?). "-W" also doesn't help. Any tip..?
I don't want to cast, create extra float variables nor anything similar. I just want to silence the warning.
Related
#pragma message is implemented in Clang as warning.
Is there any way to disable the warning only for this pragma, so it will be have like MS Visual Studio, or some other way to give informational messages from code ?
(I need an answer as an end user with a given Clang, I cannot re-compile the Clang itself on this project)
I realize this post is a year old and the OP probably already found his answer but since I was looking for the answer myself I thought I may as well include the info here.
From the Clang user's manual:
https://clang.llvm.org/docs/UsersManual.html#controlling-diagnostics-via-pragmas
The pragma may control any warning that can be used from the command line. Warnings may be set to ignored, warning, error, or fatal.
Attempting to set the class to something other than the above:
#pragma clang diagnostic push
#pragma clang diagnostic note "-W#pragma-messages"
#pragma message "HELLO!"
#pragma clang diagnostic pop
int main(int argc, char **argv)
{
}
Results in a warning showing the same options:
/tmp/test.cc:3:26: warning: pragma diagnostic expected 'error', 'warning', 'ignored', 'fatal', 'push', or 'pop' [-Wunknown-pragmas]
#pragma clang diagnostic note "-W#pragma-messages"
^
/tmp/test.cc:4:9: warning: HELLO! [-W#pragma-messages]
#pragma message "HELLO!"
^
2 warnings generated.
So it appears that as of Clang 5.0 there is no way to treat the message as informational instead of as a warning.
I've recently come across with double return statement (one of them was added by mistake) in our project and wondering why compiler doesn't show a warning for that?!
Ok, I added -Wunreachable-code to other warning flags, but still no luck.
Got warning - with a code to execute after return statement:
Didn't get warning but still second return statement will never be executed.
Even if I add something like this, still no warning
Is there extra warning flag for that, or compiler isn't smart enough?
Good catch!
-Wunreachable-code does not report a warning and there is no other warning flag which would do.
Not even the Static Analyzer catches this mistake!
(Tested with XCode 6.1 GM 2)
Wrap your code in pragma flags that will suppress that warning between the push and pop
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunreachable-code"
//Your code goes here
#pragma GCC diagnostic pop
Use -Wno-unreachable-code for your file in Build Phases.
Try this...
-(NSString*) makeSomeStringForMe {
NSString *someString = #"some string";
return someString;
}
I have to use some private functions, like:
SCDynamicStoreRef
SCDynamicStoreCreate (
CFAllocatorRef allocator,
CFStringRef name,
SCDynamicStoreCallBack callout,
SCDynamicStoreContext *context
) __OSX_AVAILABLE_STARTING(__MAC_10_1,__IPHONE_NA);
By default they are not allowed for iphone, so I've changed declaration of them in my .m file. But now it shows "Availability does not match previous declaration" warning. How to suppress this warning?
With the usual disclaimer that using private APIs might cause your app to be rejected:
You can suppress the warning with
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wavailability"
…
#pragma clang diagnostic pop
It might also cause crashes or other failures if that function is present in the iOS
frameworks, but with different parameters.
I have a switch/case section of code in an iOS project that checks a variable of type NSCalendarUnit. At first, Xcode 5.0.2 gives a warning about not including some of the enum values in switch statements. So I added the rest of them, except NSCalendarUnitNanosecond, which Xcode indicates is not available in for iOS, and even puts a red strikethrough line through it when showing the auto-completion selections. Yet, Xcode 5.0.2 is still giving me the warning
Enumeration value 'NSCalendarUnitNanosecond' not handled in switch
So is it valid for iOS or not?
(it's part of Mac OS X, e.g., https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/Foundation.htm
As a side note, it's interesting that the Apple docs at https://developer.apple.com/library/mac/documentation/cocoa/reference/foundation/classes/NSCalendar_Class/History/History.html#//apple_ref/doc/uid/TP40003626-RH1-SW1 are out of date, being last updated in 2011.
When preprocessing the source file, one can see that the definition of NSCalendarUnit
expands on iOS to
enum NSCalendarUnit : NSUInteger {
// ...
NSCalendarUnitNanosecond __attribute__((availability(ios,unavailable))) = (1 << 15),
// ...
}
which means that NSCalendarUnitNanosecond is not available on iOS.
But it seems that the compiler does not honor the availability attribute correctly
when checking the switch statement.
This can easily be reproduced with the following example:
enum MyEnum {
Enum1,
Enum2,
Enum3 UNAVAILABLE_ATTRIBUTE
};
enum MyEnum e = 0;
switch (e) {
case Enum1:
case Enum2:
break;
default:
break;
}
also produces a "Enumeration value not handled in switch" warning when compiling with
-Weverything. This seems to be a compiler bug.
Of course you can suppress the warning locally with
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wswitch-enum"
// switch-statement
#pragma clang diagnostic pop
Xcode raising "incompatible pointer types sending 'subclassA' to parameter of type 'subclassB' " warning. Compiling with clang.
In the case where the warning is raised, I use a
[subclassA isKindOfClass: [subclassB class]] ...
to ensure compatible pointer use. I'd like something like:
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
// warning-raising code
#pragma clang diagnostic pop
but for the appropriate warning raised. I.e. Whats the clang flag to ignore the specified diagnostic?
Thanks for your time.
If I understand you right, you're saying something like
if ([subclassA isKindOfClass:[subclassB class]]) {
[foo someMethodThatWantsSubclassB:subclassA];
}
The fix here is to cast subclassA after the successful type assertion. Your case is a bit odd in that you're dynamically determining the type of subclassB instead of testing for a static type, but in the method -someMethodThatWantsSubclassB: you definitely know the type involved, so you'd write something like
if ([subclassA isKindOfClass:[subclassB class]]) {
[foo someMethodThatWantsSubclassB:(BClass)subclassA];
}
If you have some really weird setup where you don't actually know the static type of subclassB (although I can't imagine the situation here) you could simply cast to (id) instead to get rid of the warning:
if ([subclassA isKindOfClass:[subclassB class]]) {
[foo someMethodThatWantsSubclassB:(id)subclassA];
}