Community
Participate
Working Groups
20080212 For bug 96685 we would like offer a link from compiler warnings to the corresponding preference setting. It would be good if jdt.core can offer this option. But we can also place this mapping in JDT.UI. But I assume some compiler knowledge is required to do it right. For settings with sub options, this could return multiple settings.
Created attachment 92134 [details] Draft fix + test case This is a first crack at it. Since the bug only asked for compiler problems, this should be good enough, if only problems which can be flagged as error, warning, or ignore are targeted. Martin, would you please let me know what you think?
Functionality is good, maybe a better name? getCorrespondingCompilerOption(int problemId)
Well, originally proposed name: getCompilerProblemSeverityTuningOption(int problemID) is admittedly as detailed as it could be, which you may find too much indeed, but I would contend that your proposal is too general, since several options may have a bearing on an error being reported or not (even source level indeed). Hence I'd like the name to be specific. I'll ask Kent review, which will be an occasion to collect his advice on the name as well, and we'll make a decision when he's shared his thoughts if this is OK with you?
Kent, would you please let me know what you think about the patch in general, and the name choice as well?
(In reply to comment #2) > Functionality is good, maybe a better name? > > getCorrespondingCompilerOption(int problemId) > I like that muuuuuch better. (In reply to comment #3) > Well, originally proposed name: getCompilerProblemSeverityTuningOption(int > problemID) is admittedly as detailed as it could be, which you may find too > much indeed, but I would contend that your proposal is too general, since > several options may have a bearing on an error being reported or not (even > source level indeed). Which compiler option id do you return in such a case?
It depends. Either there is an option that explicitly manages the severity for the given problem and I return this, or else there is none and I return null. Some options may eliminate the emission of a warning even if this is not their own purpose. Consider: /** * @param x */ void foo(X x) { } If javadoc is processed (COMPILER_DOC_COMMENT_SUPPORT enabled), then you will get no warning or error about x not being used in method, regardless of the value of COMPILER_PB_UNUSED_PARAMETER, because the @param clause is considered to reference x. But if javadoc is not processed, then option COMPILER_PB_UNUSED_PARAMETER will set the level of the reported warning or error, if any. This is not good enough a reason to return COMPILER_DOC_COMMENT_SUPPORT as an option that you may want to consider when attempting to get rid of the warning, the relationship being somewhat remote. Another case of interest is that some options refine the behavior, while still depending on the severity setting option (for example, COMPILER_PB_DEPRECATION_IN_DEPRECATED_CODE). It might be that the warning at hand could be disposed by tuning COMPILER_PB_DEPRECATION_IN_DEPRECATED_CODE only (that is, not changing COMPILER_PB_DEPRECATION at all), but to guess that would need more than the problem ID (the same problem ID is used regardless of the offending code being within deprecated code or not; what the option conditions is the fact that the warning is emitted, or not), it would need some context about the error that we may not have at hand when calling the method added here. So, for now, my proposition is to focus on the primary options that were explicitly designed to handle the severity of compiler errors.
How about getConfigurableOptionForProblemSeverity() ? The patch was cut off & is incomplete.
(In reply to comment #7) > How about getConfigurableOptionForProblemSeverity() ? My votes would go to this one or to my original proposal. Pls others cast yours. > The patch was cut off & is incomplete. Damn GSA! I will attach a complete one asap. This will be the occasion to remove the extraneous 'ONLY_'.
Created attachment 92180 [details] Complete patch for draft fix plus test case
Both getCompilerProblemSeverityTuningOption and getConfigurableOptionForProblemSeverity sound complicated and use new terminology ('TuningOption', 'ConfigurableOption') The existing API for options is getOption(String optionName). so what about getOptionName(int problemID) I would also agree to getOptionForProblemSeverity(int problemID)
(In reply to comment #10) > Both getCompilerProblemSeverityTuningOption and > getConfigurableOptionForProblemSeverity sound complicated I would have preferred 'sound precise' ;-) Would still be my first and second choices. The expected behavior *is* very specific, no wonder it reflects in the name? > and use new > terminology ('TuningOption', 'ConfigurableOption') The terminology is severity tuning or configurable severity indeed. And new terminology is not that surprising when adding new function, is it? > > The existing API for options is getOption(String optionName). > so what about > getOptionName(int problemID) Too general. Introduces the idea that maybe we missed 'Name' in previous propositions... especially since getOption is a shorthand for getOptionValue indeed. Would be my fourth choice. > I would also agree to > getOptionForProblemSeverity(int problemID) Would be my third choice, kind of way behind the second.
How about getOptionForConfigurableSeverity(int problemId) ? We do not want to lose the notion that only problems with a configurable severity are returned. Please vote on your choice, if you have one.
(In reply to comment #12) > How about getOptionForConfigurableSeverity(int problemId) ? +1
> getOptionForConfigurableSeverity(int problemId) +1
Severity means Ignore/Warning/Error... I'd rather suggest: getOptionForConfigurableProblem(int problemId)
(In reply to comment #16) > Severity means Ignore/Warning/Error... Yes. The current implementation, that fits Martin's needs according to comment #2, only cares about those.
Created attachment 92551 [details] Patch with new name
Released for 3.4 M6.
The Javadoc needs some polish: - references to problemID and null should be in <code> - ... the constants defined by this class which names start with ... ^ whose or: ... this class' constants whose names start with ... (preferred) or: ... this class' constants the names of which start with ... - ... a problem which severity ... ^ whose severity ... (preferred) or: ^ the severity of which ...
Released polished javadoc (taking option 1 in all cases).
Verified for 3.4M6 using build I20080324-1300
*** Bug 147029 has been marked as a duplicate of this bug. ***
