I'm trying to suppress an instance of a warning in my code. I use the intellij feature alt-enter to add the suppress warning annotation to the method, also tried with the class. But whenever I hit the rebuild button, the warning keeps coming up as if the suppress warning annotation isn't being recognised.
I've read a few answers that suggest disable completely, or you can suppress individual entry using this notation. I know I can disable it completely through settings, but I'd rather just suppress this instance. Does anyone know why it wouldn't be suppressing the warning?
Information:Using Eclipse compiler to compile java sources
Information:Compilation completed successfully with 1 warning in 9 sec
Information:0 errors
Information:1 warning
...TagValidator.java
Warning:(41, 16) java: Type safety: Unchecked cast from java.lang.Object to java.util.List<common.model.Tag>
Method in question:
#SuppressWarnings("unchecked")
#Override
public void validate(Object target, Errors errors) {
logger.entry();
List<Tag> list;
list = (List<Tag>) target;
for (Tag tag : list) {
if (tag.getTag().length() > 30) {
errors.rejectValue("tags", "tags.length");
break;
}
}
logger.exit();
}
This appears to be an issue with the eclipse (ejc) compiler. When the javac compiler is used, no warnings are present upon make/compilation. But if you switch to the eclipse compiler, then you get the warnings. In the (closed) IntelliJ IDEA bug report ecj doesn't use #SuppressWarnings the JetBrains development team indicated that
IDEA uses such suppressions for its own error highlighting, which is compiler-independent. Similarly, it runs external compiler as is, without any interference.
So IDEA isn't doing anything to tell ejc not to use/honor the SuppressWarnings annotations.
Related
In the idea editor and my java project , idea does not detect non-existing methods and underline in the editor pane, so i could not use alt + enter to generate new methods.
Example screenshot is below :
BTW : powersave mode is disabled, in the project setting sources are selected.
Project window is seen below:
I created demo maven project in idea, still the problem continues.
I created DemoNew Class.
public class DemoNew {
}
Then i created DemoImpl class:
public class DemoImpl {
public static void main(String[] args) {
DemoNew demoObject = new DemoNew();
demoObject.ssss(); // idea does not detect this non-existing method.
}
}
As seen above, idea does not detect the non existing ssss method in DemoNew class.
I uploaded demo project and my settings in intellij idea.
demo project and settings
After compiling project, still idea does not underline non-existing method with red color in the editor pane.
JetBrains Team answered the question
Looks like JDK uses wrong locale:
https://youtrack.jetbrains.com/issue/IDEA-190718 Please try to add
"-Dsun.locale.formatasdefault=true" option to JVM settings.
I added that parameters from intellij idea / help / edit custom vm options.
And parameters are seen below.
-Dsun.locale.formatasdefault=true
-Duser.language=en
-Duser.region=US
-Dfile.encoding=UTF8
I added last four items in the file.
That fixed the problem.
I have a function in Kotlin that I want to inline despite not being high-order.
I find that through out the project I have numerous occurrences of such scenario.
Therefore, to ignore compiler warnings about using inline functions, I have to use lots of Suppress("NOTHING_TO_INLINE") annotations through out my project and it's starting to bother me.
Is there any way to block this warning for the whole project by, for instance, a compiler option?
I'd like to know how to do this in IntelliJ IDEA.
It doesn't look like it's possible to disable the inspection globally. I can't find a setting in IntelliJ at least. You can, however, disable the inspection for an entire file:
#file:Suppress("NOTHING_TO_INLINE")
If you press ALT+Enter on the warning, you'll get an option to suppress it which just contains suppressing for the function, class (if it's in one), or for the entire file. Any inspections you can disable usually has a "Disable inspection" option on this list (which NOTHING_TO_INLINE does not have).
You can, however, disable the warnings when compiling (but it does not affect the inspection; you'll still see warnings while editing) by adding suppressWarnings to the compileKotlin task. Note that this disables ALL warnings, not just specific ones.
compileKotlin {
kotlinOptions.suppressWarnings = true
}
I have tried annotating a field with
org.checkerframework.checker.nullness.qual.NonNull
org.jetbrains.annotations.NotNull
javax.annotation.Nonnull
And in all cases, assigning a null to it generates no complaints from IntelliJ 2016.2.
public class GreetingController {
#NotNull Integer x = 3;
public void foo() { x = null; }
}
That all compiles fine according to IntelliJ.
This page from IntelliJ specifically states that "IntelliJ IDEA highlights the problems “on-the-fly”, so you can see the inspection results right in the editor." I have even copied the example code (public class TestNullable) into my editor and it produces no errors.
This other page from IntelliJ states you can change the annotations it responds to. So I chose javax.annotation.Nonnull and made sure that was the one I was using in my code, still no luck.
To be clear, what I'm hoping for, and what I understand should be provided, is that the editor window / compiler alerts me to the problem (I am not looking for a runtime check, NullPointerException already works fine at runtime.)
In case it didn't work in real time, I tried "Rebuild Project".
I'm sure this must work, what am I doing wrong?
I have uploaded an example of this not working here: ZIP download.
As I can see from your screenshots and the sample project, IntelliJ IDEA does show you the warnings. Note that these warnings are shown by the code inspections which are running on the fly and will be displayed in the editor or in the Analyze | Inspect Code results. These warnings will not be displayed by the compiler.
Note that you can configure the warnings highlighting if needed (for example add the underwave effect):
You can also change the severity of the inspection (like to Error):
You may also want to vote for this feature request:
IDEA-78625 Provide inspection severity level that will work like validation and abort compilation
As a bonus, pay attention to the javax.annotation.Nullable annotation, it may be not what you think it's for, see this comment and the documentation. For some years IntelliJ IDEA has incorrectly suggested to use this annotation, while the correct one for such cases would be javax.annotation.CheckForNull:
This annotation is useful mostly for overriding a Nonnull annotation.
Static analysis tools should generally treat the annotated items as
though they had no annotation, unless they are configured to minimize
false negatives. Use CheckForNull to indicate that the element value
should always be checked for a null value.
"Settings" > "Inspections" > "Probable Bugs" > "Constant conditions & exceptions"
Tick the first option: "Suggest #NotNull annotation for methods that possibly return null and report nullable values passed to non-annotated parameters.
Click "Configure Annotations". By default, Intellij will use their own annotations from org.jetbrains.annotation. I was using the more general (my own opinion) annotations from javax.annotation.
I set Nullable to: javax.annotation.Nullable
I set NotNUll to : javax.annotation.NotNull
In order to set these new options, you must click them, then click the tiny checkmark button to the right to set it. Selecting the javax.annotation annotations then hitting "OK" will NOT lock in the new settings, you must use the checkbox button.
After successfully specifying javax.annotation.Nullable and javax.annotation.NotNull, the code correctly highlighted null problems.
The best that this can do is offer up warnings. It will not stop compilation from happening, since the annotations do not prohibit or preclude code compilation from taking place.
Be sure that you have the appropriate inspections enabled in your IDE, and be sure that you remain aware of what parameters you're passing into your method. The IDE can at best warn you, but it can't really stop you.
Alternatively, introduce a unit test to fail if that method receives a null parameter, and rely on that to ensure that you're not breaking code or expectations.
ld: warning: Some object files have incompatible Objective-C category definitions. Some category metadata may be lost. All files containing Objective-C categories should be built using the same compiler.
This warning above appeared when I installed the Firebase/Core through cocopods. And I believe it cause an error, because my project can't read the FIRApp.configure() at App deleagate in my project. I am sure I download the GoogleService-Infor.plist and put it in the right place in project, because I done it on my another project before (work properly), my another project didn't have the Objective-C categories warning.
Can anyone help me out?
The process that I've done:
Add pod 'Firebase/Core' in the project podfile, close the xcode.
Open terminal, go to the target project folder, execute pod install.
Appear a warning on terminal (Solution: just put the $(inherited) in the build setting of ALWAYS_..., then problem solve)
[!] The xxxxxx-ebooking [Debug] target overrides the ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES build setting defined in `Pods/Target Support Files/Pods-xxxxxx-ebooking/Pods-xxxxx-ebooking.debug.xcconfig'. This can lead to problems with the CocoaPods installation:
Use the $(inherited) flag, or
Remove the build settings from the target.
Appear a warning on xcode (This issues are simple, just commit the new files then warning will gone):
file:///Users/yyyyyy/Projects/xxxxxx_projects/xxxxxx-ebooking/Pods/Target%20Support%20Files/Pods-xxxxxx-ebooking/Pods-xxxxxx-ebooking.debug.xcconfig: warning: Missing file: /Users/yyyyyy/Projects/xxxxxx_projects/xxxxxx-ebooking/Pods/Target Support Files/Pods-xxxxxx-ebooking/Pods-xxxxxx-ebooking.debug.xcconfig is missing from working copy
Ignore the issues process of 3, 4, because it are easy to solve. Because the most wired warning is :
ld: warning: Some object files have incompatible Objective-C category definitions. Some category metadata may be lost. All files containing Objective-C categories should be built using the same compiler.
Firebase Analytics has not been created. Please, configure Firebase by calling [FIRApp configure]
I did put the FIRApp.configure() in my project. But when I call FA event on some view did load, it will show this warning. I believe it is because the Objective-C warning.
see if using #nonobjc on your static variable resolve the issue
Finally I solved all bugs, thanks my friend help me to debug and stack overflow community. Here is the solution:
In the beginning I thought this warning "ld: warning: Some object files have incompatible Objective-C category definitions" caused the fail of executing the FIRApp.configure(). But it end out it are two different errors!
First issue, The FIRApp.configure() issues is because my project has error migration when swift 2.2 to 3.0. The xcode suggested me to change the old 2.2 syntax to be private method in AppDelegate:
private func application(application: UIApplication, willFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool {
// This method is your app’s first chance to execute code at launch time.
FIRApp.configure()
return true
}
The FIRApp.configure() will never execute because it is not AppDelegate's method. So, changed back to correct syntax will solve the issues:
func application(_ application: UIApplication, willFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey : Any]? = nil) -> Bool {
print("Fire! willFinishLaunchingWithOptions")
return true
}
Second issue, if using the below demo syntax and your project has objective-C in third party plug-in or your code, it will cause the warning "Some object files have incompatible Objective-C...". Maybe, because syntax is old for swift 3.0 so it appear this warning.
class var applicationBuildNumber: String {
if let build = Bundle.main.infoDictionary?["CFBundleVersion"] as? String {
return build
}
return "Build Number Not Available"
}
If you using class function, then this warning will disappear:
class func appLocalBuild() -> String {
return Bundle.main.object(forInfoDictionaryKey: kCFBundleVersionKey as String) as! String
}
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. :-)