Warning for collision of local variable and host-variable?

[OP1]

Shot in the dark... is there a way to have the compiler issue a warning when the name of a local variable (defined in a procedure contained in a module or submodule) collides with the name of another variable in the host module (or parent module, if the procedure is contained in a submodule)?

MODULE M
IMPLICIT NONE
INTEGER :: I
CONTAINS
SUBROUTINE S
IMPLICIT NONE
INTEGER :: I
END SUBROUTINE S
END MODULE M

[Steven_L_Intel1]

Nope - this is a standard language feature.relied on by many users.

[jimdempseyatthecove]

What you can do is in SUBROUTINE S, after IMPLICIT NONE, is to comment out all the variable declarations. The variables used in S that do not have "not defined" errors have name conflicts. Note, you may also receive type, rank, size, and/or shape error messages and these will mean the name of the variable is defined, but as a different type, rank, size, and/or shape. A few iterations of comment, compile, uncomment some, compile, ... and you should have things sorted out.

Jim Dempsey

[OP1]

Thanks Jim for the trick!

As Steve mentioned, having access to host variables is very useful (and used extensively) - but now having layers of nested submodules makes it a little more 'dangerous'  (for lack of a better word) than in the past, since it is easier to forget or lose track of variables declared somewhere else than where the procedure is CONTAINed. Having a warning for this (optionally activated) would be a nice-to-have feature (I don't know if this is feasible though).
 

[jimdempseyatthecove]

OP,

You also have ONLY to exclude those variables from the module not intended. Though in a sub-module it is not possible (to my understanding) to ONLY-fy the parent modules variables.

Jim Dempsey

[FortranFan]

OP wrote:

.. having access to host variables is very useful (and used extensively) - but now having layers of nested submodules makes it a little more 'dangerous'  (for lack of a better word) than in the past, since it is easier to forget or lose track of variables declared somewhere else than where the procedure is CONTAINed. Having a warning for this (optionally activated) would be a nice-to-have feature (I don't know if this is feasible though).

Fortran 2015 extends IMPORT statement to include, "IMPORT, ONLY : list", "IMPORT, NONE", and "IMPORT, ALL" and to apply it to CONTAINed subprogram and BLOCK constructs.

Just like enhanced interoperability with C from Fortran 2015, it will be highly welcome news if Intel implements this feature even before the standard revision is officially released.

[andrew_4619]

Another option is to put the module "global" variables in a separate module (data only with an empty contains section). Then in your module USE this data module in the module subroutines making use of the ONLY feature for the variables actually used. This is more work but name conflicts are avoided (you will get an error) AND if you look at the top of any  sub-program you can see exactly where every item comes from and what is actually used in the routine.

The only problem is that you can have USE module_name, ONLY: routine_name and not actually use routine_name as the "warn unused" doesn't  cover this case within modules.....

The Fortran 2015 features FF mentions look really really useful! YES PLEASE.

[OP1]

This extension of the IMPORT statement in Fortran 2015 looks exactly like what I need! Thanks FF for bringing this to my attention.