Re: [Patch, Fortran] Add parsing support for assumed-rank array

[Mikael Morin <mikael dot morin at sfr dot fr>]

Hello,

I somehow was reading this in the standard:
"An assumed-rank variable name shall not appear in a designator or
expression except as an actual
argument corresponding to a dummy argument that is assumed-rank..."

with "...except in..." instead of "...except as...".

Some of my comments were plain misunderstanding/misinterpretation on my
side.
The next comment iteration is below.

Mikael

On 13/07/2012 09:50, Tobias Burnus wrote:
>>> @@ -5067,13 +5097,26 @@ resolve_variable (gfc_expr *e)
>>>    /* TS 29113, 407b.  */
>>> -  if (e->ts.type == BT_ASSUMED && !assumed_type_expr_allowed)
>>> +  if (e->ts.type == BT_ASSUMED && !assumed_rank_type_expr_allowed)
>>>      {
>>>        gfc_error ("Invalid expression with assumed-type variable %s
>>> at %L",
>>>           sym->name, &e->where);
>>>        return FAILURE;
>>>      }
>>
>> I'm not sure I understand the logic with the mixed assumed rank/type
>> flag. According to C407c, shouldn't we check that e is assumed
>> rank/shape?
> 
> No, that check is not for assumed-rank arrays but for (e.g. scalar)
> assumed type, TYPE(*). The check handles cases like:
> 
>   type(*) :: x
>   print *, ubound(array, dim=x)
> 
> where "x" is not allowed, contrary to, e.g.,
> 
>   type(*) :: x(:)
>   print *, ubound(x)
> 
> Thus, one needs to keep track whether "x" is allowed or is not allowed
> in an expression. As that's the same for assumed type and for assumed
> rank, I am using the same tracking variable, called
> assumed_rank_type_expr_allowed. A better name would be:
> assumed_rank_or_assumed_type_expr_allowed  (or s/or/and/), however, I
> found my version clear enough and while it is already long, that variant
> would be even longer.

What about naming the flag in_actual_arg and moving the inquiry_argument
condition to the error condition?

> 
>>>
>>> +  /* TS 29113, C535b.  */
>>> +  if (((sym->ts.type == BT_CLASS && sym->attr.class_ok
>>> +    && CLASS_DATA (sym)->as
>>> +    && CLASS_DATA (sym)->as->type == AS_ASSUMED_RANK)
>>> +       || (sym->ts.type != BT_CLASS && sym->as
>>> +       && sym->as->type == AS_ASSUMED_RANK))
>>> +      && !assumed_rank_type_expr_allowed)
>>> +    {
>>> +      gfc_error ("Invalid expression with assumed-rank variable %s
>>> at %L",
>>> +         sym->name, &e->where);
>>
>> The error message could be made more helpful. ;-)
> 
> Suggestions welcome. Example use would be:
> 
> x = x +1
> call foo(x+1)
> call sin(x)  ! Though that probably triggers elsewhere
> 
> I don't think the wording is that bad.

Well, my problem with it is that it doesn't tell what is invalid.
What do you think about "Assumed rank variable %s at %L can only be used
as an actual argument." ?
I think that currently your foo(x+1) case doesn't trigger an error.
It's not in your testcases at least.

> 
>>> @@ -5084,6 +5127,22 @@ resolve_variable (gfc_expr *e)
>>>        return FAILURE;
>>>      }
>>>
>>> +  /* TS 29113, C535b.  */
>>> +  if (((sym->ts.type == BT_CLASS && sym->attr.class_ok
>>> +    && CLASS_DATA (sym)->as
>>> +    && CLASS_DATA (sym)->as->type == AS_ASSUMED_RANK)
>>> +       || (sym->ts.type != BT_CLASS && sym->as
>>> +       && sym->as->type == AS_ASSUMED_RANK))
>>> +      && e->ref
>>> +      && !(e->ref->type == REF_ARRAY && e->ref->u.ar.type == AR_FULL
>>> +           && e->ref->next == NULL))
>>> +    {
>>> +      gfc_error ("Assumed-rank variable %s with designator at %L",
>>> +                 sym->name, &e->ref->u.ar.where);
>>
>> Ditto here. And I think that C535b is more about the context of the
>> expression rather than the expression itself.
> 
> Here, I am lost. The check is that
>   ubound(x(:))
>   call bar (x(1))
>   call bar2(x([1,3,5])
>   call bar3(x(1:5:2))
> or similar does not occur if "x" is assumed rank. That "(:)" is an
> (array) designator. Do you have a better suggestion? I could add the
> word "array" before "designator", but I would like to avoid to list all
> possible combinations.

This one error is better as it tries to hint what's wrong. However, ...

> 
> From TS29113:
> "C407b An assumed-type variable name shall not appear in a designator or
> ..."
> 
> From Fortran 2008:
> 
> "1.3.59 designator
> name followed by zero or more component selectors, complex part
> selectors, array section selectors, array element selectors, image
> selectors, and substring selectors (6.1)"

... according to this, a bare variable name is also a designator, and it
is valid.  So issuing errors because the variable is/has a designator
seems confusing at best. I'm almost satisfied with this (maybe
s/with/in/ or s/be used with/???/) :
"Assumed-rank variable %s at %L cannot be used with a subobject reference."