name clash with lambda as anon inner class compilation

[dpetroff]

Today I upgraded from Xtend 2.21 to 2.26 and my code base broke the IDE generator targeting Java 11.

Consider the method

def getMyAdapter(extension EObject it) {
	eAdapters.filter(AdapterImpl).head ?: (new AdapterImpl() => [eAdapters += it])
}

In the most recent Eclipse package (2022-03), the IDE generator generates distinctly different code from gradle for this example. In particular, the gradle generator uses Java lambda notation, while the IDE does not. Additionally, the IDE generated code also results in broken Java because it does not disambiguate between the EObject it and the Adapter it inside the lambda. Notice that the EObject it is declared as an extension, so the eAdapters call inside the lambda should apply to it. This works as expected when building with gradle and previous versions of the IDE, but the current IDE generator does not appear to disambiguate between the two its, which results in broken Java code.

myGradleProject.zip is a minimal gradle project reproducing the issue. Note that building with gradle is successful, including the test phase, and as long as the IDE generator doesn't rebuild the source after refreshing the gradle project in the IDE, there are no errors in the editor. Once the IDE has rebuilt the source, it is necessary to rebuild again with gradle and refresh the gradle project in the IDE again to get rid of the error.

[cdietrich]

no no clue what change could have caused this. unfortunately not too many people seem to test milestones :(

[cdietrich]

workaround:
have a org.eclipse.xtend.core.Xtend.prefs
with

useJavaCompilerCompliance=true

having

targetJavaVersion=Java11
useJavaCompilerCompliance=false

causes the problem

am not sure if this is a problem in the gradle plugin
downgrading the plugin to 2.1.0 helps
@szarnekow @oehme any idea?

[cdietrich]

config.getJavaSourceVersion().isAtLeast(JAVA8) is false
this is cause there is no settings file
and the default is somewhere else.

the pref has
targetJavaVersion=Java11
and not
targetJavaVersion=JAVA11

i thought this was fixed in the plugin....

[dpetroff]

I noticed the workaround you suggested shortly before you posted it. However, it seems the Refresh Gradle Project action recreates the preference file and sets the option to false every time, which is not great as I frequently have to do it and have many subprojects that get reset. This is starting to look more like a gradle plugin issue.

[cdietrich]

yes this is a bug in xtext-gradle-plugin

[cdietrich]

can you build this branch locally and test it
https://github.com/xtext/xtext-gradle-plugin/compare/cd_xtendIssue1301
./gradlew pTML -PreleaseVersion=3.0.2-SNAPSHOT -x test
then add maven local and use classpath plugin application

(you may need to delete existing xtend and xtext.java prefs)

[dpetroff]

I still think there is also an Xtend generator component to it. Setting aside the failure to identify the correct Java compliance level, the correctly-generated code has a lambda with it_1 as the variable, while the incorrect code generates a procedure with it as the variable, which shadows the original it from the containing scope.

I'm also seeing a lot of weirdness with the useJavaCompilerCompliance setting being stuck to false in my projects, while at the same time being stuck to true in the gradle project I attached before, regardless of what the actual preference file says.

[cdietrich]

yes it also should work conflict free with anonymous inner classes

[cdietrich]

if you want an opt out for useJavaCompilerCompliance or settings generation,
maybe you can disable
xtextEclipseSettings task somehow.
if not file an enhancement request for the plugin

[cdietrich]

i have no clue why we dont get the settings configured in e.g. xtext-core codebase

[cdietrich]

@dpetroff any update?

[cdietrich]

@rubenporras the anonymous class has name clash issue would be something for you to look at if you want to dive into xbase

[rubenporras]

Hi @cdietrich ,

why do you think it would be something for me?

do you think a PR I merged in Xtext 2.25 could have broke something or do you think I could be interested in the topic?

Regards