Re: [PATCH, Fortran] PROCEDURE declarations

[Tobias Burnus <burnus at net-b dot de>]

Tobias Schlüter wrote:
> There are two quite different kinds of PROCEDURE statements: the form
> with parentheses (R445, R451 and R1211) and the one without (R1206).
> The former is akin to a a data declaration statement, the latter to a
> MODULE PROCEDURE statement.

Agreed, except for R451 which differs from both:

R451 specific-binding is PROCEDURE [ (interface-name) ]
                         [ [ , binding-attr -list ] :: ]
                         binding-name [ => procedure-name ]

This also allows for:
  PROCEDURE proc1
is in generic interfaces, but also for
  PROCEDURE(interface) :: sub3
  PROCEDURE, bind(C) :: proc1 => proc3

This PROCEDURE is also special as it allows only for one item
and not for a list as the other PROCEDURE statements.

But we can start worrying about this when we start implementing it.


> The point is, we've repeatedly had issues with entries creeping out
> the woodworks.  Entries are weird, and they tend to break assumptions
> one tacitly makes.  It's worth checking.

Good point. The following crashes with my version of the patch (I don't
use the latest one):
test.f90:1: internal compiler error: in build_function_decl, at
fortran/trans-decl.c:1208


SUBROUTINE a
 abstract interface
   subroutine abc(x)
     real x
   end subroutine
 end interface
 procedure(abc) :: abc2
entry abc2(x)
 real x
 x = 0
end subroutine
end


> I think that's fine.  I would like this message and the one from above
> to use a similar message, but I'm convinced that you'll find a
> pleasant color for this particular bikeshed.
Given the grey, rainy day I suggest blue and yellow.

>>> Another solution would be to move this particular check to the
>>> resolution stage.  While even cleaner, this also would mean more work
>>> for you.
>> But at resolution stage we have no information of the number of
>> identifiers, do we?
> That depends on what information one keeps in the parsing stage :-) 
> But this change is definitely beyond the scope of your current patch,
> and can be addressed whenever someone feels the urge (i.e. never :-).
If this should be really fixed, I suggest to fill a PR - otherwise we
will forget about it.

> Provided Tobias B agrees, this is ok with the change to use
> gfc_add_proc() and after you played around with entries a bit.
I think with these changes (and an ENTRY fix) it should be ok.
Especially, we can still change things afterwards if we discover more
problems or have better ideas.

Tobias