Bugzilla – Full Text Bug Listing
| Summary: | [javadoc] Compiler warning for unused parameter showing up even though it is documented | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Michael Rennie <Michael_Rennie> |
| Component: | Core | Assignee: | JDT Core Triaged <jdt-core-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | darin.eclipse, frederic_fusier, markus.kell.r, Olivier_Thomann |
| Version: | 3.5 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Michael Rennie
I should note that performing a clean build on the projects does not remove the problem - it comes back after every build (clean or otherwise). You actually need to also trigger the processing of javadoc comment. Check this option: Preferences>Java Compiler>Javadoc>Process Javadoc comments If the javadoc are not processed, there is no way the compiler can "guess" that the parameter is defined using @param. Frédéric, is this the intended behavior? If yes, I would close as INVALID. (In reply to comment #2) > You actually need to also trigger the processing of javadoc comment. > Check this option: Preferences>Java Compiler>Javadoc>Process Javadoc comments Yup that fixed it. > > Frédéric, is this the intended behavior? > If yes, I would close as INVALID. It is confusing that you can have one setting on that needs another to be turned on as well. Maybe this could be improved to tell the user that turning on that option will do nothing without Javadoc processing also turned on. (In reply to comment #3) > It is confusing that you can have one setting on that needs another to be > turned on as well. Maybe this could be improved to tell the user that turning > on that option will do nothing without Javadoc processing also turned on. I had the same feeling about it. This is why I asked if it works the way it was designed. Even if it was designed that way, it doesn't mean we cannot improve it :-). (In reply to comment #4) > (In reply to comment #3) > > It is confusing that you can have one setting on that needs another to be > > turned on as well. Maybe this could be improved to tell the user that turning > > on that option will do nothing without Javadoc processing also turned on. > I had the same feeling about it. This is why I asked if it works the way it was > designed. Even if it was designed that way, it doesn't mean we cannot improve > it :-). > Yes that was the intended design when Javadoc comments are not processed. The reason for that was that at the time it was implemented, we were really concerned about the fact that processing the Javadoc comments would slow the compiler... We keep this option, and use it as the default, to avoid users to get an impact on their compilation time when they do not intentionally care about the correctness of the javadoc comments contents... So, IMO, the simplest solution on this bug issue would be to unset and disable the compiler option "Ignore parameters documented with '@param' tag" in the preference page when the "Process Javadoc comments" is not set... Markus, what do you think? (In reply to comment #5) > Yes that was the intended design when Javadoc comments are not processed. The > reason for that was that at the time it was implemented, we were really > concerned about the fact that processing the Javadoc comments would slow the > compiler... We keep this option, and use it as the default, to avoid users to > get an impact on their compilation time when they do not intentionally care > about the correctness of the javadoc comments contents... This comes back to the fact that the compiler cannot retrieve javadoc comments without resolving them. APT also needs to get the javadoc, but doesn't care about them being resolved. So I believe we should split this behaviour. Having a way to get the javadoc without resolving them and another way to trigger their resolution. If we keep the statu quo on the compiler side, we need to make it clear on the preference page what needs to be done to get the expected behaviour. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |