Inline functions (including multi-line and non-elemental functions)

[MichaelSt98]

Extending and improving Inline utilities as discussed in #377

[github-actions]

Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/378/index.html

[codecov]

Codecov Report

Attention: Patch coverage is 98.41270% with 3 lines in your changes missing coverage. Please review.

Project coverage is 95.51%. Comparing base (3834903) to head (53cc3fa).
Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
loki/transformations/inline.py	97.61%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #378      +/-   ##
==========================================
- Coverage   95.53%   95.51%   -0.03%     
==========================================
  Files         186      186              
  Lines       38974    39140     +166     
==========================================
+ Hits        37233    37383     +150     
- Misses       1741     1757      +16     

Flag	Coverage Δ
lint_rules	96.39% <ø> (ø)
loki	95.49% <98.41%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MichaelSt98]

The whole thing got a bit out of hand again and turned out to be a rabbit hole ...

Currently (or rather with this PR), nested functions are handled via an iterative approach. We could try to solve this recursively instead. However, I don't think this would be straight-forward and questionable whether this is beneficial. Anyway, I am open for discussing that and other implementation details.

Moreover, it would be possible to check whether functions are single-line (or could be reduced to a single line) and inline those at an expression level.

[mlange05]

Looks great, and is very, very useful! Many thanks, this one has been on the todo list for a while! 🙏 🙏 🙏 🙏 🙏 🙏 GTG

[reuterbal]

Very nicely done, this is a really fantastic addition and nicely executed!

A bunch of nitpick comments but no showstoppers.

[reuterbal]

This has also been fixed on the main branch, so we might want to remove the commit from this branch in a rebase.

[reuterbal]

Why? I can't see anything that would usually upset OMNI, and a quick parse with F_Front was successful for me.

[MichaelSt98]

If you execute

from loki import Subroutine, fgen, OMNI, FP
fcode = """
subroutine member_functions
    implicit none
    integer :: i
    real(kind=8) :: a(3)
    contains
    function add_to_a(b, n)
      integer, intent(in) :: n
      real(kind=8), intent(in) :: b(n)
      real(kind=8) :: add_to_a(n)

      do i = 1, n
        add_to_a(i) = a(i) + b(i)
      end do
    end function
end subroutine member_functions
    """
routine = Subroutine.from_source(fcode, frontend=OMNI)
print(fgen(routine))

SUBROUTINE member_functions ()
  IMPLICIT NONE
  INTEGER :: i
  REAL(KIND=8) :: a(3)
  CONTAINS
  FUNCTION add_to_a (b, n)
    IMPLICIT NONE
    INTEGER, INTENT(IN) :: n
    REAL(KIND=8), INTENT(IN) :: b(n)
    ! HERE: MISSING DIMENSION !!!
    REAL(KIND=8) :: add_to_a
    DO i=1,n
      add_to_a(i) = a(i) + b(i)
    END DO
  END FUNCTION add_to_a
END SUBROUTINE member_functions

Same thing for real(kind=8), dimension(n) :: add_to_a. This doesn't happen for FP and OFP.

[reuterbal]

This does sound like a bug in the Loki frontend, translating the OMNI AST to Loki IR, not a problem with OMNI.
Give me a sec, I'll have a look...

[reuterbal]

#391 should fix the problem

[reuterbal]

I have rebased and removed the pylintrc commit. Ready from my side now, many thanks again!