Fixes of keyword renaming

[zhucaoxiang]

This is an updated version of #160 . Sorry for not looking at this issue for so long. I found that my fork deviates from the official repo and it is difficult to resolve conflicts.

In the past years, my colleagues and I are actually using my fork to avoid issues in renaming keywords. For example, in the following Fortran source (now included in the /examples).

module global

    implicit none
    
    type class2
        integer :: x = 456
    end type class2

    integer :: abc=0
    integer, parameter :: lambda=1
    integer :: with(9)
    
    contains
    
    subroutine is(a)
        implicit none
        integer,intent(in) :: a

        abc = abc + a
        return 
    end subroutine is
end module global

integer function in(a)
    implicit none

    integer, intent(in) :: a

    in = a + 1

    return
end function in

There are module, type, subroutine, and function names conflicting with Python system keywords. The existing public version will report errors (first with the module name). I managed to fix most of them except the derived type, although the derived type name was also working in my old fork.

[jameskermode]

Thank you for the contribution. As you will have seen there are failures in the regression tests so this can't yet be merged. Are you working on fixing the failing tests?

[zhucaoxiang]

@jameskermode Yes, I noticed the errors and am working on finding solutions.

[smiet]

I see that the test are passing, could this fix be merged soon?

With the numpy 2.0.0 update the diverged branch of @zhucaoxiang is no longer compiling, and maintaining it is suboptimal to directly using yours.

[jameskermode]

Yup, I'll take a look. It seems there are now some conflicts, if you are willing to try to resolve them that would speed things up.

[smiet]

I am glad to help!

I cannot see the conflicts myself, I pulled jameskermode:master into my branch of zhucaoxiang:main_off and there were no merge confilcts. Am I missing something?

I don't have write permission to @zhucaoxiang's f90wrap branch. Could you trigger the tests again to see if they still pass?

I will ask @zhucaoxiang for write permission and hopefully lay this issue to rest.

[zhucaoxiang]

@smiet I have sent you invitations.

[jameskermode]

I'm just going from the GitHub warning above about conflicts. Rebasing on current master should solve it.

[smiet]

There you go, ready to merge I believe!

I see that #220 addresses numpy2.0 support better than what I had done.

[jameskermode]

Thank you - I will merge providing the CI tests pass.

[jameskermode]

@smiet and/or @zhucaoxiang there are some remaining test failures I am afraid - would you be willing to take a further look?

[smiet]

Could you restart the tests now that #220 has been merged? This should hopefully fix it (on our branch I had the same error before I switched to numpy2.0).

If that doesn't fix it I'll have to get back on it tomorrow.

[jameskermode]

You'll first need to update this branch from master to bring in the changes

[jameskermode]

Still failing tests I'm afraid

[smiet]

Sorry, Caoxiang ran black over the source and it is really hard to disentangle the logic changes from all the syntax changes. I found a change I missed and have pushed it now, my apologies. This is on us, and I will keep iterating until all tests pass.

[inoelloc]

diff --git a/f90wrap/f90wrapgen.py b/f90wrap/f90wrapgen.py
index 0c82bfe..a526dfa 100644
--- a/f90wrap/f90wrapgen.py
+++ b/f90wrap/f90wrapgen.py
@@ -497,9 +497,7 @@ end type %(typename)s_rec_ptr_type"""
         self.write_transfer_out_lines(node)
         self.write_finalise_lines(node)
         self.dedent()
-        self.write(
-            "end subroutine %(sub_name)s" % {"sub_name": self.prefix + node.name}
-        )
+        self.write("end subroutine %s" % (sub_name))
         self.write()
         return self.generic_visit(node))

It seems to work with this change

[inoelloc]

A Makefile.meson is missing from the test folder

include ../make.meson.inc

NAME     := keywordr_rename

test: build
	$(PYTHON) tests.py

[zhucaoxiang]

Thanks to @inoelloc, all the tests have now been passed. @jameskermode @smiet

[jameskermode]

Thanks very much! I have also reviewed the substantive changes and am in principal very happy to accept this contribution. The only thing that gives me a pause for thought is the large number of changes introduced due to reformatting with black which messes up the git history rather and makes it hard to see what the meaningful changes are. Would one of you be willing/able to revert this? If it is not possible I will probably merge, albeit a bit relunctantly.

[zhucaoxiang]

which messes up the git history rather and makes it hard to see what the meaningful changes are. Would one of you be willing/able to revert this?

I probably did this with automatic formatting. I will check if there is a way to revert it.

[zhucaoxiang]

I realized that most of the changes were saved in one commit (https://github.com/jameskermode/f90wrap/pull/194/commits/ab3798d29edcbc2d9cebb158f18f6b695df5e790). There seems no elegant way to revert it unless we go through the two files line by line. I am sure I was using VSCode auto-formating, so there should be no content revised unintentionally. @jameskermode Are you fine with what it is? I am sorry for the inconvenience.

[inoelloc]

@zhucaoxiang Can you confirm that the only changes applied are on name and orig_name variables ?

[smiet]

We apologize for the syntax changes. Unfortunately, isolating them isn't feasible as the initial commit contains substantial amounts of logic changes. @zhucaoxiang and I explored solutions together but found no easy fix. There are more changes relating to single or double _ and __ strings.

We kindly request your acceptance of the PR as-is. And we will ensure that it doesnt' happen again.

[zhucaoxiang]

@zhucaoxiang Can you confirm that the only changes applied are on name and orig_name variables ?

That's the main change. But the problem is that I cannot guarantee that's the only change. I modified the files last year.

[inoelloc]

@jameskermode Are you planning to release on PyPI once this PR has been merged ?

[jameskermode]

Yes. I will go ahead and merge this then do a PyPI release. Thanks everyone for the work!