GSoC 2026 - Type Management Test Suite: Phase 1 Architecture Questions

[retryoos]

Hi everyone,

I am Dimitris the GSoC 2026 contributor working on the Type Management Refactoring Test Suite with Michael Oberlehner as my mentor. I have been reading through the refactoring code before Phase 1 starts and have a few questions where I want to confirm my understanding.

RenameUpdateFBTypeInterfaceModelEdit does not seem to be instantiated anywhere. The cascade for a DataType rename goes through TypeRefactoringHelper.addModelEditsForType() to DataTypeEditBuilder.createStructuredDataTypeChanges(), which produces DataTypeEdit instances for VarDeclaration objects and UpdateConfigurableFBModelEdit for ConfigurableFB objects. RenameUpdateFBTypeInterfaceModelEdit exists in the rename package with a full implementation but I cannot find it being called anywhere in the production code. My proposal listed it as one of the core assertion targets so I want to clarify if is it intentionally not wired in, because DataTypeEdit already covers FB interface variables since they are also VarDeclaration objects or is it meant to be called somewhere and currently missing?

The second question I have is about the correct headless API to trigger RenameTypeRefactoringParticipant from a JUnit test. Since it extends RenameParticipant it needs to be activated via an LTK RenameRefactoring rather than called directly. Is the right approach to build a RenameResourceDescriptor for the IFile, wrap it in a RenameRefactoring, and run it with PerformRefactoringOperation? The existing tests using FordiacProjectLoader do not perform refactoring operations so I do not have a prior example in the repo to follow.

Thank you in advance for your time and guidance.

[oberlehner]

Hello Dimitris,
RenameUpdateFBTypeInterfaceModelEdit has been replaced with a simple DataTypeEdit. see #2374
The approch is , we first search all data type instances (PINs in blocks (Block Type definitions and their usages) , Structured Type Members, STRUCT_DEMUX block, STRUCT_MUX and F_MOVE block) with the datatype search and then apply an edit on it.

Since we are currently trying to simplify the code.
Therefore, it seems that you found some dead code and RenameUpdateFBTypeInterfaceModelEdit should be deleted.
Thx for pointing that out!

Regarding your second question:
Yes, the right direction is to trigger the normal LTK resource rename refactoring, not to instantiate RenameTypeRefactoringParticipant directly. The participant is contributed through the rename-participant extension point and is selected by LTK when the renamed element is an IResource/IFile matching the enablement.

I would not manually wrap the descriptor in a RenameRefactoring. For the resource rename case, use RenameResourceDescriptor from org.eclipse.ltk.core.refactoring.resource, create the refactoring context from the descriptor, and execute it via PerformRefactoringOperation.

You may have a look at JDT (eclipse for java) refactoring. maybe this helps you to understand the LTK refactoring life cycle:

https://github.com/eclipse-jdt/eclipse.jdt.ui/blob/a104dedb32575adeb1235807131a3540bf32fd87/org.eclipse.jdt.ui.tests.refactoring/test%20cases/org/eclipse/jdt/ui/tests/refactoring/GenericRefactoringTest.java

[retryoos]

Thank you for the clarifications and for confirming the dead code find I will open a cleanup PR to delete RenameUpdateFBTypeInterfaceModelEdit.