Folding mechanism for while/for/if/switch-case

[jakub-suliga]

Problem:
Currently, there is no folding mechanism for while/for/if/switch-case statements in Eclipse. VSCode and IntelliJ support a folding mechanism for these statements. Therefore, I have created a method that implements this folding mechanism. This is also an open issue: #1426. In addition, I deleted some commented-out code from 2007.

Before:

After:

How to test:

1. Start an Eclipse workspace and create a new class.
2. Add while/for/if/switch-case statements to this class.
3. Verify that the folding mechanism works as expected.

Here is a small program you can use to test:

private int zaehler;
private final Object sperre = new Object();


public void test() {
    if (zaehler > 0) {
        System.out.println();
    } else if (zaehler == 0) {
        System.out.println();
    } else {
        System.out.println();
    }

    while (zaehler < 10) {
        zaehler++;
    }

    for (int i = 0; i < zaehler; i++) {
        System.out.println();
    }

    do {
        zaehler--;
    } while (zaehler > 0);

    int[] zahlen = {1, 2, 3, 4, 5};
    for (int zahl : zahlen) {
        System.out.println();
    }

    switch (zaehler) {
        case 0:
            System.out.println();
            break;
        case 1:
            System.out.println();
            break;
        default:
            System.out.println();
            break;
    }

    try {
        int ergebnis = 10 / zaehler;
    } catch (ArithmeticException e) {
        System.out.println();
    } finally {
        System.out.println();
    }

    synchronized (sperre) {
        zaehler++;
    }

    Runnable runnable = () -> {
        System.out.println();
    };
    runnable.run();

    {
        System.out.println();
    }

    for (int i = 0; i < 5; i++) {
        for (int j = 0; j < 5; j++) {
            if (i * j > 6) {
            }
            System.out.println();
        }
    }

    try {
        String text = null;
        text.length();
    } catch (NullPointerException e) {
        System.out.println();
    } catch (Exception e) {
        System.out.println();
    } finally {
        System.out.println();
    }

    {
        System.out.println();
    }
    if (zaehler > 0) {
        for (int i = 0; i < zaehler; i++) {
            while (i < 5) {
                System.out.println();
                i++;
            }
        }
    }

    lambdaVerwenden();
}

public void lambdaVerwenden() {
    verarbeiteLambda(() -> {
        System.out.println();
    });
}

private void verarbeiteLambda(Runnable runnable) {
    runnable.run();
}

Bugs:

• [Bug] [Folding mechanism] Method declaration on the Same Line as the Closing Bracket #1539
• When there are multiple nested while/for/if/switch-case statements, not all foldable regions are recognized.

[jakub-suliga]

Bug:

• When you press enter or delete a line and the element is closed, the folding mechanism gets buggy

[fedejeanne]

The test failures seem to be unrelated: https://ci.eclipse.org/jdt/job/eclipse.jdt.ui-github/job/PR-1562/21/testReport/

The only test that fails with age == 1 (i.e. in this PR) is org.eclipse.jdt.text.tests.PluginsNotLoadedTest.pluginsNotLoaded but looking at its stack trace I don't see any hints that point to this PR either:

java.lang.AssertionError: 
Wrong bundles loaded:
- org.eclipse.jdt.junit
 expected:<0> but was:<24>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.eclipse.jdt.text.tests.PluginsNotLoadedTest.pluginsNotLoaded(PluginsNotLoadedTest.java:278)
...

Does anyone know the reason for this failure?

In the meantime @jakub-suliga, try with another force-push to re-trigger the checks and see if the failure persists.

[fedejeanne]

In the meantime @jakub-suliga, try with another force-push to re-trigger the checks and see if the failure persists.

On a closer look, the test failures are because of the changes introduced in this PR. Run them locally and you will see it.

Here's (part of) the console output when running org.eclipse.jdt.ui.tests.quickfix.AnnotateAssistTest1d5.testAnnotateReturn2():

!STACK 0
java.lang.ClassCastException: class org.eclipse.jdt.internal.core.ClassFile cannot be cast to class org.eclipse.jdt.core.ICompilationUnit (org.eclipse.jdt.internal.core.ClassFile and org.eclipse.jdt.core.ICompilationUnit are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @21452f5e)
	at org.eclipse.jdt.ui.text.folding.DefaultJavaFoldingStructureProvider.computeFoldingStructure(DefaultJavaFoldingStructureProvider.java:981)
	at org.eclipse.jdt.ui.text.folding.DefaultJavaFoldingStructureProvider.update(DefaultJavaFoldingStructureProvider.java:907)
	at org.eclipse.jdt.ui.text.folding.DefaultJavaFoldingStructureProvider.initialize(DefaultJavaFoldingStructureProvider.java:852)
	at org.eclipse.jdt.ui.text.folding.DefaultJavaFoldingStructureProvider.handleProjectionEnabled(DefaultJavaFoldingStructureProvider.java:822)
	at org.eclipse.jdt.ui.text.folding.DefaultJavaFoldingStructureProvider$ProjectionListener.projectionEnabled(DefaultJavaFoldingStructureProvider.java:700)
...
	at org.eclipse.jdt.ui.tests.quickfix.AnnotateAssistTest1d5.testAnnotateReturn2(AnnotateAssistTest1d5.java:178)
...

It seems the fInput isn't always an ICompilationUnit as the new code assumes. You'll have to "fork" the execution (with an if (fPart instanceof ICompilationUnit)) and preserve the old code too (in the else block).

It would be interesting to know when exactly is fInput not and ICompilationUnit and if it's possible to turn them into ICompilationUnits (in a separate PR). By the looks of it, it might be when one opens a .class file, probably one that displays source code, like java.lang.String:

[fedejeanne]

@iloveeclipse : Jakub and I were looking into the failed tests and we found the culprit: it was a null. After some debugging and evaluating we decided that a null-check would make sense since now (in this PR) it is possible to add folding structures for things that are not IJavaElements. This led to commit ade7b52.

Do you see any possible problem with this change? We couldn't come up with any but maybe you can?