Hi Harald,

(Written 17th but left in intray by mistake.)

Thanks for the review. I will make sure that the intended changes are
incorporated.

I haven't applied it yet because I was so heavily engaged in trying to make
two pass parsing work that I didn't want the interruption. As it happens,
it was obvious by yesterday that it was going to be considerably more
difficult than I anticipated. I have posted the patch to PR89645, together
with a list of testsuite failures. Many of these are so obscure that I
didn't have any idea how to put them right. I reverted to the fix-up patch
and, having come at it with fresh eyes, have fixed the problems that I was
having with it. It is regesting as I write.

My order of work between now and the Christmas break is:
1] Apply the agreed patch for PR112459; -now done
2]               -ditto-               for PR112834; -now done
3] Generate testcases for PR89645 and all its variants (especially with
class replacing derived types); and
4] Prepare the whole lot for submission to the list.

My local test for PR87477 now shows " 43 successes out of  43 tests" :-)

Regards

Paul


On Wed, 6 Dec 2023 at 19:35, Harald Anlauf <anlauf@gmx.de> wrote:

> Hi Paul,
>
> On 12/6/23 17:09, Paul Richard Thomas wrote:
> > Dear All,
> >
> > This patch was rescued from my ill-fated and long winded attempt to
> provide
> > a fix-up for function selector references, where the function is parsed
> > after the procedure containing the associate/select type construct (PRs
> > 89645 and 99065). The fix-ups broke down completely once these constructs
> > were enclosed by another associate construct, where the selector is a
> > derived type or class function. My inclination now is to introduce two
> pass
> > parsing for contained procedures.
> >
> > Returning to PR112834, the patch is simple enough and is well described
> by
> > the change logs. PR111853 was fixed as a side effect of the bigger patch.
> > Steve Kargl had also posted the same fix on the PR.
>
> the patch looks good, but could you please check the coding style?
>
> @@ -6550,7 +6551,19 @@ select_type_set_tmp (gfc_typespec *ts)
>         sym = tmp->n.sym;
>         gfc_add_type (sym, ts, NULL);
>
> -      if (selector->ts.type == BT_CLASS && selector->attr.class_ok
> +      /* If the SELECT TYPE selector is a function we might be able to
> obtain
> +        a typespec from the result. Since the function might not have been
> +        parsed yet we have to check that there is indeed a result
> symbol.  */
> +      if (selector->ts.type == BT_UNKNOWN
> +         && gfc_state_stack->construct
> +         && (expr2 = gfc_state_stack->construct->expr2)
> +         && expr2->expr_type == EXPR_FUNCTION
> +         && expr2->symtree
> +         && expr2->symtree->n.sym && expr2->symtree->n.sym->result)
>
> Adding a line break before the second '&&' makes it more readable.
>
> +       selector->ts = expr2->symtree->n.sym->result->ts;
>
> @@ -2037,7 +2038,12 @@ trans_associate_var (gfc_symbol *sym,
> gfc_wrapped_block *block)
>
>         /* Class associate-names come this way because they are
>          unconditionally associate pointers and the symbol is scalar.  */
> -      if (sym->ts.type == BT_CLASS && CLASS_DATA (sym)->attr.dimension)
> +      if (sym->ts.type == BT_CLASS && e->expr_type ==EXPR_FUNCTION)
>
> There should be whitespace before AND after '=='.
>
> +       {
> +         gfc_conv_expr (&se, e);
> +         se.expr = gfc_evaluate_now (se.expr, &se.pre);
> +       }
> +      else if (sym->ts.type == BT_CLASS && CLASS_DATA
> (sym)->attr.dimension)
>
> > Regression tests - OK for trunk and 13-branch?
> >
> > Paul
> >
>
> Thanks for the patch!
>
> Harald
>
>