Submodule duplicate name issue

[singleterry]

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

[ivan-pi]

@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

! a@hello.f90
submodule (a) hello
contains
    subroutine hello_a
        print *, "hello from submodule a"
    end subroutine
end submodule

! b@hello.f90
submodule (b) hello
contains
    subroutine hello_b
        print *, "hello from submodule a"
    end subroutine
end submodule

When I put these files in src and run fpm build I get,

$ fpm build
 + mkdir -p build/dependencies
 Warning: Module hello in ././src/b@hello.f90 is a duplicate
<ERROR>*build_model*:Error: One or more duplicate module names found.
STOP 1

The error occurs here:

fpm/src/fpm.f90

Line 260 in 1cfcaf8

call fpm_stop(1,'*build_model*:Error: One or more duplicate module names found.')

The issue stems from the approximate parsing algorithm

fpm/src/fpm_source_parsing.f90

Lines 45 to 46 in 1cfcaf8

	!> @note Submodules are treated as normal modules which `use` their
	!> corresponding parent modules.

[singleterry]

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
use a
use b
call a%hello_a()
call b%hello_b()
end 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!

[ivan-pi]

The same bug appears also in the corner case when the module and submodule happen to share the same name, e.g.

! a.f90
module a
interface
module subroutine b
end subroutine
end interface
end module

! a@a.f90
submodule (a) a
contains
module subroutine b
print *, "hello"
end subroutine
end submodule

At least 5 processors appear to accept this (gfortran, flang, ifort, ifx, nvfortran).

[singleterry]

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!

[ivan-pi]

Ahhh! I see what your saying. It appears that every module and submodule MUST have unique names.

It's an fpm bug. As you've already explained, this is not required by the Fortran standard.