Bug 49260 - Malformed Javadoc Compiler option sensitive to line breaks
Summary: Malformed Javadoc Compiler option sensitive to line breaks
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 3.0 M7   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 47420 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-12-22 04:59 EST by Channing Walton CLA
Modified: 2004-03-25 14:10 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Channing Walton CLA 2003-12-22 04:59:11 EST 
The compiler warnings for malformed Javadoc is sensitive to text split over several lines, which 
happens if the Javadoc is formatted quite often

Take this Javadoc comment:

* @see CompletionProposal#CompletionProposal(java.lang.String, int, int,  int)

and put a line break in the argument list

* @see CompletionProposal#CompletionProposal(java.lang.String, int, int,
*  int)

The 'Malformed Javadoc' compiler option says 'Javadoc: Invalid parameters declaration'
I think this happens with the @see tag since other tags with split arguments didn't have a problem.
Comment 1 Tom Hofmann CLA 2003-12-22 06:55:42 EST 
Not sure whether we are allowed to break see tags, if not, the javadoc
formatting needs to avoid that.

Moving to core for comments.
Comment 2 Andre Weinand CLA 2003-12-23 08:23:46 EST 
[Does not seem to be a Mac problem. Removed Mac tags.]
Comment 3 Philipe Mulet CLA 2003-12-23 08:45:26 EST 
We indeed treat Javadoc on a per line basis. Need to double check expected 
behavior.

If proven that we are indeed wrong, then this would need to be addressed along 
with other doclet tags support.
Comment 4 Frederic Fusier CLA 2004-01-13 05:18:18 EST 
Fixed.

Changes done in jdt.internal.compiler.parser.JavadocParser.readToken().
Loop on '*' character (TerminalTokens.TokenNameMULTIPLY) when new line has been 
encountered.

This imply that while parsing tags, last token was not consumed to avoid 
skipping next tag definition.
For example:
/**
 * @see String
 * @see Integer
 */
void foo() {}
parse of first @see tag will stop at following token '@' (TokenNameERROR). If 
we consume it, then loop in checkDeprecation would restart at 's' character of 
next see tag and will missed the declaration!

Test cases added in jdt.core.tests.compiler.regression.JavadocTestMixed.
Comment 5 David Audel CLA 2004-02-11 05:39:13 EST 
Verified for 3.0M7
Comment 6 Dani Megert CLA 2004-03-25 14:10:36 EST 
*** Bug 47420 has been marked as a duplicate of this bug. ***