Bug: Refactor procedures ignores interface keyword

[gnikit]

Requesting to indent and refactor (-Rr) the following code the interface block is completely ignored.

   INTERFACE MatCreateShell
      SUBROUTINE MatCreateShell(comm,mloc,nloc,m,n,ctx,mat,ierr)
         use petsc
      MPI_Comm :: comm
      PetscInt :: mloc,nloc,m,n
      TYPE(integer) :: ctx
      Mat :: mat
      PetscErrorCode :: ierr
      END SUBROUTINE MatCreateShell
   END INTERFACE MatCreateShell

On a separate note, I understand that the -Rr | -RR are only meant to change the case of the end ... lines but it would be nice/reasonable if the casing of the of the function/subroutine/procedure/... also used the same casing e.g.

      subroutine MatCreateShell(comm,mloc,nloc,m,n,ctx,mat,ierr)
         use petsc
         MPI_Comm :: comm
         PetscInt :: mloc,nloc,m,n
         TYPE(integer) :: ctx
         Mat :: mat
         PetscErrorCode :: ierr
      end subroutine MatCreateShell

[wvermin]

Indeed, -Rr ignores END INTERFACE, but also END TYPE. As it is now, only lines where a single END is permitted are refactored, to ease converting from old fortran decks to modern fortran. I will have a look at extending the refactoring to END INTERFACE/TYPE (are there others too?). The name of the flag --refactor-procedures would not be so adequate any more, --refactor-end would be more appropriate. About the case of the name of the subroutine/function/etc: findent takes the name as defined. I see no benefit in flattening the CamelCase.

…

On 24/09/2021 21.15, gnikit wrote: Requesting to indent and refactor (|-Rr|) the following code the |interface| block is completely ignored. INTERFACE MatCreateShell SUBROUTINE MatCreateShell(comm,mloc,nloc,m,n,ctx,mat,ierr) use petsc MPI_Comm:: comm PetscInt:: mloc,nloc,m,n TYPE(integer):: ctx Mat:: mat PetscErrorCode:: ierr END SUBROUTINE MatCreateShell END INTERFACE MatCreateShell image <https://user-images.githubusercontent.com/16143716/134727787-b5a34c16-5aad-403a-8a4b-714362e8e47a.png> On a separate note, I understand that the |-Rr | -RR| are only meant to change the case of the |end ...| lines but it would be nice/reasonable if the casing of the of the function/subroutine/procedure/... also used the same casing e.g. subroutine MatCreateShell(comm,mloc,nloc,m,n,ctx,mat,ierr) use petsc MPI_Comm:: comm PetscInt:: mloc,nloc,m,n TYPE(integer):: ctx Mat:: mat PetscErrorCode:: ierr end subroutineMatCreateShell — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALUKU56ALFAHOYJXT4OAQTUDTE3PANCNFSM5EWSKQZA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[gnikit]

are there others too?

To the best of my knowledge no. Only things that spring to mind are labelled statements like label: where ().... but if the label is missing from the end where then that is invalid code, so we shouldn't have to worry about such cases.

About the case of the name of the subroutine/function/etc: findent takes the name as defined. I see no benefit in flattening the CamelCase.

I think there was a miscommunication. I meant the actual letter case of the Fortran keyword, not the subroutine name.
If you look at line 85 in the diff, END SUBROUTINE has become end subroutine. I think that is reasonable since we requested -Rr, but if you look at line 78, the keyword SUBROUTINE has remained unchanged which results into the funny looking code

SUBROUTINE name()
...
end subroutine name

As a side note, I agree with you about changing the case of function/sub/etc. names. For example this is a subroutine where having a camel case naming convention serves a purpose. The subroutine is an interface to a C function so using the exact same case as the C code helps keep searches simple and consistent.