Hi Mikael,
>> here is a patch for a rather long-standing PR. It continues my ongoing
>> campaign of improving the checks for "procedure characteristics" (cf.
>> F08 chapter 12.3), which are relevant for dummy procedures, procedure
>> pointer assignments, overriding of type-bound procedures, etc.
>>
>> This particular patch checks for the correct shape of array arguments,
>> in a manner similar to the recently added check for the string length
>> (PR 49638), namely via 'gfc_dep_compare_expr'.
>>
>> The hardest thing about this PR was to find out what exactly the
>> standard requires (cf. c.l.f. thread linked in comment #12): Only the
>> shape of the argument has to match (i.e. upper minus lower bound), not
>> the bounds themselves (no matter if the bounds are constant or not).
>>
>> I also added a FIXME, in order to remind myself of adding the same
>> check for function results soon.
>>
>> The patch was regtested on x86_64-unknown-linux-gnu. Ok for trunk?
>>
>
> The patch is basically OK.
thanks for the review!
> Any reason to keep this disabled?
>
> + case -2:
> + /* FIXME: Implement a warning for this case.
> + gfc_warning ("Possible shape mismatch in argument '%s'",
> + s1->name);*/
> + break;
Well, in principle not. As you might have noticed, such a warning is
already in effect e.g. when calling 'gfc_dep_compare_expr' from
'gfc_check_typebound_override'.
The problem with 'check_dummy_characteristics' is that it does not
directly throw an error, but only writes a message into a string
variable and returns FAILURE to the calling procedure, which itself is
responsible for throwing the error.
This mechanism is used to enhance flexibility and improve the error
message by prepending a string describing the context in which the
error message occurs (e.g. we might see a mismatch of characteristics
either in a procedure pointer assignment or when passing an actual
argument for a dummy procedure, etc).
The situation is further complicated by the fact that
'check_dummy_characteristics' is also called by
'gfc_compare_interfaces', which itself does not throw an error either,
but again just passes a string to the calling procedure.
If you have a cute idea how to elegantly introduce warnings into this
mechanism, I'm all ears. Otherwise I'll just start by committing the
patch as posted ...
Thanks again for the feedback,
Janus
