Checking of overriding function result characteristics

[IanH]

A feature request - I appreciate there's no constraint, but 12.0.2 and earlier will complain if an overriding procedure doesn't have a argument list that appropriately matches the overridden procedure, which is nice. Could we please have that check extended to function results as well?

[fortran]MODULE A_mod IMPLICIT NONE PRIVATE TYPE, PUBLIC :: A_type CONTAINS PROCEDURE, NOPASS :: Sub => a_Sub PROCEDURE, NOPASS :: Fun => a_Fun END TYPE A_type CONTAINS SUBROUTINE a_Sub(i, r) INTEGER, INTENT(IN) :: i INTEGER, INTENT(OUT) :: r !**** r = i + 1 END SUBROUTINE a_Sub FUNCTION a_Fun(i) RESULT INTEGER, INTENT(IN) :: i INTEGER :: r !**** r = i + 1 END FUNCTION a_Fun END MODULE A_mod MODULE B_mod USE A_mod IMPLICIT NONE PRIVATE TYPE, EXTENDS(A_type), PUBLIC :: B_type CONTAINS PROCEDURE, NOPASS :: Sub => b_Sub PROCEDURE, NOPASS :: Fun => b_Fun END TYPE B_type CONTAINS SUBROUTINE b_Sub(i, r) INTEGER, INTENT(IN) :: i INTEGER, INTENT(OUT) :: r !REAL, INTENT(OUT) :: r ! This would cause error #8383 !**** r = i + 2.0 END SUBROUTINE b_Sub FUNCTION b_Fun(i) RESULT INTEGER, INTENT(IN) :: i REAL :: r ! Oops! Silly programmer... !**** r = i + 2.0 END FUNCTION b_Fun END MODULE B_mod PROGRAM fun_intf_matching_not USE A_mod USE B_mod IMPLICIT NONE TYPE(B_type) :: not_poly_var CLASS(A_type), ALLOCATABLE :: poly_var !**** PRINT *, not_poly_var%Fun(1) ! "3.0" - all good - my maths is ok. ALLOCATE(B_type :: poly_var) PRINT *, poly_var%Fun(1) ! "1" - uh oh... back to school for me!? END PROGRAM fun_intf_matching_not [/fortran]

[Wendy_Doerner__Intel]

Ian,

Thanks for the feature request. I have submitted it to engineering with tracking number: DPD200165615. Not sure you are familiar with our Static Security Analysis available by purchasing Intel Parallel Studio XE? It uses the Inspector product to find coding errors like this (although I have not tested it on this particular error). More info here:

http://software.intel.com/en-us/articles/intel-parallel-studio-xe/

------

Wendy

Attaching or including files in a post

[IanH]

Oops. I fibbed a bit... there are some gaps in the subroutine argument checking too, which have had me chasing my tail for the last week or so. Again, I guess this falls into the feature request category.

[fortran]MODULE BarParentMod
  IMPLICIT NONE 
  PRIVATE
  
  TYPE, PUBLIC :: Foo
  END TYPE Foo
  
  TYPE, PUBLIC, ABSTRACT :: BarParent
  CONTAINS
    PROCEDURE(intf_without_allocatable_arg), DEFERRED :: Proc    
  END TYPE BarParent
  
  ABSTRACT INTERFACE
    SUBROUTINE intf_without_allocatable_arg(obj, arg, dt)
      IMPORT :: BarParent, Foo
      IMPLICIT NONE
      CLASS(BarParent), INTENT(IN) :: obj
      REAL, INTENT(OUT) :: arg   ! Oops!  Should be allocatable.
      CLASS(Foo), INTENT(OUT) :: dt
    END SUBROUTINE intf_without_allocatable_arg
  END INTERFACE 
END MODULE BarParentMod

MODULE BarMod
  USE BarParentMod
  IMPLICIT NONE
  PRIVATE
  
  TYPE, PUBLIC, EXTENDS(BarParent) :: Bar
  CONTAINS
    PROCEDURE :: Proc => proc_with_allocatable_arg
  END TYPE Bar 
CONTAINS
  SUBROUTINE proc_with_allocatable_arg(obj, arg, dt)
    CLASS(Bar), INTENT(IN) :: obj
    REAL, INTENT(OUT), ALLOCATABLE :: arg
    TYPE(Foo), INTENT(OUT) :: dt  ! Oops! - I'm not very classy.
    !****
    ALLOCATE(arg)
    arg = 1.0
  END SUBROUTINE proc_with_allocatable_arg
END MODULE BarMod

PROGRAM NoCheckOfAllocatableOrPolymorphic
  USE BarParentMod
  USE BarMod
  IMPLICIT NONE
  CLASS(BarParent), ALLOCATABLE :: obj
  REAL :: arg
  TYPE(Foo) :: dt
  !****
  ALLOCATE(Bar:: obj)
  CALL obj%Proc(arg, dt)
END PROGRAM NoCheckOfAllocatableOrPolymorphic
[/fortran]

[Wendy_Doerner__Intel]

Thanks for the additional test case which I have added to the one engineering is already looking into. By the way your first was deemed a compiler bug, not a feature request. Will update this thread when we have a compiler that resolves it.

------

Wendy

Attaching or including files in a post

[Wendy_Doerner__Intel]

With the 13.0 compiler we now give errors on this test case, in other words check the functions as we should. Wendy Doerner Intel Developer Support