-
Notifications
You must be signed in to change notification settings - Fork 109
Submodule duplicate name issue #1063
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@singleterry, could you provide a minimal-working example of your problem? I've tried to reproduce this issue: ! a.f90
module a
implicit none
private
interface
module subroutine hello_a
end subroutine
end interface
end module
! b.f90
module b
implicit none
private
interface
module subroutine hello_b
end subroutine
end interface
end module
! [email protected]
submodule (a) hello
contains
subroutine hello_a
print *, "hello from submodule a"
end subroutine
end submodule
! [email protected]
submodule (b) hello
contains
subroutine hello_b
print *, "hello from submodule a"
end subroutine
end submodule When I put these files in
The error occurs here: Line 260 in 1cfcaf8
The issue stems from the approximate parsing algorithm fpm/src/fpm_source_parsing.f90 Lines 45 to 46 in 1cfcaf8
|
Your example captures the error. The submodule label "hello" attached to module hello_a and hello_b is legal according to the Fortran Standard as quoted above. app.f90 should be able to then call (assuming hello_a and hello_b are public): program app The submodule label hello should not be local or global name and does not have to be unique according to the standard. Is it good programming practice? NO! Can it happen? YES! Especially in large systems where many disparate parts (modules) are brought together to create a larger task/app which were not thought to be related. Which is what I did. I always call the submodule that sets and gets private data assessors_smod.f90: module ( name ) accessors_smod. This name then conflicts and errors FPM when it should not. Of course, this is one example only. I am sure there are many! Thanks! |
The same bug appears also in the corner case when the module and submodule happen to share the same name, e.g.
At least 5 processors appear to accept this (gfortran, flang, ifort, ifx, nvfortran). |
Ahhh! I see what your saying. It appears that every module and submodule MUST have unique names. While probably good programming practice, sometimes, not doable! One solution is to prefix/posfix the module/submodule name with module or submodule in the sort routines??? Not sure how this would affect things down the line in FPM. I'll leave the solution to the experts on FPM! That's not going to work. Maybe prefix/postfix the submodule name with its corresponding module? Again, to the experts! |
It's an fpm bug. As you've already explained, this is not required by the Fortran standard. |
Description
A submodule has the same name either in a dependant library or in the same library but the module it is attached to have different names. The standard says
14.2.3 line 6: “… the submodule name by itself is not a local or global identifier.”
The fix to avoid this bug is easy: all submodule names are different (probably a best practise issue anyway).
Expected Behaviour
I always put the accessors for private data in a submodule with the name accessors_smod. They are attached to unique module names. FPM should not error and compile properly as the compilers will not balk at this.
Version of fpm
0.10.0, alpha
Platform and Architecture
linux
Additional Information
No response
The text was updated successfully, but these errors were encountered: