Hoisting arrays with kind specifiers imported from a module doesn't hoist the import statement `HoistLocalArraysTrans`

[LonelyCat124]

In this code

module my_mod
   ...
   contains
subroutine my_sub(...)
   use realtype, only: my_real
   real(kind = my_real), allocatable, dimension(:,:) :: my_array
end subroutine
end module

When the my_array is hoisted to the module in the transformation scripts (using HoistLocalArraysTrans) the my_real declaration isn't hoisted into the module, so the code doesn't compile.

[arporter]

Daley has reported that commit aacd0bf has 'fixed' this problem in that it now catches this case and forbids it. However, in so doing we have effectively disabled hoisting for all arrays in NEMO (since they always have a precision defined by a symbol). We need to extend HoistLocalArraysTrans to hoist (or at least copy to an outer scope) any symbols it depends on too.

[arporter]

Of course, in NEMO we won't know where e.g. wp comes from by default because of the wildcard imports. However, I think the fact that we now list the source module as one of the ones the frontend is to resolve should solve this problem.

[sergisiso]

From my email today:

Indeed, the problem is that we don't know where the "wp" symbol comes from. When extending HoistLocalArraysTrans for allocatable I found that almost nothing was hoisted (allocatable or not) because of this.

The typical solution for this is to "chase" imports for the module that this symbol comes from, then psyclone knows where it comes from. However in this case it comes from a transitive import. A "use module" than contains another "use module" that declares the symbol. We don't currently support that (at some point I want to but for now it is too slow).

Another solution that I am exploring is that there is no "use module" inside subroutines in most of NEMO, so the logic could be something like, if "wp" is unresolved (we don't know where it comes), and there is no module with wildcard imports inside the subroutine, assume it is fine to hoist. I implemented this in my branch but when I launched the integration test it failed. I then got sidetracked by other things but I will come back to explore why it failed soon.

[sergisiso]

Simon suggested using a option to manually disable where symbols come from for certain variables. A "force" for the CodeBlock restriction can also be useful. I will explore it in the ongoing #2893