Community
Participate
Working Groups
So there is a problem that is not analysed. Does that mean that a) a problem in my code has been detected, but is not reported as a problem? b) whether a problem in my code exists or not is not checked at all? Then the reason for the message is given as "due to a compiler option being ignored". Does that mean that c) a compiler option is specified to ignore the problem, hence it is not even tried to be analysed? d) a compiler option to analyze the problem is specified, but that option is ignored? If so, why is it ignored? I must admit that I generally prefer not to see this message at all because I have the feeling that it is somehow the result of combining checking options that are directly in the code, i.e., @SuppressWarnings, and global workspace options, which are often different in different workspaces. More concretely, in all cases where I get these annoying (and currently unremovable) "At least one of the problems ..." messages, the code author has added a @SuppressWarnings annotation to express that the code does not have a problem. Then in some other workspace the global options also say "I'm not interested in this kind of problem" and voila, I get a message that I can't seem to interpret correctly and that I can't remove. And apparently just because the code and my workspace settings both have the same intention, i.e., ignore that problem. Am I misunderstanding the purpose of this message?
I think this is a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=520287 I have this same problem with my current customer project and I find it super super duper annoying that there is no way to get rid of this problem marker via a preference or in any other way. JDT produces so many exceedingly useful warnings and even informational messages, e.g., this new unlikely type argument message which is almost always a bug in the code. But with these completely useless unsupressabable problems, the useful problems go unnoticed. I suppose I could try to contribute a fix, but where to start?!
Sorry, Ed, for not responding earlier (as one of the authors of the original bug 506888). I'm glad you found the connection to bug 520287 (and transitively to bug 506888 I assume). I'd like to emphasize that this info message is a compromise. I don't think anybody really likes it very much, but we didn't find a better solution. In this light, implementing a fix is likely several orders of magnitude simpler than finding a good concept, so let's speak about concepts: Status quo: - problem kinds are grouped to @SW tokens (e.g., "unused"). - warning configurability in the UI is more fine-grained than @SW tokens (local variable, method parameter, import, private member etc.pp.) - if some options from group "x" are disabled we may get into this conflict: - if we see @SW("x") but have not noticed any warning suppressed by this we don't know if this means: - the @SW is unnecessary and should be flagged as such, or - the warning being suppressed was disabled and so we don't know if it _would_ surface if enabled this is particularly relevant, if people with different workspace prefs see different "@SW is unused" warnings -> one user removes @SW, another user will see a new warning appear that was previously suppressed. Obviously, we didn't do too good a job in capturing all this information in a one-line error message. Is there a way out? (1) we could theoretically change the implementation to always analyze all problems. (a) In particular javadoc analysis is completely turned off depending on compiler preferences. Do we really want to change that? Same for annotation-based null analysis. (b) Remembering ignored problems requires significant changes in how we record and report problems, starting by reverting bug 210213 from 2007. (2) we could potentially improve the info message (3) we could introduce a new configurable options as sub-option of "Unused '@SuppressWarnings' token" e.g.: "'Unused' status is not fully known due to a relevant option being ignored" [E/W/I/I] (4) convince Dani that we can just scrap this info entirely ;p (2) & (3) would be simple to implement. Here design/agreement is the hard part. (1.a) would be a costly decision. Think of performance. Think of bugs in one analysis that currently can be avoided by disabling that analysis, but would have no workaround if analysis is always performed. Only if we decide to bite that bullet, considering (1.b) would come into focus.
(In reply to Stephan Herrmann from comment #2) > Sorry, Ed ups, Eike and Ed are two different persons :)
I would prefer a version of (3) where I could suppress specifically only this new "confusing" warning that only happens when a) there is an @SuppressWarning("foo"), but b) the global preferences have set "foo" warning to ignore. I don't want performance to be impacted and I don't want anyone to do a lot of work! I just want to eliminate this one informational message... For my customer project I really want to highlight how many bugs are in their code just based on these newer "unlikely type argument" informational messages, but it's hard to make that point when there are a whack of informational messages that I can't eliminate. This customer project has hundreds of workspace projects from several different Git repositories so it's very hard to manage project-specific preferences and it's hard to set a global preference that will not also result in useless, unsuppressable informational message...
(In reply to Ed Merks from comment #4) > I would prefer a version of (3) where I could suppress specifically only > this new "confusing" warning that only happens when a) there is an > @SuppressWarning("foo"), but b) the global preferences have set "foo" > warning to ignore. I don't want performance to be impacted and I don't want > anyone to do a lot of work! I just want to eliminate this one informational > message... @Dani, @Jay, do you care to comment?
Thanks for the responsiveness! It's much appreciated!!
This continues to be an annoying problem. If @nobody cares to respond with a comment, then I would suggest that @Stephan is in the best position to show leadership and should feel free to choose the path forward that he personally feels is the most appropriate.
Additionally, FYI: bug 547645
(In reply to Stephan Herrmann from comment #5) > (In reply to Ed Merks from comment #4) > > I would prefer a version of (3) where I could suppress specifically only > > this new "confusing" warning that only happens when a) there is an > > @SuppressWarning("foo"), but b) the global preferences have set "foo" > > warning to ignore. I don't want performance to be impacted and I don't want > > anyone to do a lot of work! I just want to eliminate this one informational > > message... > > @Dani, @Jay, do you care to comment? Apologies for missing this. Stephan, can you tell me what you have in mind for option (2)? Naturally, options (1) and (4) are out of contention and if option (2) is not particularly interesting, then I tend to lean towards (3).
(In reply to Jay Arthanareeswaran from comment #9) > (In reply to Stephan Herrmann from comment #5) > > (In reply to Ed Merks from comment #4) > > > I would prefer a version of (3) where I could suppress specifically only > > > this new "confusing" warning that only happens when a) there is an > > > @SuppressWarning("foo"), but b) the global preferences have set "foo" > > > warning to ignore. I don't want performance to be impacted and I don't want > > > anyone to do a lot of work! I just want to eliminate this one informational > > > message... > > > > @Dani, @Jay, do you care to comment? > > Apologies for missing this. > > Stephan, can you tell me what you have in mind for option (2)? I had nothing particular in mind, just listed this as theoretical option for completeness, since communication seems to play a central role in this issue (see the bug title). > Naturally, options (1) and (4) are out of contention really? I was hoping we could settle for (4) ;p > and if option (2) is > not particularly interesting, then I tend to lean towards (3). If you ask me, it's less "leaning towards" rather than "running out of options". So, reproducing the plan from above: We will introduce a new configurable options as sub-option of "Unused '@SuppressWarnings' token" e.g.: "'Unused' status is not fully known due to a relevant option being ignored" [E/W/I/I] "being ignored" or "set to ignore"? How about: "'Unused' status is not fully known because a relevant option is set to 'ignore'" [E/W/I/I]
New Gerrit change created: https://git.eclipse.org/r/149692
(In reply to Eclipse Genie from comment #11) > New Gerrit change created: https://git.eclipse.org/r/149692 core part to make the unloved info configurable. I did not allocate a new @SuppressWarnings token for it, though ;p
Gerrit change https://git.eclipse.org/r/149692 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=c842004634d661ef8d9d485e77e9c84af231e888
see also bug 409303 comment 6 :)
*** Bug 520287 has been marked as a duplicate of this bug. ***
https://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/diff/org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/text/correction/ConfigureProblemSeveritySubProcessor.java?id=d528dbc1af351a5a7f89693cffcca207b027b637 on behalf of bug 506888 tweaked option tweaking so users could adjust the ignored warning option. See discussion around bug 506888 comment 23. This change will be removed while exposing the new configuration option for JDT/Core in the UI.
New Gerrit change created: https://git.eclipse.org/r/150649
(In reply to Eclipse Genie from comment #17) > New Gerrit change created: https://git.eclipse.org/r/150649 This is my last take on this issue. I'm not submitting the new UI label for any beauty contest, or contest of conciseness: 'Unused' status is not fully known because a relevant option is set to 'Ignore': Some will consider it much too long, some will still be puzzled about the meaning (which would require an even longer text to suitably explain the situation). I will not participate in their discussion. Feel free to change the text in any direction (shorter, longer, better, worse ...).
Gerrit change https://git.eclipse.org/r/150649 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=e90eeedae6ab5b8fa8eb40fbd00840583dbbc9b3
(In reply to Eclipse Genie from comment #19) > Gerrit change https://git.eclipse.org/r/150649 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/ > ?id=e90eeedae6ab5b8fa8eb40fbd00840583dbbc9b3 Released for 4.14 M1
Verified for Eclipse Version: 2019-12 (4.14) M1 with Build id: I20191008-1800
