Community
Participate
Working Groups
Build Identifier: I20110428-0848 You know how some(if not all) warning don't show when Errors are present (in current code if anything is red aka Error, then some warnings don't get visually shown aka underlined). If there is an Error which can be suppressed via @SuppressWarnings such that there are no errors shown anymore (in the current file) then a Warning (of local variable being not used; at least this warning if not all or more) is not being sensed (or shown, or in anyway detected as a warning) just as if the Error(s) still existed in the code and were not suppressed. If I transform the Errors in Warnings (via Java Compiler->Errors/Warnings) then the specified Warning is sensed and shown, which leads me to believe that @SuppressWarnings doesn't fully suppress the Errors. well you get the point, too much talk and i don't amount to anything :) Reproducible: Always Steps to Reproduce: make this code: package org.some; public class Dum { public void some( @SuppressWarnings( "unused" ) int aParam ) { int aLocal; } } ========== in Project->Properties->Java Compiler->Errors/Warnings in Unnecessary Code: set `Value of local variable is not used: Warning` set `Value of parameter is not used: Error` now notice that aLocal variable doesn't get a Warning underline to workaround: set `Value of parameter is not used: Warning` now aLocal gets a Warning underline in other words, if any Errors exist, then if they are suppressed with @SuppressWarnings like that, they still cause that Warning on aLocal (at least that warning, if not all other warnings) to not show, just as if the warning doesn't show when the Error is active (if any errors are active the aLocal Warning won't show, must clear all errors prior to that warning showing - and clearing the errors with @SuppressWarnings will still cause aLocal warning to not show)
sorry I think I should've posted this in the APT component ? annotation processing ...
also for this to work, you must have enabled: Java Compiler->Errors/Warnings->Annotations->Suppress optional errors with @SuppressWArnings else that @SW won't be recognized or something
oh and also, this: set `Value of local variable is not used: Warning` you can set that to Error and it's the same thing, acts the same as previously described for Warning
this was also tested with set `Unnecessary declaration of thrown exception: Error` instead of set `Value of parameter is not used: Error` with the same effect, to test that, set `Value of parameter is not used: Warning` set `Unnecessary declaration of thrown exception: Error` and do this code: package org.some; public class Dum { public void some( @SuppressWarnings( "unused" ) int aParam ) { int aLocal; } @SuppressWarnings( "unused" ) public void moo() throws Exception { // empty } } to fix aka aLocal to show warning, then you can either: 1. remove `throws Exception` 2. add throw new Exception(); instead of "//empty" and optionally remove @SuppressWarnings( "unused" ) - I now see here that although this Error appears: Unnecessary @SuppressWarnings("unused") as error(due to my settings), aLocal still shows as warning nonetheless , so this would be an exception and means that warning doesn't not-appear when _any_ errors exist in code 3. set `Unnecessary declaration of thrown exception: Warning`
4. remove throws Exception and optionally the @SW part
I suspect this is the same as bug 343621. The fix for bug 336648 has been backed out for 3.7 RC1, I don't think you should see this problem in 3.7 RC1, can you confirm ? Thanks.
tested with Build id: I20110512-2000 aka eclipse-SDK-3.7RC1-win32-x86_64.zip it does NOT seem to be fixed, I still don't get the warning on aLocal variable is not used.... I will next try the latest build from 14 may I think (2 days after the one I just tested)
since I'm still downloading latest eclipse sdk, I had time to clean up the Errors/Warnings such that all options are set to Ignore and unticked except these: `Value of local variable is not used: Warning` `Value of parameter is not used: Error` (ticked) `Enable @SuppressWarnings annotations` (ticked) `Suppress optional errors with @SuppressWarnings` and most importantly: (ticked)Treat above errors like fatal compiler errors (make compiled code not executable) the issue still persists, no warning on aLocal variable (which is unused) However, if I untick/uncheck the `Treat above errors like fatal compiler errors (make compiled code not executable)` then the warning appears!!! I swear I did try to untick this in previous version to no avail. Perhaps your fix works except when this option is selected? this is still in I20110428-0848 aka 3.7 RC1
I mispasted the last build number in previous post only, it was I20110512-2000 aka 3.7 RC1 and I just tested if unticking `Treat above errors like fatal compiler errors (make compiled code not executable)` can fix the show warning but it does not indeed (this eclipse was I20110428-0848 aka 3.7 m7) So I can only conclude, your fix indeed works except when `Treat above errors like fatal compiler errors (make compiled code not executable)` is ticked/selected. I thank you so much for this fix, I will try to workaround this by keeping this unticked for now. I want to try eclipse-SDK-I20110514-0800-win32-x86_64.zip but it's still downloading, so I will try it eventually but I will only post here if there are any differences (ie. if it works for this one), else assume it's not fixed as described.
indeed the same happens even in this Build id: I20110514-0800 aka eclipse-SDK-I20110514-0800-win32-x86_64.zip (3.7) I will now try it on eclipse 4.1 aka eclipse-SDK-I20110517-2200-win32-x86_64.zip yep, exact same thing: unticking `Treat above errors like fatal compiler errors (make compiled code not executable)` will fix it and make the warning appear. So to summarize: bug is fixed when `Treat above errors like fatal compiler errors (make compiled code not executable)` is deselected, and bug is back when that option is selected. Hail to the king, baby :)
(In reply to comment #8) > However, if I untick/uncheck the `Treat above errors like fatal compiler errors > (make compiled code not executable)` then the warning appears!!! I swear I did > try to untick this in previous version to no avail. Perhaps your fix works > except when this option is selected? If you select the option to treat all errors as fatal, then the code generation for the method doesn't happen and the local variable cannot be flagged as unused. We have a bug report open to detect unused local variables before the code generation to prevent this kind of side-effects for problem detection. So I don't plan to change this for 3.7. The only thing that I will investigate is the reporting of unused thrown exceptions. This is counter-intuitive.
(In reply to comment #11) > The only thing that I will investigate is the reporting of unused thrown > exceptions. This is counter-intuitive. In fact this works fine. You need to disable the option that ignores Exception from thrown exceptions. So besides the unused local that cannot be properly detected if the method code generation is not run, there is nothing wrong here. And this will be fixed with bug 328830 in 3.8 time frame.
(In reply to comment #11) > (In reply to comment #8) > > However, if I untick/uncheck the `Treat above errors like fatal compiler errors > > (make compiled code not executable)` then the warning appears!!! I swear I did > > try to untick this in previous version to no avail. Perhaps your fix works > > except when this option is selected? > If you select the option to treat all errors as fatal, then the code generation > for the method doesn't happen and the local variable cannot be flagged as > unused. > We have a bug report open to detect unused local variables before the code > generation to prevent this kind of side-effects for problem detection. So I > don't plan to change this for 3.7. > > The only thing that I will investigate is the reporting of unused thrown > exceptions. This is counter-intuitive. I'm not sure that I understand, you mean to say that for this code: package org.some; public class Dum { public void some( @SuppressWarnings( "unused" ) int aParam ) { int aLocal; } } the code generation for the method does not happen? but there are no errors, shouldn't code generation not happen only when there are errors? unless I misunderstand. I mean sure there are errors in this code only if I untick/disable the Project->Properties->Java Compiler->Errors/Warnings->Annotations->Suppress optional errors with `@SuppressWarnings` but with that enabled, there are no errors, shouldn't the code generation for the method happen? I mean, before the local variable gets flagged as unused, why wouldn't the code generation for method not happen? I'd assume it wouldn't happen if there are any reported warnings or errors, but there are none, unless the warning about the local being unused happens and then it's treated as fatal error and then the code generation doesn't happen(but this means code generation had to happen once to even report that local not being used - as you made me understand) So I either disable the above option OR I remove the @SuppressWarnings from the code, both variants cause my code to err, ie. this code: package org.some; public class Dum { public void some( int aParam ) { int aLocal; } } has error on aParam, and indeed I understand in this case code generation for method does not happen which means aLocal variable won't get a warning, but if I make sure that option is enabled AND I add the @SuppressWarning in the code, so it becomes: package org.some; public class Dum { public void some( @SuppressWarnings( "unused" ) int aParam ) { int aLocal; } } then there are no errors and no warnings, is there a reason why code generation for the method would not happen? if it should happen then it should maybe report the aLocal as being unused? Hope you can demystify my confusion ;) Thanks.
(In reply to comment #13) > I mean sure there are errors in this code only if I untick/disable the > Project->Properties->Java Compiler->Errors/Warnings->Annotations->Suppress > optional errors with `@SuppressWarnings` > but with that enabled, there are no errors, shouldn't the code generation for > the method happen? No if you select the non-fatal errors to be fatal. Even if there is no error reported (because suppressed by the @SuppressWarnings). @SuppressWarnings only hide the potential error. The error is still there. You should simply uncheck the option that treat non-fatal errors as fatal. > Hope you can demystify my confusion ;) I tried :-). Let me know if this is enough.
(In reply to comment #12) > (In reply to comment #11) > > The only thing that I will investigate is the reporting of unused thrown > > exceptions. This is counter-intuitive. > In fact this works fine. You need to disable the option that ignores Exception > from thrown exceptions. I did not understand this at all I mean, here are some variants of what I can understand: 1. you say it shouldn't report unused thrown exceptions, like this: public void moo() throws Exception { // empty } Exception is declared to be thrown but it's not thrown, thus we call this unused thrown exceptions. But this makes sense to me to report this, there are also options to fiddle with settings related to this like: Unnecessary declaration of thrown exception: Ignore/Warning/Error [] Ignore in overriding and implementing methods [] Ignore exceptions documented with @throws or @exception tags [] Ignore `Exception` and `Throwable` these all make sense to me, thus I fail to understand what you meant by 'this is counter-intuitive' therefore this variant must be false resulting in me not understanding what you mean 2. the second variant is mostly based on what you said below > In fact this works fine. You need to disable the option that ignores Exception > from thrown exceptions. if I disable this option: [] Ignore `Exception` and `Throwable` then it wouldn't change from what it previously was, that is why I think here you maybe meant enable it? which means it will not report declared Exception exceptions and thus the @SuppressWarnings here: @SuppressWarnings( "unused" ) public void moo() throws Exception { // empty } is unnecessary too, but then, I'm not sure I get it, why is this relevant, it probably only make sense to this: > > The only thing that I will investigate is the reporting of unused thrown > > exceptions. This is counter-intuitive. Don't think of this of a failure on your part, it is simply I who does not understand what you said *evil-grin_followed_by_a_self-slap-of-idiotness* xD
(In reply to comment #14) > (In reply to comment #13) > > I mean sure there are errors in this code only if I untick/disable the > > Project->Properties->Java Compiler->Errors/Warnings->Annotations->Suppress > > optional errors with `@SuppressWarnings` > > but with that enabled, there are no errors, shouldn't the code generation for > > the method happen? > No if you select the non-fatal errors to be fatal. Even if there is no error > reported (because suppressed by the @SuppressWarnings). @SuppressWarnings only > hide the potential error. The error is still there. > > You should simply uncheck the option that treat non-fatal errors as fatal. > > > Hope you can demystify my confusion ;) > I tried :-). Let me know if this is enough. Oh I see what you mean, thanks! Like, the error is still there, but it's only not being shown/reported due to @SW But this is actually desired? Shouldn't maybe @SW totally clear the error? so that the part that treats non-fatal errors as fatal would actually see no errors I mean, is that really desired as it is? I seem to want @SW to totally annihilate the error, this would in fact allow that aLocal warning to happen, how nice it would've been :) Fair enough, I do understand now, but I'm reluctant to accept it as so, lol
(In reply to comment #14) > You should simply uncheck the option that treat non-fatal errors as fatal. that is indeed the workaround I used for this bug, coupled of course with the latest release of e4 build I20110518-2200 it's rather fair enough for me Much appreciated, thanks!
(In reply to comment #16) > But this is actually desired? Shouldn't maybe @SW totally clear the error? so > that the part that treats non-fatal errors as fatal would actually see no > errors > I mean, is that really desired as it is? I seem to want @SW to totally > annihilate the error, this would in fact allow that aLocal warning to happen, > how nice it would've been :) > Fair enough, I do understand now, but I'm reluctant to accept it as so, lol Technically speaking @SW should not suppress errors. Now we should discuss if it should get rid of all errors even the fatal ones. I would say as soon as you set an error to be fatal, @SW should not hide it anymore. This would be more consistent.
(In reply to comment #18) > Technically speaking @SW should not suppress errors. Now we should discuss if > it should get rid of all errors even the fatal ones. > I would say as soon as you set an error to be fatal, @SW should not hide it > anymore. This would be more consistent. you do have a point, I was merely looking at @SW as being @SuppressIssue meaning whatever its setting is Error/Warning, it would still suppress it, (unless it's on Ignore then it would get detected as trying to suppress something that's never getting reported (this feat already existing, I'm aware)) If indeed @SW would be fixed as you say, I'd most likely need a @SuppressErrors with the same functionality but for Errors only, meaning I'd probably have two of those @SE and @SW one after the other for the same issue, just in case I change the setting to alternate between report as Error or Warning for the specific issue, in fact other settings would probably complain that I can only have either @SW or @SE but not both, since the issue is only reported as either a Warning or an Error, but this would mean that if I do change that setting from Error to Warning (or inverse) I would have to edit all the places for this issue to transform the @SE into @SW (or inverse) - which would be unwanted :) Peace out;)
places = places in the code
Since we have an option to use @SW to suppress errors, this should be done regardless of the fatal state of the error as long as the error is an optional error. You cannot expect @SW to be used to suppress errors that the JLS requires to be mandatory. Updating title accordingly.
"@SuppressWarnings should clear all errors including fatal optional errors" I like the title, but as we talked, when you say "should clear ... errors" that means, they should also be cleared internally(where they are unseen-by/unreported-to the user), because they are already cleared in the sense that they are not reported(where they are seen by the user) (not-reported or unseen-by-user meaning: there are no red underline decorators and no Error items in Problems view). Just making sure this is "clear" =) in other words exactly as you said in your prev comment (21): > "Since we have an option to use @SW to suppress errors, this should be done regardless of the fatal state of the error as long as the error is an optional error." and I agree with this: > "You cannot expect @SW to be used to suppress errors that the JLS requires to be mandatory."
to put it even simpler, if the error is not reported(to the user) then it should not be considered internally either, this pretty much summarizes the current state of this "bug", I'd say. The error is thus only partially cleared, or something =) ok I'm done ranting xD
Ok, I checked what is going on exactly. When an error is tagged as fatal, the referenced context (in this case the method) is tagged as having errors. So at the code generation time, the problem is not yet "filtered" out by @SW. This is done at the end of the problem inside finalizeProblems(). So to be consistent, we should check @SW at the time the problem is reported to make sure we don't flag the method as having errors. Insie finalizeProblems(), we no longer have the reference context for a problem. So there is no way to remove the flag at that time. Let's check what we can do for 3.8.
Changing onwership
Created attachment 208905 [details] A patch This is a patch that works, but could have a performance impact. All the error/warnings are checked for all suppressions. This could impact performance, when there are many errors that gets suppressed. I will try to get some peformance numbers.
*** Bug 365455 has been marked as a duplicate of this bug. ***
Patch with bug 365437 comment#6 includes the changes for this. I have looked at the patch and found one issue with the patch that I have submitted here -- I wasn't checking for the option suppressOptionalErrors. Otherwise, there are slight differences between the placement of the checks. I will improve the current patch looking at the changes Olivier made in bug 365437 comment#6.
Created attachment 208926 [details] Improved Patch Cleaned up patch looking at Olivier's patch. Used the test from that patch.
I ran some performance tests and didn't find any regressions.
*** Bug 367734 has been marked as a duplicate of this bug. ***
Created attachment 208984 [details] Patch The last patch had some other file changes cropped in.
Released the patch on master via commit 7e8a00ed0fb06969786f78f88b755624a0317803
*** Bug 367935 has been marked as a duplicate of this bug. ***
*** Bug 361115 has been marked as a duplicate of this bug. ***
Verified for 3.8 M5 using build I20120123-1300 In particular I can confirm that a suppressed fatal optional error no longer hides any unrelated warnings in the same method/ctor or class.
