Another potential bug with IMPORT statements in INTERFACE blocks

[OP1]

The following code does not compile, as expected (the derived type T is declared after it is referenced in the interface block for USE_T).

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
PRIVATE :: T
INTERFACE
    MODULE SUBROUTINE USE_T(X)
    IMPORT, ONLY : T
    IMPLICIT NONE (TYPE, EXTERNAL)
    TYPE(T) :: X
    END SUBROUTINE USE_T
END INTERFACE
TYPE T
END TYPE T
END MODULE M

However, the following code DOES compile. But should it?

1. Shouldn't the compiler complain about the IMPORT statement
   referring T before the actual declaration of T in the module,
   even if it is not used (as it does in the code above)?
2. Alternatively, shouldn't the compiler indicate that the IMPORT, ONLY : T statement is superfluous since T has no bearing on the interface of S whatsoever?

MODULE M
IMPLICIT NONE (TYPE, EXTERNAL)
PRIVATE :: T
INTERFACE
    MODULE SUBROUTINE S
    IMPORT, ONLY : T
    IMPLICIT NONE (TYPE, EXTERNAL)
    END SUBROUTINE S
END INTERFACE
TYPE T
END TYPE T
END MODULE M

This is with IFX 2024.1.0 and the corresponding IFORT version.

[andrew_4619]

Hmm well in the first case the error "error #6457: This derived type name has not been declared. [T]" seems quite OK with me, I would not object to that.

In the second case I would guess the IMPORT is checked at the point of use  which does not exist. The compiler is still noy 100% on warn unused with "USE only " and "IMPORT' IMO but that is a different matter.  I am not sure this case is one to complain much about either but that is just my opinion.

[Steve_Lionel]

The answer to both questions is "no". All that is required is that T be "accessible within the host scoping unit". There's nothing wrong with declaring things that aren't used - some compilers have the ability to diagnose such things.

[OP1]

@Steve_Lionel Then, according to your logic, the first example above is a compiler bug, since "T is accessible within the host scoping unit" (despite it being declared after the interface)?

[Steve_Lionel]

No. T is accessible in the scope of module M. While there are places in the standard that require "previously defined", this is one of many cases where simply being accessible is OK, and anything declared in the module is accessible from within the module.

You may also want to read my post Domestic or Imported? - Doctor Fortran (stevelionel.com)

[OP1]

@Steve_Lionel could you please revisit your comments in this thread (and the other I posted in parallel on a similar topic), since I think that you missed the subtle distinction between SUBROUTINE and MODULE SUBROUTINE in the interface blocks?

[Steve_Lionel]

I have revisited the standard and don't see a reason to change my opinion here. I'm open to suggestions as to why I am mistaken. MODULE SUBROUTINE simply indicates that the subroutine will appear in a submodule, which will automatically have access to all entities declared in the module.

[Steve_Lionel]

I'll add that the IMPORT in this example has no effect, as everything in the module is accessible from the module procedure anyway.

[OP1 · Accepted solution]

ok, thanks @Steve_Lionel for double-checking. 

I suppose that the fact that the IMPORT, ONLY : T statement in the second example is useless (since T is of no use in that interface) is the reason why no compile-time error message issues at this point. Unlike the first example, where T is required to declare X. Maybe it's not the most intuitively consistent behavior but as @andrew_4619 said, this is probably not something to make a big fuss about.

[Steve_Lionel]

I may need to correct myself regarding the IMPORT being useless - at least I see that IFX complains if it is omitted. I thought the standard had relaxed this rule for module procedure interfaces, but I will check.

Edit: Ah, I see. MODULE SUBROUTINE doesn't necessarily indicate a submodule, so the normal rules for INTERFACE apply. Rather than repeating the interface, you could use MODULE PROCEDURE instead. See Doctor Fortran in "We All Live in a Yellow Submodule" - Doctor Fortran (stevelionel.com)