Hi everyone, welcome to the tenth blog of my GSoC'25 journey. There were two major tasks which I performed during this week. First task was to Implement Submodules in separate files for Monolithic Compilation without using any additional compiler option. Another task which I performed was to Implement Module Procedures for Submodules by creating a new ASR Function.
Starting with the first task, I spent some time looking over stlib src files over various packages so that I can find a way to distinguish a regular module from parent module (module which can have submodules) during compile time. After spending some time, I was able to deduce that any module can be parent module if it has atleast one Function Node having module field in its FunctionType as true. In short, if a module has either a module subroutine or a module function, then that module can be a parent module. I was able to vaildate this fact using GFortran which was additionally, generating a smod file for its future submodules when above condition was getting satisfied.
After this, I used this information to create a new flag has submodules in Module ASR. By doing this, we were abe to get rid of compiler option --add-submodules through which we were externally providing submodule names that we wanted to load while compiling our program file. So, now onwards, we were saving modfile for submodules after adding parent module name as prefix to modfile name. This way, we can get all our submodule modfiles correspondig to a parent module just by parent module name.
So, finally, whenever we encouter a use statement in prgram file, we will load the module correspondig to it. If the loaded module is a parent module (has submodules flag is true), then, using parent module name, we file find all the submodule files and load the ASR of all the submodules of that parent module in Global Scope while executing program file. This way, we will be able to generate LLVM Functions for all our submodule implementations and thus, our submodules will get implemented for Monolithic Compilation.
I was able to implement this complete approach and it was working well when we compiled all the files one after another in correct order. But still, the apporach had one problem. In CMAKE, the order of compilation of these files is derived internally based on use statements in prgram file. But our program file doesn't has use statement for submodule and thus, CMAKE was not able compile submodule files before executing program file. This caused an error while loading modfile for submodules in CMAKE. The complete documentation for this issue and its suggested solutions can be found here.
Now, lets move to our second task. I implemented module procedures for submodules in two phases. Firstly, it was implemented in AST SymbolTable Visitor. Here, a new ASR Function was created with an empty body. Arguments, return var, function signature etc. were taken from module interface present in parent module with some minor changes like scope updation, defType modification (to implementation) and abiType modification (to source). Then, it was implemented in Ast Body Visitor where body of Function (representing module procedure) was populated. Also, function dependecies for module procedures were updated. This is how, our module procedures were implemented for submodules. Link to Pull Request for the same is Pull #8126.
For the next week, firstly, I am planning to extend my work on module procedures to support module procedures in a module efficiently. Also, will handle Declarations made in module procedures as currently, they aren't working. Also, I will wrap up Submodule Implementation for Monolithic Compilation as soon as possible after a bit of discussion toady. Then onwards, I will work to robustify submodules by reverting stdlib submodules workarounds and fixing things that break. Also, their is one more thing that we will need to handle which is nesting submodules. Will also start my work on it, if the time permits.
Overall, I worked for 24 hours this week and enjoyed the work that I did in the tenth week and would like to thank Ondrej Certik, Harshita Kalani, Pranav Goswami and all the other LFortran members for their reviews and suggestions which helped me a lot to tackle new difficulties. I am looking forward to continue my journey in the next week with the same excitement and enthusiasm and plan to complete my proposed tasks as quickly as I can.