Implict typing and defaulted derived type kind params

[IanH]

Take the very new and the very old, and just for fun mix them together and see what happens.

PROGRAM p
  IMPLICIT TYPE(t)(a)
  INTEGER, PARAMETER :: i = 99
  TYPE t(k)
    INTEGER, KIND :: k = i
    INTEGER :: comp
  END TYPE t
  TYPE(t) :: b
!  a = t(1) ; b = t(1) ! Spurious error #8212
  PRINT *, a%k, b%k
END PROGRAM p

>ifort /check:all /warn:all /standard-semantics /stand implicit.02.f90 && implicit.02.exe
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.108 Build 201407
26
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

implicit.02.f90(10): warning #6717: This name has not been given an explicit type.   
  PRINT *, a%k, b%k
-----------^
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:implicit.02.exe
-subsystem:console
implicit.02.obj
 0 99

[Steven_L_Intel1]

Amusing.  Thanks.

[Steven_L_Intel1]

I believe that the error 8212 in the commented out line is correct. With t(1), you are specifying a value for the type parameter k, but not for the component comp. However, this brings up different issues that are compiler bugs when I fix this by changing these to t(comp=1):

First, the compiler is not applying the implicit TYPE(t) to variable a. Second, for the assignment to b, the compiler complains that the types don't match, which is not correct.

I have escalated this as issue DPD200362973.

[IanH]

With the 8212 thing, isn't the syntax with a specification for the type parameter t(expr_for_k)(expr_for_comp) ,  the first set of parens belonging to the derived-type-spec syntax rule and being optional?

[Steven_L_Intel1]

Yes, that's right - I missed that.

[Steven_L_Intel1]

The error 8212 is escalated as DPD200362993. This was a real head-scratcher for me as I thought at first that there was a syntax ambiguity in the language. I caught myself, though, and realized that there isn't. If the (1) was intended to be a type parameter, the constructor would have to be written as t(1)().

[Steven_L_Intel1]

This has been fixed - I expect the fix to appear in update 2, planned for February.

[Steven_L_Intel1]

To be clear, I expect both problems reported here to be fixed in Update 2.

[IanH]

When the paint on update two is touch dry, give it a whirl on the following maliciousness.

PROGRAM p
  IMPLICIT NONE
!  TYPE :: t(k)
!    INTEGER, KIND :: k
!  END TYPE t
CONTAINS
  SUBROUTINE s
    IMPLICIT TYPE(t(1,2))(a)
!    CLASS(t(2,3)), ALLOCATABLE :: b
    TYPE :: t(j,k)
      INTEGER, KIND :: j
      INTEGER, KIND :: k
    END TYPE t
  END SUBROUTINE s
END PROGRAM p

with 15.0.1 and /check:all /warn:all /standard-semantics it ices.

Because of the ice I didn't quite get there, but the ability to have a forward reference of sorts (in the implicit statement) to a type that may or may not be defined in the current scope looked like a fun little problem to resolve.

[Steven_L_Intel1]

Looks like we fixed this one too. It no longer reproduces with our latest sources.