Community
Participate
Working Groups
Snippet: public void start() { int result; for (int i = 0; i < 3; i ++) { result = i >> 1; result ++; // Correct indentation is wrong here } }
In the code above, the LESS token in the for statement seems to be part of the cause. Indentation is correct when other operators are used. The following code shows the same indentation behavour: private int i = 3 << 1; public int start() { for (int j = 0; j == 0; j ++) { j = 3 >>> 1; i = 0; // wrong indentation } return 0; }
Can be reproduced using 3.2 RC6.
Created attachment 43251 [details] skipSkope fix
The error can be traced back to the class: JavaIndenter From package: org.eclipse.jdt.internal.ui.text Method: skipScope() After finding a > token, preceeded by a >, the code assumes that it is looking for a generic type and tries to find the matching < for the preceeding >. There are 3 problems with the code: 1) The assumption that it is looking for a generic type is not always correct. In the case of a bit shift right and an unsigned bit shift right, it should not be looking for a generic type. 2) The code tries to find the scope for the preceeding > To work as intended, it should to go back to its original position and token, and then skip the scope. 3) A minor thing: nextToken() modifies: fToken, fPreviousPos, fPosition and fLine. However skipScope() resets only fPosition and fToken to their original values. Proposal: 1) Remove the last TokenGREATERTHAN case. 2) Store and restore the values of fPreviousPos and fLine. (see the attachment above)
Tom, please give the patch a try.
Released patch with the following changes > 20060814 - thanks! - added copyright - added test in JavaHeuristicScannerTest::testShiftOperator()
Bug is still present in 3.3 RC1 BTW, the test case in testShiftOperator does not match the examples. (i.e. '<' in the for expression)
The test cases are wrong. I removed them. You and Tom obviously didn't test the fix (your suggestion from comment 3 got applied - I reverted them for 3.3).
A friend bumped into this bug. This is the minimal code I got to that still has the incorrect indentation: long C = 1 << 2; void m() { long e = 1 >> 2; //wrong indentation } It seems that the problem is when there is left shift and after it a block of code that contains a right shift.
*** Bug 243158 has been marked as a duplicate of this bug. ***
This bug is still there in 4.4. I can't imagine it's still not been fixed. Is there an official solution or patch for this ? I tried wrapping the expression that contains >> with parentheses and it corrected the indentation. However it is not always a good solution to this.
Is this skipScope code the reason why this class declaration abstract class AbstractStream<T, E extends Exception, STREAM, SELF extends AbstractStream<T, E, STREAM, SELF, IS, LS, DS, CONSUMER, PREDICATE, BINARY_OPERATOR, COMPARATOR, TO_IS, TO_LS, TO_DS, TO_INT, TO_LONG, TO_DOUBLE>, IS, LS, DS, CONSUMER, PREDICATE, BINARY_OPERATOR, COMPARATOR, TO_IS, TO_LS, TO_DS, TO_INT, TO_LONG, TO_DOUBLE> { } gets turned into a hugely over-long one line? And if so, is that code really necessary in the first place?
*** Bug 439757 has been marked as a duplicate of this bug. ***
This is still present on Eclipse Neon 4.6.1
From a quick glance I guess that the core of the solution would need to let JavaHeuristicScanner recognize combined tokens like LEFT_SHIFT, RIGHT_SHIFT etc. Unfortunately, even ">>" doesn't necessarily mean RIGHT_SHIFT, it could be a pair of two closing type argument angle-brackets. See grammar rules like TypeArguments ::= '<' TypeArgumentList1 TypeArgumentList1 -> TypeArgument1 TypeArgument1 -> ReferenceType1 ReferenceType1 ::= ClassOrInterface '<' TypeArgumentList2 TypeArgumentList2 -> TypeArgument2 TypeArgument2 -> ReferenceType2 ReferenceType2 ::= ReferenceType '>>' OR: skipScope() would need to cancel its search when any content between '<' and '>' is illegal for a type argument. => either way not a trivial task ...
*** Bug 512661 has been marked as a duplicate of this bug. ***
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. If you have further information on the current state of the bug, please add it. 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.
Bug is still present in 2019-09 R (4.13.0) (build: 20190917-1200)
