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."
