Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xtend refactoring handling of anonymous class #2898

Merged

Conversation

LorenzoBettini
Copy link
Contributor

Another proposal for #2886

there's no need to store the converter
@LorenzoBettini
Copy link
Contributor Author

This is another working proposal for this issue that does not touch the inferred model.

the changes are rather minimal:

  • the inferrer always sets the inferred type for AnonymousClass as anonymous
  • a new XtendCompilerHelper performs the check the inferred used to do, i.e., the anonymous class does not contain fields or methods that are not overridden
  • the XtendGenerator uses this helper to know whether it has to create nested local classes instead of anonymous classes; previously, it only checked JvmGenericType.isAnonymous.
  • the XtendCompiler redefines the new XbaseCompiler.canCompileToJavaAnonymousClass(XConstructorCall constructorCall) introduced in Xbase/Xtend refactoring #2890 and delegates to XtendCompilerHelper
  • a custom TreeAppendable, I called that AnonymousClassAwareTreeAppendable, but it could be called XtendTreeAppendable, uses a custom LightweightTypeReferenceSerializer to decide what to do with JvmGenericType that are "anonymous", again, using the XtendCompiler. This is useful to intercept all the serialization of types related to anonymous classes correctly. While the previous customizations catch anonymous classes in "new" expressions, this one catches the occurrences of related types in other parts, e.g., in local variables in case anonymous classes are compiled into nested local classes.

This way, during the Xtend compilation process, anonymous classes are correctly generated as Java anonymous classes or nested local classes. All the tests are green. All the generated code is as before. No test has been touched apart from this one https://github.com/eclipse/xtext/pull/2898/files#diff-8d2c98464642a8554f494c6f4c1de6f865cbec0d6cb5b288412da41e6067cba1L222 of course.

/**
* @author Lorenzo Bettini - Initial contribution and API
*/
public class XtendCompilerHelper {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this can only answer whether a JvmType can be compiled to an anonymous class, maybe a more restrictive name should be chosen?
AnonymousClassCompilerHelper?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed that was my second choice, so I'll rename it :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -320,7 +330,9 @@ class XtendGenerator extends JvmModelGenerator implements IGenerator2 {
}
if (declaringType.local && it instanceof JvmOperation) {
val declarator = declaringType as JvmGenericType
if (!declarator.anonymous) {
if (!declarator.anonymous ||
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure whether I like the fact that the helper doesn't check the declarator itself but this code here has to do both.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed I had put a Javadoc comment on the helper https://github.com/eclipse/xtext/pull/2898/files/bc766b0068465148679855a36c8c9c88e5c62065#diff-c6ea2a981e27e70dc2cd53ff982ee051ac65096607807462e10196d625518f88R35
to avoid a check there, but if you prefer we can check isAnonymous directly in the helper, if that's what you mean.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@szarnekow I've just pushed 6af742c

that check for anonymous is redundant

feature.localClasses.filter[ !anonymous ].forEach[
appendable.newLine
feature.localClasses.forEach[
if (compilerHelper.canCompileToJavaAnonymousClass(it)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yet this code here doesn't do both.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least in the current implementation anonymous classes are local classes

/**
* @since 2.34
*/
def TreeAppendable createAppendable(ImportManager importManager, ITraceURIConverter converter,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be protected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right! I think so.

Copy link
Contributor

@szarnekow szarnekow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I like this change. Just a few small comments / questions.

@LorenzoBettini
Copy link
Contributor Author

Closing and re-opening to trigger CI rebuild

@LorenzoBettini LorenzoBettini reopened this Feb 5, 2024
@LorenzoBettini LorenzoBettini merged commit 447dc2c into eclipse-xtext:main Feb 6, 2024
8 checks passed
@LorenzoBettini LorenzoBettini deleted the temp-xtend-anonymous-class-2 branch February 6, 2024 08:34
@LorenzoBettini LorenzoBettini added this to the Release_2.34 milestone Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants