Community
Participate
Working Groups
Eclipse is trying to compile a javadoc comment as java-sourcecode if it gets uncommented. Example (linenumbers added): 1 /** 2 * This method gets called when a bound property is changed. 3 * 4 * @param evt A PropertyChangeEvent object describing the event source and the property that has 5 * changed. 6 */ 7 public void propertyChange(PropertyChangeEvent evt) 8 { 9 } 1. Mark line 2-6 and comment with Strg-/ 2. Save the file 3. Mark line 2-6 and uncomment with Strg-/ 4. Save the file => The javadoc comment is handled as sourcecode and compile errors are displayed for the javadoc section
The steps to reproduce are wrong. It should be: 1. The javadoc comment must be folded 2. Mark the folded javadoc comment and the complete method 3. Comment it with Strg-/ (everything except line 1 is commented with '//') 4. Save the file 5. Mark line 2-9 and uncomment with Strg-/ 6. Save the file => The javadoc comment is handled as sourcecode and compile errors are displayed for the javadoc section
Move to JDT/UI It seems that editor behaves as line 1 was commented but didn't show // at beginning. Selecting line 1 and uncomment it fixes the problem...
The document is correctly updated but the first comment line is not correctly shown in the editor is not. This used to work in 3.0. Tom, please investigate.
Notes: - To reproduce, in step 2 (from comment 1), make sure to select the folded line entirely (otherwise, the first line of the javadoc region is not commented out). - choosing "New editor" afterwards opens a new editor that correctly shows the contents of the document. Also, closing and reopening the editor works as expected. I suspect a problem in the projection infrastructure.
DefaultJavaFoldingStructureProvider creates a foldable region for the lines that (at least partially) contain javadoc. The foldable region translates to two fragments that are removed in the projection: the first line of the javadoc, and the remaining lines of the javadoc after the caption line. The double slashes get added at the offset of the first fragment, which is equal to the offset of the foldable region. Position updating inconsistency: a. "comment lines" adds double slashes to all lines b. the document mapping gets updated accordingly <- FragmentUpdater c. the folding regions tracked by the java folding structure provider get updated <- DefaultPositionUpdater (since AnnotationModel uses the default position category) d. the reconcile triggers recomputation of the folding structure e. the folding region for the javadoc gets removed, which triggers ProjectionDocument::addMasterDocumentRange Both the fragment and the foldable region get updated by position updaters. However, two different position updaters are used that have slightly different semantics when adding the slashes that to the first javadoc line (which is folded away): - FragmentUpdater considers them to be part of the java doc line fragment (inclusive). - DefaultPositionUpdater does not include the slashes in the foldable region, since the document change happens right at the offset of the position (exclusive).
A solution would be to enforce strictly line based fragments in ProjectionViewer::{add,remove}MasterDocumentRegion
Fixed > 20050831 The projection infrastructure can handle arbitrary fragments, but ProjectionViewer only supports line based fragments. ProjectionViewer must therefore ensure that any fragments it adds to the document mapping are stricly line based, even if the ProjectionAnnotations do not adhere to this convention.
Created attachment 26706 [details] ProjectionViewer.java.diff Patch against ProjectionViewer.java R1.75 This is a 3.1.1 candidate.
Agree. Approving for 3.1.1. Slightly modified the patch together with Tom. Second reviewed by Tobias. Released into R3_1_maintenance.
start verifying ...
Verified in M20050831-1200 + ZRH plugins from R3_1_maintenance.
Reopening, since I found an analogous case where the last line is not correctly updated: public class Try { int a; int b; } - fold the type - select the whole line - press Ctrl+Shift+/ (Add Block Comment) => the closing */ is not rendered
Investigating fix...
Created attachment 26832 [details] ProjectionViewer.java.diff Patch against ProjectionViewer.java R1.75.2.1 This patch removes the prior fix and chooses a different approach: when collapsing ProjectionAnnotations, we always delegated to IProjectionPosition to compute the actual folding regions. However, when expanding a ProjectionAnnotation, we previously took the entire region of the projetion annotation, instead of again letting the annotation decide which regions were folded. This caused the asymmetric behavior described in this PR. This patch also delegates to the IProjectionPosition to compute the regions to expand. The patch works fine for me. However, the changes are far from minimal and we have to debate about whether to include it into R3_1_maintenance.
Avail. in HEAD > 20050905
The bug described in comment 12 is already in since R3.0. Since the fix for this problem is not trivial and I just found another case where it's not working at the end of the file we will not put it into 3.1.1. Filed bug 108925 to track this further.
Marking as verified since the regression which has been introduced got fixed.
