Hi Yuao,
Tobias Burnus wrote:
For BT_DERIVED:
(i) The type needs to be the same – or compatible ('SEQUENCE' attribute)
I was referring to: "7.5.2.4 Determination of derived types":
"Data entities also have the same type if they are declared with
reference to different derived-type definitions that specify the same
type name, all have the SEQUENCE attribute or all have the BIND attribute."
But as they need to have the same name, it is formally correct, but has
no practical effect for checking.
Thus, feel free to ignore this mumbling.
* * *
(ii) If there are kind arguments, it needs to be the same.
gfortran names parameterized derived types (PDT) as
'Pdt' + type name + '_<kindvalue> – thus for
'type t(x); integer, kind :: x' – the names associated
with type(t(x=5)) and type(t(6)) are 'Pdtt_5' and 'Pdtt_6',
respectively. - Which implies a name check.
However, it seems as if the simplest is to call:
gfc_compare_types and use gfc_typename in the diagnostic.
As discussed before, I think rejecting BT_CLASS for now
makes sense, but there is no reason why BT_DERIVED including
PDT can't be enabled.
type t(kind,dim)
integer, kind :: kind = 4, dim = 10
real(kind=kind) :: array(dim)
end type t
...
type(t(8)) :: x
type(t(dim=10)) :: y
type(t(8,24)) :: z
would be a use for the *kind type parameter* ('kind'); The kind is
known at compile time and, hence, does not actually need to be stored
in the type. The 'len' type parameter also exists.
* * *
BT_CLASS:
As the declare type needs to be the same,
subroutine sub(var, var2)
type(t) :: var
class(t) :: var2
... (cond ? var : var2)
seems to be fine – and would be accepted by the gfc_compare_types
check. But there are presumably further adjustments required,
Including, possibly the optimization whether BT_CLASS should
be converted to BT_DERIVED or BT_DERIVED to BT_CLASS, depending
how the conditional-expr / conditional-arg is used. Erring on
BT_CLASS is probably best, but having some optimizations might
still make sense, at least when used as dummy argument.
* * *
And regarding procedure/procedure pointers:
While 'actual-arg' (R1524) permits procedure-name and proc-component-ref,
the 'conditional-arg' constitutent, i.e. 'consequent-arg' (R1528) only
permits 'expr' or 'variable' - i.e. no procedures are permitted
* * *
Talking about NIL, I noticed that (cond ? .nil. : .nil.) is invalid,
cf. first sentence of:
C1540 At least one consequent in a conditional-arg shall be a consequent-arg.
If the corresponding dummy argument is not optional, .NIL. shall not appear.
Cheers,
Tobias
PS: Sorry, previous patch review email was written in a bit of a rush as I
had a series of meetings afterwards.
PPS: If you dislike the gfc_typename output: This is a known problem, but
not that trivial to be fixed as gfc_typename returns a 'const char*',
i.e. dynamic memory allocation is not possible. On the other hand, adding
kind values to type names might quickly exceed the available length for
symbol names - not only for the diagnostic but also internally. For the
latter, the idea to use the string pool as used for 'tree' by the middle
end, was discussed. For now, the hope is that any sensible program does
not exceed this.
For now, just use it – but eventually it should be improved ...
