Produce a clean Task translation unit (TU) from raw m2c output that follows the project Task template and is ready for matching-focused iteration.
-
Do not rename any functions or globals during this refactor workflow. These symbols may be referenced in other files and could negatively affect external linkage and/or match progress should not every single instance of the symbol be updated. Instead, suggest the expected names for these symbols in the chat after applying the refactor for the developer to review and apply manually at their discretion.
-
Do not create any new functions or globals during refactoring. Work only with functions and globals that already exist in the raw m2c output. If callback signatures do not match, alter their implementations to meet the required signature. Do not create any form of wrapper or adapter.
-
Local variables may be created sparingly within existing functions as needed to meet the required signatures and structure, but avoid introducing new variables if unnecessary. Do not create new variables for the sole purpose of renaming or restructuring code; only introduce them when necessary to achieve the required function signatures.
-
Never create macros intended to simplify structure access. All structure access should be simple and direct, without indirection or obfuscation.
-
Macros to improve readability of complex expressions are acceptable, provided they appear multiple times in the TU and warrant the abstraction. Do not create macros for simple one-off expressions or to rename fields in existing structs.
-
Create type definitions conservatively. Beyond the two required local structs (<FileName> and <FileName>_Args), only define additional types if they are explicitly required by the callback signatures and memory layout.
-
NEVER recreate or locally redefine Task system types such as TaskPool, Task, TaskHandle, TaskStages, or their callback signatures in the TU.
-
Always include and use the canonical Task definitions from include/Engine/EasyTask.h.
-
If there is any mismatch between decompiler output and local guessed task types, resolve it by adapting TU code to the EasyTask.h definitions, not by creating substitute structs/unions/typedefs.
-
Function parameter names and function-local variable names may be renamed to descriptive names for readability and maintenance, as long as behavior and matching intent are preserved.
-
Member names of file-local structs defined within the TU may also be renamed to descriptive names when it improves readability and maintainability.
-
Local structs (the primary task state struct and the args struct) are file-scoped and not exposed outside the TU. They must be named after the filename: For example, a file named MenuTop_numMoney.c would define MenuTop_numMoney and MenuTop_numMoney_Args. No other naming format for these two structs is acceptable.
-
Define and initialize TaskStages directly inside the _RunTask function body. Do not move TaskStages to file-scope/static data or any helper outside _RunTask.
-
Example of required _RunTask function structure:
s32 _RunTask(TaskPool* pool, Task* task, s32 stage, void* args) {
TaskStages stages = {
.initialize = _Init,
.update = _Update,
.render = _Render,
.cleanup = _Destroy,
};
return stages.iter[stage](pool, task, args);
}
This exact line must be used to dispatch the lifecycle callbacks in RunTask. Do not use any other form of dispatch, such as direct calls, switch statements, if statements, or inline conditionals.
-
Do not add explicit unused-parameter suppression lines such as (void)pool;, (void)task;, or (void)args;. Leave unused parameters unreferenced.
