Community
Participate
Working Groups
20040130 (jdt.core preview 8 p.m) In a.): First Tag element has range that goes until the end of the file. In b.) First tag range does not include the embedded tag 1.) public class E { /** * {@link A} * @see Vector#siz() * @param nam1 */ public void gee(String name) throws IOException { } } class G { private static class Inner {} } (b) public class E { /** * XX {@link A} * @see Vector#siz() * @param nam1 */ public void gee(String name) throws IOException { } }
I cannot reproduce exactly this bug using last integration build I200401301130: in a.): First Tag element has range that goes until the end embedded tag in b.): First tag range includes the embedded tag However, there are two remaining problem: in a.): First tag element does NOT include leading '{' of embedded tag (it starts at '@' of '{@link'. This makes the range of embedded tag set to 8 instead of 9 characters... in b.): Same problem for embedded tag which does not include leading '{' character and so have wrong length. This also has for consequence that parent tag element also have wrong length: 11 instead of 12 expected Martin, if you agree, then please reduce the severity as there's only one character missing in positions and let me know if you want a preview for it (I have the fix ready...)
Fixed. Include leading '{' for embedded tags by storing start position in AbstractCommentParser: field inlineTagStart. Refresh starting position of parent tag when pushing see reference of when updating inline tag position in DocCommentParser. Modify ASTConverterJavadocTest to have a complete verification of positions for Javadoc nodes hierarchy. Also add test cases in this class for these specific errors of position.
how does this affect regular users? it says 'major'. is the build usable? english, please. :)
This bug does NOT affect build usability (as it was said in comment 1)... I reduce the severity to avoid confusion. Last comment explanation was written for jdt-core developers, sorry. The important thing for you is that it will be fixed in next integration build.
Verified for 3.0M7
