Type-bound procedure and procedure pointer component calls

[Daniel Kraft]

Tobias Burnus wrote:
> Hi Daniel, Janus, et al.,
> 
> Daniel Kraft wrote:
>> 2) Implement a routine to adapt actual arglists by inserting
>> passed-object arguments in case of PASS. This should be straight
>> forward and recyclable for procedure pointer components, at least I
>> think so. Do you have special requirements for this to work, Janus?
> 
> I don't think that there are special requirements - except that the
> interface for procedure pointer components (similar to deferred
> procedures) is given as
>   procedure(interface) [...] :: proc
> and does not point to a procedure as in
>   procedure [...] :: proc => procTarget
> Thus except for where the information is stored they should be
> identically. (Other than that there is a fundamental difference: TPB
> call an otherwise available procedures while PPC are only accessible via
> the procpointer; I'm not sure whether this makes a difference with
> regards to struct gfc_callee or elsewhere -- presumably not.)

So do you agree with my proposal for gfc_callee?  If so and if Janus 
agrees, too, I'll start working on this intermediate patch to introduce 
gfc_callee.  I will try to store parsed callees there instead of the 
symtree members and adapt the existing code and see if this is a good 
approach or requires too many changes.  If it does, I'll set symtree 
during resolution from the gfc_callee data (for typebound procedures 
this is ok, too, as they eventually become ordinary calls during 
resolution).

>> Does anyone know, is it an error to define a type-bound procedure with
>> the same name as an (array) component of the derived-type? 
> 
> It is, but it is a bit hidden:
> 
> "16.2 Scope of local identifiers
> "Within a scoping unit, identifiers of entities in the following
> classes: [...]
> (2) Type parameters, components, and type-bound procedure bindings, in a
> separate class for each type, [...]
> are local identifiers in that scoping unit. [...]
> "Within a scoping unit, a local identifier of one class shall not be the
> same as another local identifier of the same class, except that a generic
> name may be the same as the name of a procedure as explained in 12.3.2.1
> or the same as the name of a derived type (4.5.9)."

So I will add tests for type-bound procedures not to be of the same name 
as components ;)  Sould not be hard...

> Reading the standard, some constrains came into my mind, which I
> tested:
> 
> -------------------------------
> use iso_c_binding
> implicit none
> intrinsic cos
> procedure(cos) :: foo
> 
> interface
>   subroutine bar
>   end subroutine bar
> end interface
> 
> type, bind(c) :: f
>   integer(c_int) :: i
> ! INVALID:
> contains
>   procedure, nopass :: bar
> ! C433 (R429) If SEQUENCE appears, a type-bound-procedure-part shall not
> !             appear.
> ! same for BIND(C):
> ! C1504 (R429) A derived type with the BIND attribute shall not have a
> !              type-bound-procedure-part.
> end type f

This should not be hard, either.  I will include it with the patch for 
component-checks.

> type t
> contains
> ! Why is this rejected? "foo" should be an external procedure with an
> ! explicit interface
>   procedure, nopass :: foo
> end type t

I have to admit that I don't quite know what

PROCEDURE(cos) :: foo

above means.  Does this establish an explicit interface for foo?  If so, 
foo's symbol's if_source is probably still not set to IFSRC_IFBODY.  How 
do I know about this interface then, so I can adapt the check accordingly?

Cheers,
Daniel

-- 
Done:     Arc-Bar-Cav-Sam-Val-Wiz, Dwa-Elf-Gno-Hum-Orc, Law-Neu-Cha, Fem-Mal
To go:    Hea-Kni-Mon-Pri-Ran-Rog-Tou