[BUG] Changed AST tree even though no lombok used in file

[LukasBasiura]

Hi, recently I saw some strange behavior for me in eclipse ast while developing eclipse plugin. On a method like this:

public class Simple {

    public void method() {
        int a, b; int c;
    }
}

after installing lombok I see two nodes instead of one node in AST tree in place of this expression : int a, b;

AST structure without lombok

{
      "name": "XTypeDeclaration",
      "pos": " [26,112] ",
      "parentName": "XCompilationUnit",
      "parentPos": " [0,114] ",
      "content": "public class Simple {\n  public void method(){\n    int a, b;\n    int c;\n  }\n}"
}

AST after installing lombok :

{
      "name": "XTypeDeclaration",
      "pos": " [26,112] ",
      "parentName": "XCompilationUnit",
      "parentPos": " [0,114] ",
      "content": "public class Simple {\n  public void method(){\n    int a;\n    int b;\n    int c;\n  }\n}"
}

As you can see node TypeDeclaration in eclipse now resolves to int a;\n int b;\n while in original file it is int a, b; The most surprising thing is that i do not use lombok in this class.

This behaviour started to occur since lombok 1.8.20 and is present in 1.8.22. Do you know something about this behaviour ?

[Rawi01]

Lombok does not change the source, it only modifies the AST but only if there is a lombok annotation. I created an example that declares multiple variables, added a breakpoint in the first lombok method and noticed that eclipse already splitted it up into multiple LocalDeclaration nodes.

Have you checked that the problem goes away if you downgrade to an older lombok version? How do you get the source for a TypeDeclaration?

[rzwitserloot]

Vehement agreement with @Rawi01 here: That's an extraordinarily claim, given that lombok simply doesn't do anything until it sees lombok annotations. Lombok definitely isn't expanding LocalDeclaration/FieldDeclaration like this, ever. If you're observing it, either you're getting the run-around from eclipse and it's not actually lombok related somehow, or, lombok is calling 'getters' on the AST nodes and eclipse is doing it in those methods.

In that last case I'm pretty sure that if lombok hadn't 'caused it', something that is about to happen (firing off save actions, compiling the file, etc - something inevitable that is about to occur) would do it, so then there really is no issue here: Something is going to expand that node no matter what, lombok merely makes it happen a blink-of-an-eye earlier than without lombok. Doesn't sound like a thing we should attempt to 'fix'.

However, the one thing that makes me pause and think: Maybe we should look into this, is that if this is caused by attribution (which is somewhat expensive), and it occurs even in files with no lombok annotations in it, then that means lombok's mere presence causes more attribution than required, so if we can eliminate it, we speed up eclipse+lombok, and that's worthwhile.

Here are the next debug steps as I see it. It's quite a bit of work, perhaps - not sure when we have the time to do this. But if someone else cares to do this, muchos gracias, owe you a drink of your choice:

• First, and looking at @LukasBasiura here - I want to ascertain in which scenario(s) is whatever-it-is-that-causes-the-expansion not inevitable anyway? As in, which scenarios exists where, if lombok wasn't there, we save the cost of that attribution. To be clear, if all that removing lombok would do is that you still get the same number of attribs, but they would merely occur a little bit later, there's no relevant performance gain to be had. So, what actions attrib only if lombok is loaded in eclipse? A great answer to this question would be something like: "Set 'auto-format on save' in save actions, make an edit in a file with int a, b; in it and no lombok annotations at all. Save the file: With lombok, that int a, b; is expanded, without it, it isn't." That one is a double whammy - not just a performance win, also an actual 'bug' of sorts; mere presence of lombok shouldn't change the behaviour of the auto-formatter.

• Assuming the above leads to a 'yes' answer., and not just 'only when you use this (fairly obscure) plugin': A reproducible case that comes up often enough that warrants spending the time, then - Write some code that, with the lightest of touches, finds a specific int a, b; node (say, it's always in the top level class, first FieldDecl object), and prints the current status (expanded or not). Preferably using only field reads, we want to avoid whatever it is we do that causes the expansion. Then, pepper the lombok transformation process with calls to it to figure out which exact line causes eclipse to perform the expansion. That look if we can avoid it, or if we can do a pre-scan to early-exit if no lombok is found. Could do with a debug breakpoint + a watch as well.