Re: [Patch, fortran] PR82173 (PDT) - [meta-bug] Parameterized derived type errors

[Paul Richard Thomas <paul.richard.thomas@gmail.com>]

Dear Dominique,

That error is perfectly correct. Change the order of the assignment
and the declaration for 'b' and you will see that all is well.

The matching of type parameter specification list follows the same
rules as those of actual arguments, except that deferred and assumed
expressions are allowed for PDTs.

I am not convinced that I have deferred and assumed parameters fully
sorted out yet. I suspect that I am too permissive. On the other hand
entities declared in a module do not make any sense unless (i) All the
LEN parameters are deferred; or (ii) The default initialization is
somehow able to deal with variables in the specification expressions.
I will have to ask one of the gurus how to do this.

Cheers

Paul


On 12 September 2017 at 13:47, Dominique d'Humières <dominiq@lps.ens.fr> wrote:
> Dear Paul,
>
> I have been playing with the patch and found that the following variant of the test for pr82168
>
> module mod
> implicit none
>
> integer, parameter :: dp = kind (0.0d0)
>
> type, public :: v(z, k)
>    integer, len :: z
>    integer, kind :: k = kind(0.0)
>    real(kind = k) :: e(z)
> end type v
>
> end module mod
>
> program bug
> use mod
> implicit none
>
> type (v(2)) :: a
> a%e = 1.0
> type (v(z=:, k=dp)) :: b
>
> end program bug
>
> gives the error
>
> pr82168_db_1.f90:23:24:
>
>  type (v(z=:, k=dp)) :: b
>                         1
> Error: Unexpected data declaration statement at (1)
>
> I am also puzzled by the meaning of ‘z=:’ in the main program. Should not it be restricted to be inside a procedure?
>
> Cheers,
>
> Dominique
>
>



-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein