Week 11: Submodule Implementation

Hi everyone, welcome to the eleventh blog of my GSoC'25 journey. A major update from eleventh week is Succesful Completion of Submodules Implementation for Monolithic Compilation. Apart from these, I also worked to support declarations made in Module Procedures and reverting Submodule workarounds from Stdlib in Separate Compilation mode.

I started the week by extending my previous Merged Pull Request Pull #8126, which implemented modules procedures, to add support for declarations made in module procedures. It was not a difficult task as we just needed to iterate over AST Declarations and visit them one by one. Also, I made some small modifications in our previous implementation for module procedure. Link to Merged Pull Reqest for the same is Pull #8142.

Then onwards, I started to continue my work on Submodule Implementation for Monolithic Compilation. The current implementation for it was almost correct and complete. But, still we weren't able to test submodules in monolithic compilation due to CMAKE issue. So, first of all, I created a new label llvm submodule and prepared a script for it which was responsible for executing all the files in correct order, create object files for them and finally, link them all to correctly run the test.

CMAKE Script for llvm submodule label


        set(object_files "")
        set(prev_file "")
        foreach(extra_file ${extra_files})
            get_filename_component(obj_name ${extra_file} NAME_WE)
            add_library(${obj_name} OBJECT ${extra_file})
            target_compile_options(${obj_name} PUBLIC $<$<COMPILE_LANGUAGE:Fortran>:${extra_args}>)
            if (prev_file)
                add_dependencies(${obj_name} ${prev_file})
            endif()
            set(prev_file ${obj_name})
            list(APPEND object_files $<TARGET_OBJECTS:${obj_name}>)
        endforeach()
        add_executable(${name} ${file_name}.f90 ${object_files})
        target_compile_options(${name} PUBLIC $<$<COMPILE_LANGUAGE:Fortran>:${extra_args}>)
        add_dependencies(${name} ${prev_file})
        add_test(${name} ${CURRENT_BINARY_DIR}/${name})

After this, I registered this as a backend and updated ci to run integration tests for this label in both monolithic and separate compilation modes. With these, our Submodule Implementation for Monolithic Compilation was complete after some refinements. But still, some checks were failing on ci. Failures were due to two reasons :-

We changed modfile name for submodules by adding parent module name as prefix. But, CMAKE only needs submodule name in its modfile which caused CMAKE error.
We were loading submodules whenever we encountered a use statement even if correspondig file doesn't has a program. This caused duplication, serialization and deserialization errors in Stdlib.

These failures were handled using following solutions :-

For the first problem, we created an extra empty modfile using only submodule name for submodules to satisy the CMAKE condition.
For second problem, we maintained a boolean variable in_program to track when or codeflow is in Program Scope. Using this, we restricted all our load submodules calls only for Use statement in Program Scope.

Using these solutions and some minor refactorings, we were able complete our work on submodule implementation for monolithic compilations. Following are the links to Pull Requests for this complete approach :-

Pull #8184 : For ASR related changes
Pull #8159 : For implementing submodules in monolithic compilation

Following this, I started to work on reverting submodule workarounds from Stdlib in Separate Compilation mode. I have made decent enough progress in doing so and have reverted almost all the workarounds. Link to the branch for tracking this is sc-lf-revert-submodules-1.

For the next week, I am planning to continue this reverting process also, for monolithic compilation mode. I have also identified some errors while reverting submodule workarounds. Will also create MREs for them and fix them in my next week.

Overall, I worked for 33 hours this week and enjoyed the work that I did in the eleventh 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.